On February 20, 2013, I was honored with the chance to give a keynote at the Embedded Linux Conference in San Francisco. These are some notes and URLs which back up my comments in the talk.
My first experience with open source operating ssytems was around 1980 when I was in college. At Colorado State University, the entire Computer Science Department ran on a single DEC VAX 11/750. That little Vax 750 was running 4.2 BSD Unix and had 12M of memory. A 32 bit system connected (by UUCP) to the rest of the "network" as it was then.
Like a lot of kids, I found it incredibly cool that I could actually look at the source code for the operating system and understand how it worked without circumventing secrecy laws. This probably helped motivate me to actually go to work in operating systems as a software engineer.
So I've been doing OS work as a professional since the 1980s. And I love it.
Now I'm working in embedded Linux. Funny, but there are a lot of embedded systems which are like that Vax 750: 32 bit architecture, connected to the network, 12M of memory.
And running an open source operating system.
Traditionally embedded devices are considered a different class of beast from servers. It's assumed that the device is a single-function application. It's assumed that you don't need to run new applications like a general-purpose computer. And often, it's assumed that you can hack something together and rush it out the door.
So while I can imagine all kinds of cool ways to use 32 and 64 bit CPUs connected to the network, I also worry about the implications to security and privacy. The intersection of power and carelessness really keeps me awake at night.
Now I'm not a security expert, but I do know several at work. Ryan Ware easily dug up several examples of where we're at risk:
- American and Israeli intelligence officers targetted Iran's nuclear weapons program by attacking the high-speed centrifuges they were using for refinement of uranium. These centrifuges were connected by an internal network with an air gap to the rest of the world. In spite of the challenges, the attack of the centrifuges was very successful, but the resulting virus escaped into the real world, and the result was the famous Stuxnet virus. This was an unintended consequence of course, but the most desructive effects of a lot of viruses are often what the author doesn't expect.
- Viruses like Stuxnet take advantage of so-called "zero day" bugs. These are weak points in the software which are not known when it's released. Once they are discovered, they can be exploited by a bad person or (hopefully) patched by the good people. This recent article shows that there are in fact many more of these than we might first suspect. In fact, according to Ryan, there are on average around 2.5 CVE's per week released on the Linux kernel. That means that whatever Linux-based system you put out there on an embedded device will absolutely have undetected security holes. This is not an indictment of Linux. Because the source code is free and freely available, there are likely to be fewer of these on Linux because you have many people looking at the code and submitting fixes.
- To highlight the problem with these industrial automation controls, here is an example from a company who makes software which is run on power plants and the like. Unfortunately the code will allow someone to gain a shell access very easily. The article talks about over 100 of these systems accessible to the public internet with a cursory search.
- A year ago in a keynote at the Yocto Project Developer Day, Linux Foundation Executive Director Jim Zemlin was highlighting a city which has moved all of their homes to be connected on smart meters. Ironically, the FBI is seeing hundreds.
- Sometimes current events conspire to make your talk more relevant. There have been recent break-ins to sites like the New York Times, the Wall Street Journal and Apple Computer. Just the day before my talk, there was an article posted about a professional group which has been reported to be focused on exploits for critical infrastructure.
There are other examples of course. In future, I'll talk about some of the things which we're trying to do to help in this area from the Yocto Project.