[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