[OLPC Security] Securing the laptop: DoS

[Carl-Daniel Hailfinger]

Simson,

Sorry for not getting back to you earlier. I wanted my answer to
be well-researched and also had to learn for my final university exams.

Simson Garfinkel wrote:
> 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?

Since nearly all of the threats I listed were aimed at making the
laptops unusable for our targets (schoolchildren), there are two main
groups of attackers I imagine:
1) The "because we can" group: People who will attack our security model
  to prove the point that we forgot to consider something. Background
  of these people is probably academic and/or classic creative hacking.
  Impact scale: Low, single machines or just academic papers about the
  threat.
2) The "bragging rights" group: People who want to get peer recognition
  (peers would be script kiddies or crackers or just classmates) and
  maybe even get mentioned in the news. They won't care about any
  (permanent) damage or other ill side effects of their attacks, the
  resources they spend to achieve their goal are disproportionately
  large.
  Impact scale: High, at least a few thousand affected machines per
  instance would be defined as success, but if larger target groups
  are possible, they won't stop at a few thousand machines.
3) (not really one of the two main groups) Politically motivated
  attackers: They disagree with the politics of the project (one laptop
  per child/being based on Linux/"imperialistic tool"/etc.) or the
  politics of the local distribution entity (no distribution to certain
  areas/ethnic groups/political opponents/etc.). Attacks are performed
  to either get media coverage or to "fix" perceived injustice.
  Impact scale: Medium to low. The group of attackers is probably very
  small (if any), their skills and target count are likely to match
  group 2.

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

As Jim Gettys suggested, making power usage informatino available is
going to help kids recognize excessive battery draining. A "power
meter" could show them which activities/programs draw too much current
and they will very soon learn to avoid websites/programs where the
power meter goes red.


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

Indeed. I just tried to give a complete list of the effects of each
attack type, as minor as it may seem.
David Woodhouse addressed your questions, since he is the expert, I'll
leave that topic to him.


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

The single malicious laptop user is not my real worry. I hope such a
user can be located with triangulation (if our hardware supports
accurate signal strength detection, it shouldn't be that hard in an
environment without too much steel).

Non-802.11 signal sources are a harder problem, but I expect that there
won't be too many of them. And as long as these sources are not mobile,
the area around them can be avoided.

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

Yes, of course. However, we have two problems with worms specific to
our environment:
1) A worm targeting wireless connectivity can use that to prevent
  updates or fixes getting applied to any machine in its range, thereby
  protecting itself.
2) Detecting worms once they are active. A few years of dealing with
  this problem have made it clear for me that there is no silver
  bullet. Signature-based detection always arrives too late and
  anomaly-based detection has too high false positive/negative rates.
  As part of my research, I have even created worms which were able
  to cause false positives for uninfected hosts while at the same
  time not being flagged as infected themselves, using both signature
  and anomaly detection. A paper on that will be published soon.

Tightening any "worm holes" is the best we can do now. Active self-
defence is something I'd rather avoid, such mechanisms have been abused
too often in the past.


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

Some of us have access to the source code of the wireless firmware now.
A goal of revision 2 is to rewrite the firmware around an opensource
kernel and release the source code.

Two ways to avoid tampering:
1) Tell the kernel to only upload cryptographically signed firmware.
  This will (maybe) not help you against an attacker who gets root,
  but it is better than nothing
2) Upload the firmware while we're in LinuxBIOS (that will happen
  anyway if we want to boot from network) and block any firmware
  uploads until a hard reboot (can the hardware do that?).


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

Sorry, I couldn't find the article on that problem. I'll keep looking.

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

IIRC most mainboard manufacturers were affected back then and learned
their lesson not to drive parts to their limits in normal use.


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

That was my preferred option so far, however if at least one of those
sectors is worn out, a BIOS update will be impossible. Yes, we can use
error correcting codes and other means to avoid that problem, but that
seems like adding a lot of complexity for such a "simple" task.

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

Interesting idea, but I doubt that we can do it. Especially now that
it seems we might only be able to flash on a cold boot for security
reasons.

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

In general, yes. However I have no idea how advanced the tools are now.
Back when I first encountered model checking, I had the impression
that running these tools on a large body of real-world C code was
infeasible. So I'm not really qualified to make a judgement call on
its use.

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

If it is feasible, I'd suggest to do so. It can only help code quality
(that in no way implies any criticism of the JFFS2 code, I haven't
looked at it yet).


Regards,
Carl-Daniel