[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