[OLPC Security] Securing the laptop: DoS

Simson Garfinkel simsong at acm.org
Sun Sep 10 14:51:59 EDT 2006


Carl-Daniel,

Thank you for this message. I'm in the process of preparing a few  
security documents and will be addressing some of these issues. In  
general, you do a good job outlining some of the threats that we've  
been considering. However, what you haven't done is given me a threat  
model --- who do you see launching these threats, and on what scale?

1. Attacks on the battery appear to be unsolvable. How would you  
address them?

2. Our primary concern regarding writes to the NAND flash have to do  
with flash lifetime, rather than using writes as a way of draining  
batteries.

	You write:

>   * Opening a file and running a {modify, fsync} endless loop on it
>     should be able to kill the flash chip in minutes

Are you sure about your calculation here?  My experience with flash  
tells me that we are unlikely to get write speeds faster than 1  
megabyte/second. If the flash is 512MB, and if we have 100,000  
rewrites for every page, then it will take 512 seconds to do a  
complete write, or 100,000 * 512 = 50 million seconds to fail the  
flash (assuming we are going through JFFS2).  10x the bandwidth to  
the flash would give us a failure in 5 million seconds, which is  
still roughly 2 months. Since full-speed writing to the flash would  
make the machine completely unresponsive, and since the machine would  
need to be constantly charged, I'm not sure that this is a realistic  
threat.

If the attack software has root, then it could bypass JFFS2 and just  
rewrite critical sectors repeatedly. Now the threat is more realistic  
--- assuming 1 megabyte/second write speed, a single 4k page could  
now be rewritten 256 times a second. So now we might be able to get  
it to fail in a little more than 5 minutes.

I'm not sure how JFFS2 would handle the failure of key pages here or  
there, but overwriting the partition table would probably be pretty  
bad. We've been discussing using some kind of security system so that  
even processes running as root cannot do raw writes to the flash.  
These brief calculations indicate that this is needed.

3. Regarding DoS in a wireless environment: Are you worried about a  
single malicious laptop user, or a worm that propagates and tries to  
DoS a community or country? Since we are using 2.4Ghz unlicensed  
technology, we can't prevent a small-scale DoS attack: microwave  
ovens, illegal 802.11 amplifiers, cordless phones, and even  
communications equipment operated by some governments all present  
threats to wireless connectivity.

	If you are worried about a large-scale worm doing a DoS attack ---  
well, there are a lot of things that a worm could do, and running a  
wireless DoS is just one of them. We need to start attacking this  
problem by minimizing the opportunities for worms in general.

4. Regarding malicious firmware to the wireless chip: Yep, this is a  
problem. My understanding is that we will not have source code to the  
wireless firmware. How do you think this should be resolved?

5. Power management:

	You wrote:
>   * 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)

I'd love to get a reference to this, as I never heard of it and I  
would like to use this information in an upcoming presentation.

Also, if this was a problem in 1996, why is it no longer a problem  
today?

6. BIOS Flashing.

You wrote:
> ! 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

One alternative is to have a pre-allocated section of the NAND flash  
that is only used for this purpose. Another alternative, I guess, is  
to put the BIOS update in RAM and do a reboot that doesn't wipe out  
the RAM. (I'm assuming that it would be easier for the Linux bios to  
look for a digitally-signed file in RAM than to load up JFFS2 and  
risk that exploit.) Do you think that such an approach is warranted?

We see to be depending awfully hard on JFFS2. On the other hand, file  
systems are pretty well-defined creatures. Are you familiar with  
model checking technology? Do you think that it is worth while to do  
some model checking on the JFFS2 implementation and try to find bugs  
and possible exploits in it?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2413 bytes
Desc: not available
Url : http://mailman.laptop.org/pipermail/security/attachments/20060910/fae614dd/smime.bin


More information about the Security mailing list