Security Risks of Firewire and PCMCIA DMA

Security Risks of Firewire and PCMCIA DMA
Secure Home | Search | About
Login Password
Register Now! Lost Password?
 Computer Software Security    Post an article   get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content add this group's latest topics to your Google content
Subject Author Date
Security Risks of Firewire and PCMCIA DMA Privacy 06-06-2007
Posted by Privacy on June 6, 2007, 12:30 am
If you were  Registered and logged in, you could reply and use other advanced thread options
Does anyone know of a way to mitigate or totally eliminate the risks
of firewire and PCMCIA direct memory access on a running Windows XP
system that has the keyboard/mouse/screen locked out?

Everything I've ever read has said just live with the risk because
there's nothing you can do about it. Some have suggested just plugging
the ports with epoxy. That's not a good solution and can probably be
bypassed.

The problem seems to be that no matter how diligent you are, there's
no software solution to this. These ports have direct access to RAM,
so they can do virtually anything to your system. I'm sure there's a
solution out there, but I have yet to run accross it.


Posted by Rick Merrill on June 6, 2007, 8:55 am
If you were  Registered and logged in, you could reply and use other advanced thread options
Privacy wrote:
> Does anyone know of a way to mitigate or totally eliminate the risks
> of firewire and PCMCIA direct memory access on a running Windows XP
> system that has the keyboard/mouse/screen locked out?
>
> Everything I've ever read has said just live with the risk because
> there's nothing you can do about it. Some have suggested just plugging
> the ports with epoxy. That's not a good solution and can probably be
> bypassed.
>
> The problem seems to be that no matter how diligent you are, there's
> no software solution to this. These ports have direct access to RAM,
> so they can do virtually anything to your system. I'm sure there's a
> solution out there, but I have yet to run accross it.
>

Why not delete the drivers? That ought to do it!

Posted by Sebastian G. on June 6, 2007, 9:07 am
If you were  Registered and logged in, you could reply and use other advanced thread options
Rick Merrill wrote:


> Why not delete the drivers? That ought to do it!


Exactly not. The point is that you don't need any drivers to interact with
the hardware to set this up. Heck, your kernel could already be crashed, and
still you could dump the entire RAM content over FireWire by issuing the
relevant commands. A reasonable workaround would be to deactive Busmastering
for the FireWire controller, a better would be a utility which disables
FireWire debugging for the controller.

For PCMCIA, there is no workaround. PCMCIA is almost equivalent to PCI,
which allows the hardware to take over the system as it likes, including
sending arbitrary electrical signals to the system bus.

Posted by Casper H.S. Dik on June 6, 2007, 3:29 pm
If you were  Registered and logged in, you could reply and use other advanced thread options

>Exactly not. The point is that you don't need any drivers to interact with
>the hardware to set this up. Heck, your kernel could already be crashed, and
>still you could dump the entire RAM content over FireWire by issuing the
>relevant commands. A reasonable workaround would be to deactive Busmastering
>for the FireWire controller, a better would be a utility which disables
>FireWire debugging for the controller.

Actually, you do need to enable the firewire device to allow for
such commands; if it is disabled it will not work.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

Posted by Sebastian G. on June 6, 2007, 4:04 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
Casper H.S. Dik wrote:

>> A reasonable workaround would be to deactive Busmastering
>> for the FireWire controller, a better would be a utility which disables
>> FireWire debugging for the controller.
>
> Actually, you do need to enable the firewire device to allow for
> such commands; if it is disabled it will not work.

Sadly this is not the case. It heavily depends on whether busmastering was
initially enable by the driver, when then disabling the driver will lead to
the discussed state. If it was already enable by the ACPI BIOS Setup, then
disabling the driver won't change anything. Depending on the implementatin,
disabling it in the BIOS might change something, but I wouldn't count on
that. Not to mention System Management Mode and ACPI firmware...

At any rate, disabling the device might not be appropriate if you actually
want/need to use it.

Similar ThreadsPosted
More tech fails to exorcise security risks September 14, 2005, 3:06 pm
Classification of Security Risks: Critical, High, Medium, Low and Warning December 30, 2005, 10:45 am
IT project risks November 19, 2006, 1:45 am
risks of using a router without a firewall September 13, 2005, 9:57 pm
Infection risks with an account with no administrator rights? August 31, 2005, 9:13 pm
Security Breaches Pandemic - Deloitte Touche 2006 Global Security Survey June 26, 2006, 11:15 pm
New site dedicated to security conferences : www.security-briefings.com May 6, 2006, 11:04 am
AOL Offers Security Tool - Active Security Monitor June 10, 2006, 1:20 am
Re: Internet Security Software.(computer internet security) April 27, 2008, 7:43 am
Security can be fun ! June 28, 2005, 4:09 pm

The site map in XML format XML site map

Contact Us | Privacy Policy