[gentoo-security] Fwd: FireWire Security issues

[Benjamin Zimmermann]

Hi,
I thought this might be interesting.

Ben.


----------  Weitergeleitete Nachricht  ----------

Subject: FireWire Security issues
Date: Dienstag, 16. November 2004 21:30
From: Maximillian Dornseif <dornseif@××××××××××××××××××××××.de>
To: freebsd-security@×××××××.org
Cc: freebsd-firewire@×××××××.org

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-ha
ckers/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@××××××××××××××××××××××.de
Phone: [phone]
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@×××××××.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@×××××××.org"

-------------------------------------------------------

--
gentoo-security@g.o mailing list