Threats and Mitigation: Difference between revisions

From OLPC
Jump to navigation Jump to search
No edit summary
(Replacing page with 'Update: Since the Bitfrost spec has been published, a new document, Correlating Bitfrost and Threats has been created to critique the spec in light of the points made h...')
Line 1: Line 1:
Update: Since the [[Bitfrost]] spec has been published, a new document, [[Correlating Bitfrost and Threats]] has been created to critique the spec in light of the points made here. Below is (approximately) the original T&M document. It makes a reference to the old Security Home Page, which has apparently (and appropriately) been supplanted by a Bitfrost introduction.
Update: Since the [[Bitfrost]] spec has been published, a new document, [[Correlating Bitfrost and Threats]] has been created to critique the spec in light of the points made here. Below is (approximately) the original T

While there are some fine general principles for OLPC security on the Security Home Page, there are neither discussions of concrete threat models nor concrete recommendations for mitigating such threats. This missive is intended to take a step toward filling in these blanks.

It is understandable, even sensible, that OLPC has not taken security too seriously. Conventional security tools and strategies cost much yet gain little. They are virtually worthless for adults much less children, as evidenced by the huge rates of infection on home pcs in the USA. For a project running at breakneck pace to meet its rendezvous with destiny, disregarding security may have been the right decision; time will tell. But there are consequences. This missive proposes steps to mitigate those consequences. But first one must argue persuasively that there are indeed consequences, else, why even bother to mitigate? So there are 4 parts here:

* Why would anyone attack an OLPC computer anyway?
* Isn't Linux a solution already?
* What are the likely consequences?
* How do we mitigate the harm that will be done?

In order, then:

== What possible reason would someone have for attacking OLPC computers? ==

The glib answer is, people will break OLPC computers for the same reason they climb Everest: to show they can. But this far underestimates the problem. There is now a professional cracking community earning millions in annual revenue by building zombie armies. One major cash cow is in the leasing of zombies to serve as spambots: in 2005 (the last time I knew the numbers), the market rate for a spambot was $3/month. The value of a 5M-box OLPC zombie army, by this reckoning, is over $150M per year. Even if an OLPC is worth less than the market rate, it is still a worthy revenue stream. You can rest assured that professional crackers are among the first to download the Sugar emulators, to get a head start in the fierce upcoming competition to capture these boxes first.

"But," you object, "OLPC computers have poor international connectivity. They'll be useless for spamming the rich countries." Alas.

I have a friend in the consumer marketing field, specializing in postal advertising (junk mail). He loves -- absolutely adores -- postal campaigns in poor countries. Though the desperately poor have far less disposable income, their naivete wrt modern advertising techniques compensates for this.

Advertisements that are scorned and discarded in the USA are read eagerly and believed profoundly in the third world. They have not been immunized. It is mildly similar to unleashing smallpox on the Incas.

Large numbers of poor people can make a few people rich indeed. As those with long memories may remember, Nestle made a fortune persuading the poorest African mothers that artificial baby milk was better than natural baby milk, until driven by an international grassroots boycott in the western world to desist. OLPC zombies will be used, via their mesh networks, to promulgate spam to the most vulnerable populations in the world. The most ethical of these spammers will have morality barely comparable to Nestle. The worst will focus on outright fraud, such as the nigerian hoax in its many guises.

Bottom line: OLPC zombies will be worth millions to those with the creativity to surmount the hurdles that some readers will no doubt highlight that stand in the way.

It is time to take special note of the remarkably durable nigerian hoax, one of the kinds of pure fraud that spambots will deliver to OLPC users and their families. This is another big, OLPC-friendly money maker. This attack uses the computer strictly as a very-low-cost comm device. In theory, you could run such hoaxes with paper mail or phones, the only problem being, those comm channels are too expensive given that the rate of success with the hoax is low. These hoaxes remain surprisingly effective even in the USA: a low-income friend-of-a-friend recently borrowed against a credit card for one, despite fierce objections by her friends who knew what it was -- nothing could alter her conviction that "her ship had finally come in ." So we can trivially predict that zombies acting as spambots to deliver nigerian hoaxes will produce tragic consequences.

== What About Linux? ==

Linux advocates like to point at the low rates of viral infection, the superior quality of coding, and the strong separation of user from root, and say security is a solved problem. Alas.

None of this makes hardly any difference. Neither the nigerian hoaxes, nor the most popular viral zombification techniques notice these features.

Linux desktops have been protected by their small numbers, their sophisticated users, and their nonhomogeneity even while all running Linux. At a single stroke, OLPC wipes the board clean of all these impediments to profitable cracking. For OLPC, the viruses will not be written in Visual Basic to read Outlook address books. they will be written in python to read Sugar address books.

OLPC viruses will not bother trying to get root privilege (unless it is easy). Thinking root priv is crucial is old-fashioned mainframe thinking.

Root-priv is fun (we will explore some cool games later), but unneeded. On a single-person computer, all the good stuff (passwords, financial accounts, address books, network connectivity) is in the user account. OLPC viruses will appear as email attachments and web links, and will write themselves to the startup profile. They will run only when the user is logged in ... but since the user is logged in just about any time the computer is turned on, this is a barely noticeable drawback.

Alas. The problem is worse than this. If just one root-escalation breach can be found during the lifetime of the computer, something that works from a user account, this breach can be propagated at light-speed across the mesh to all user-level zombies. The resulting individual root zombies can then hoist their user systems into virtual machines, and become effectively indetectable.

Who wants to bet that not a single such breach will be identified?

Meanwhile, the nigerian hoax is an almost pure social attack. Neither Linux nor any security modification to the individual computer -- not even the radical mods for which this author has achieved some infamy -- can help. The answers lie elsewhere.

== Consequences ==

To make the consequences concrete, I offer the following predictions:

* One year after shipment of 5M OLPCs, at least 50% of OLPC computers will be infected by viruses. This is a modest prediction, considering that the infection level for home PCs in the US is actually higher than this.
* One year after shipment of 5M OLPCs, at least $1M will have been stolen via OLPC computers using variants of the nigerian hoax. If one OLPC computer in a thousand is used to run a $200 scam, this will be achieved.

If at this point one finds these predictions credible and unpalatable, it is time to assess mitigation possibilities.

== Mitigation proposals ==

Herewith are 4 mitigation proposals falling int 4 categories:

* Immediate mitigation of nigerian hoax risk.
* Immediate preparation for long term mitigation of root-priv zombification risk.
* Immediate preparation to slightly lessen short term user-level zombification risk.
* Long term serious solutions

=== Immediate nigerian hoax mitigation ===

The nigerian hoax is the threat with the most severe consequences for the families of OLPC owners. Severe hardship is a common consequence for the victim of this hoax. The hoaxthreat is also the hardest threat to eliminate. Fortunately, it may be an easy threat to mitigate.

The best place to defeat the hoax is in the mind of the intended victim. How? With educational tools shipped on the OLPC itself. Suppose the computer had a training course that taught each student-owner how to run the hoax himself. Suppose there were group exercises for the students to practice hoaxing each other. Surely this would reduce the number of victims. How much reduction would it achieve? Can the $1M theft prediction be made false?

=== Immediate preparation for long term mitigation of root-priv zombification ===

Once a trojan horse becomes root and hoists the user to a vm, there are only 2 solutions: throw the computer in the river, or boot off an external medium to overwrite the infected os.

There is a crucial hardware requirement to save the computer: the initial boot sequence that allows boot media selection must be inviolate. If the os can rewrite the firmware for the boot, it can fool both user and boot media into thinking the base os has been replaced when in fact the fresh os install has been routed to the same vm compartment used to fool the user in the first place.

There is a good chance that the OLPC bootware already cannot be corrupted by the OS. But this cannot be left to chance or guesses. Do not let crackers be the first to figure it out.

Another person has added more detail to the needs for protecting the bootware/firmware, now at [[Bootware Firmware Security Issues]].

=== Near term preparation to mitigate user-level zombification risk. ===

It will marginally help mitigate zombification if the OLPC software team maintains a list of all the places and ways that executable code can be stored to launch at logon. Then make a list of all the things that belong in each location. Virus checkers can be written with this as a starting point for disinfection.

This will frankly not help much. Virus checkers are "barn door security", i.e., you've already lost if you're doing this. Hard problems required serious solutions, not patches.

=== Long term serious solutions ===

The only serious solution to the problems of viral infection and nigerian hoaxing known to this author requires 2 transformations to today's techscape:

==== The user+computer partnership has to be made virus-hostile. ====

It is possible to make computers extremely virus hostile with positive impact on the user experience by bundling authority with designation to enforce the Principle of Least Authority. This approach is demonstrated by 2 very different though related systems, Polaris (at http://www.hpl.hp.com/techreports/2004/HPL-2004-221.html) and CapDesk (at http://en.wikipedia.org/wiki/CapDesk). Full disclosure: the original author of this missive was largely responsible for both of these systems.
In systems like these, even such shocking lapses of computer hygiene as the launching of executable attachments is safe. Viciously hostile software can be used for productive purposes with limited risk. The attacker's job becomes significantly harder, while the user may not even notice a change in operation (demonstrated in the field during the Polaris pilot program).

==== Make attack unprofitable ====

Hardening of the user+computer partnership is necessary but insufficient. Even if we reduce the current individual vulnerability by a factor of 1000 (which the author considers both necessary and, barely, possible), with tens of millions of computers this still means hundreds of breaches, still enough to flood the mesh with spam, still enough to sucker profitable numbers of hoax victims.
To finally eradicate these attacks we need to remove the profit. Again the author knows only one enduring solution. Add a very lightweight digital token economy to the system (the author recommends the IOU protocol, at http://www.hpl.hp.com/techreports/2006/HPL-2006-5.html, very light and easy for end users, largely because it is authorization based, not authentication based, so avoids all the madness with large user name spaces, passwords, and certificate authorities that have killed so many digital cash systems). Then enable filtering of incoming email and chat based on token allocation. This effectively puts a user-specified "postage" token price on the privilege of delivering mail from strangers (white-listed senders bypass the token filter). If the hoaxer must pay for the privilege of each attack, and the ratio of successful attacks falls below the threshold for profitable attacks, such attacks will necessarily cease.
Combining lightweight tokens with virus-hostile user+computer partnerships, we can break the back of cybercrime. We can finally make cyberspace a safe, well-lighted place to work and play.
Marc Stiegler (and others)


[[Category:Security]]

Revision as of 00:03, 12 June 2007

Update: Since the Bitfrost spec has been published, a new document, Correlating Bitfrost and Threats has been created to critique the spec in light of the points made here. Below is (approximately) the original T

Retrieved from "http://wiki.laptop.org/mediawiki/index.php?title=Threats_and_Mitigation&oldid=42933"