Security Risks of Firewire and PCMCIA DMA

Discussion in 'Computer Security' started by Privacy, Jun 6, 2007.

  1. Privacy

    Privacy Guest

    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.
     
    Privacy, Jun 6, 2007
    #1
    1. Advertising

  2. Privacy

    Privacy Guest

    Sorry, I should have posted to all groups simultaneously.

    On Jun 6, 12:30 am, 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.
     
    Privacy, Jun 6, 2007
    #2
    1. Advertising

  3. Privacy

    Rick Merrill Guest

    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!
     
    Rick Merrill, Jun 6, 2007
    #3
  4. Privacy

    Sebastian G. Guest

    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.
     
    Sebastian G., Jun 6, 2007
    #4
  5. "Sebastian G." <> writes:

    >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.
     
    Casper H.S. Dik, Jun 6, 2007
    #5
  6. Privacy

    Sebastian G. Guest

    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.
     
    Sebastian G., Jun 6, 2007
    #6
  7. Privacy

    Guest

    On Jun 6, 9:07 am, "Sebastian G." <> wrote:
    > 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.
    >


    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.

    > 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.


    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.
     
    , Jun 7, 2007
    #7
  8. Privacy

    Sebastian G. Guest

    wrote:


    > 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.



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

    >> 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.

    >
    > 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).



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

    > Is there any way that you know of to manipulate PCI on a running
    > system to get a RAM dump?



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

    > 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?



    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.
     
    Sebastian G., Jun 7, 2007
    #8
  9. Privacy

    mangler Guest

    On Tue, 05 Jun 2007 21:30:14 -0700, 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.



    How about taking a soldering iron to the firewire chip and removing
    it ?
     
    mangler, Jun 9, 2007
    #9
  10. Privacy

    oskiller Guest

    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
    <> 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.
     
    oskiller, Jun 10, 2007
    #10
  11. Privacy

    David Lesher Guest

    Privacy <> writes:


    >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.




    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
    & 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
     
    David Lesher, Jun 12, 2007
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    2
    Views:
    5,049
    Martin Kayes
    Dec 15, 2005
  2. Babak Majidi
    Replies:
    3
    Views:
    610
    Babak Majidi
    Feb 6, 2006
  3. Imhotep

    More tech fails to exorcise security risks

    Imhotep, Sep 14, 2005, in forum: Computer Security
    Replies:
    7
    Views:
    501
    Imhotep
    Sep 15, 2005
  4. dfox138
    Replies:
    5
    Views:
    5,454
    Winged
    Jan 5, 2006
  5. DONOTREPLY
    Replies:
    1
    Views:
    1,354
    Roger Johnstone
    May 12, 2007
Loading...

Share This Page