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.

Sorry, I should have posted to all groups simultaneously.

On Jun 6, 12:30 am, Privacy <privacyorien...@mailinator.com> wrote:

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

Rick Merrill wrote:



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.

"Sebastian G." <seppi@seppig.de> writes:

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.

Casper H.S. Dik wrote:

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.

On Jun 6, 9:07 am, "Sebastian G." <s...@seppig.de> wrote:
Okay, 2 possible solutions:

1. deactivate bus mastering for the firewire controller
2. disable firewire debugging for the controller

I'll be damned if I know how to do either. Could you list all the ways
you know of to accomplish the above. I'll just do them all. I don't
need firewire on the system in question. I'll do anything short of
destroying the firewire capabilities, because I don't think that's
reliable anyway.

If it doesn't work, at least I will have tried my best.

Regarding PCI, I was reading about something called Tribble that could
compromise a system and get all the contents of RAM. But the trick was
that it had to be installed before the system was turned on (I think).
Is there any way that you know of to manipulate PCI on a running
system to get a RAM dump?

Regarding the issue of disabling the drivers. If disabling the drivers
causes the system to power down the port in question, does that
mitigate any potential risks associated with the port? In other words,
if I can confirm a port is powered down, do I have anything to worry
about from that port?

Thank you.

privacyoriented2@mailinator.com wrote:



Turn of the FireWire controller in both BIOS and your OS, and then check
whether you can still do kernel debugging over FireWire.


The real trick is how to insert a PCI card on the running system without
breaking the bus arberitation.


Why using PCI? Snooping the system bus at the RAM controller is way easier.


Yes and no. It doesn't power down anything, but as long as busmastering was
disabled before, there'll be no driver turning it on again.

On Tue, 05 Jun 2007 21:30:14 -0700, Privacy
<privacyoriented@mailinator.com> wrote:


How about taking a soldering iron to the firewire chip and removing
it ?

Maybe I'm wrong on my thinking on this, but can't they just be
disabled in both the bios and the os? Disable in the device manager,
and if there is no way to manage the system remotely, then they should
stay disabled and plugging anything into the ports would be worthless.

On Tue, 05 Jun 2007 21:30:14 -0700, Privacy
<privacyoriented@mailinator.com> wrote:

Privacy <privacyoriented@mailinator.com> writes:




Fill the ports with dongles whose presence will be verified
frequently; and do nasty things if they are not there...


--
A host is a host from coast to coast.................wb8foz@nrk.com
& no one will talk to a host that's close........[v].(301) 56-LINUX
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433