[OLPC Security] Securing the laptop: DoS

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Fri Sep 8 00:33:01 EDT 2006


Hi,

after having read through the security@ archives and having followed
devel@ closely, it seems to me that a few points have not yet entered
our field of view.

Please note that while some of my points may seem esoteric or
unrealistic, I've had quite some success with deliberately
misunderstanding specifications and questioning the obvious.
Besides that, having managed a switched (not routed) network with
~3000 unmanaged nodes (student housing), I know the havoc people
can (un)knowingly inflict on such networks, and broadcast storms
are the smallest problem of that.

1. Power management
- Current plans focus on hardware and software ability to conserve
  power so that children have a reasonable chance of keeping the
  laptop powered for ten times longer than it needs to be charged
  (by physical effort on part of the children and/or other charging
  methods).
! An attacker might look for ways to drain the battery faster than
  expected to reduce the use/charge ratio. Examples:
  * Run javascript endless loops in the browser
  * Abuse the fact that certain (D)HTML constructs are extremely
    cpu-intensive in the default browser
  * Force automatical reload of a render-heavy local web page with
    maximum reload rate
  * Use browser plugins (flash/gnash etc.) to escape detection of
    any of the above points
  * Offer applications for download which keep the CPU busy (you get
    the pattern...)
  * Offer applications which keep the connection to the DCON busy
  * USB access/polling/scanning also can use a lot of power
  * Wireless also uses more power if transmitting continuously,
    so applications might flood the network in order to keep the
    transmitter busy
  * Writes to NAND flash also require some power...

2. Network DoS
- Wireless firmware development so far seems to be focused on getting
  mesh routing and other nifty features to work nicely. That's great.
! Wireless uses a shared medium (that's bad enough in itself, though
  not fixable) and additionally can suffer from the exposed/hidden
  station problems (there are ways around that, though). This creates
  the following problems:
  * Any node can completely block wireless communication of all other
    nodes in its range (subject to all sharing the same channel), and
    that's the best case
  * Not only will communication between any two nodes in the range of
    the evil node be blocked, but communication from inside the range
    with nodes outside of the range is equally impossible
  * Assuming that nodes outside of the evil range are trying to reach
    nodes inside the range and the outside nodes retry sending packets
    regularly, congestion will happen in an area up to three times
    the range of the evil node
! Now if the attacker has some intelligence and is not only jamming
  the radion channel as stated above, it gets worse:
  * Pushing data over the mesh to some distant node reachable only
    via at least a dozen hops should keep traffic high in all of the
    traversed cells
  * If all nodes use the same channel, forwarding can only work with
    at most half of the maximum data rate (with one forwarder) or even
    less (with multiple forwarders)
  * The calculations above assume the absence of other local nodes,
    with some of them being present and active, contention gets really
    horrible
  * If broadcast/multicast is relayed over the mesh, equally bad things
    can happen

3. Hardware DoS
- Development has focused on making the machines unbreakable by most
  physical threats (rain, dust, getting dropped...), but damaging the
  hardware by software has not been discussed at all (except the
  BIOS flashing debate, which I will not reopen).
! The onboard NAND flash has a limited number of writes per sector
  before it will start to wear out. JFFS2 tries its best to mitigate
  repeated writes to a file by distributing the writes evenly over the
  whole flash chip.
  * Opening a file and running a {modify, fsync} endless loop on it
    should be able to kill the flash chip in minutes
! Uploading malicious firmware to the wireless chip:
  * The firmware might overload the transmitter (don't know whether
    that is possible on our hardware)
! Abusing power management features
  * Switching on/off components can result in electic transients
    which have (with the right timing) the ability to kill a power
    supply or voltage regulating circuits (I remember exploding
    capacitors around 1996 when malicious code sent the Pentium
    processor to sleep and back in rapid succession)

4. Other (non-DoS) issues
! Uploading malicious firmware to the wireless chip:
  * If the wireless chip can do DMA, it might be used to overwrite
    kernel memory
! "Target mode" or other disaster recovery methods:
  * Make sure software can handle a malicious target
    + Do not mount any file system of the target, it might exploit
      a bug in the fs implementation
    + If the target appears as an USB device, assume the same danger
      a specially crafted USB device would pose
! Not sure whether LinuxBIOS should really mount the NAND flash
  before disabling BIOS flashing
  * If someone figures out a way to exploit JFFS2, he would be able
    to circumvent all BIOS flashing checks because we mount JFFS2
    on the NAND flash to look for BIOS updates while BIOS write is
    still enabled


Regards,
Carl-Daniel

P.S.: I spent the whole night writing this email, so some sentences
might sound a little unclear and at 6:30am I'm not really able to
detect that anymore. Apologies for that. Will respond to any
questions after I get some sleep.


More information about the Security mailing list