Date: Tue, 16 Nov 2004 21:30:09 +0100 From: Maximillian Dornseif <dornseif@informatik.rwth-aachen.de> To: freebsd-firewire@freebsd.org Cc: freebsd-security@freebsd.org Subject: FireWire Security issues Message-ID: <cndo0f$5bv$1@sea.gmane.org>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?cndo0f$5bv$1>