Ed's an EE, PE, and author in Poughkeepsie, NY. Contact him at [email protected] with "Dr Dobbs" in the subject to avoid spam filters.
Desktop computer operating systems must be optimized for mass-market distribution to folks who have neither the interest nor the skill for customization. As a result, any given user may take advantage of only a fraction of the available programs, but every user will find a suitable fraction.
For example, Windows versions differ largely in their go-fast stripes. The top bullet item for Windows Media Center boasts, "A clean, new look for menus, taskbars, and a host of new themes and screensavers," which tells you what's really important to their marketing folks. While the exterior may look different, it has much the same assortment of stuff under the hood.
Early GNU/Linux distributions took this to an extreme by installing not only the kitchen sink, but every sink created since primordial UNIX crawled ashore, plus a broad assortment of plumbing and sculpting tools should you become desirous of building your own sink.
Recent distros have reined in this tendency, if only because a program that's not present can't become a security exposure. A secondary benefit accrues to new users suffering a case of "the crazy you get from too much choice" when confronted by a dozen editors, half a dozen browsers, and four CD burners. That's less of an issue with stock Windows boxes, which are downright feature-poor by comparison.
Classic embedded systems take this to the other extreme, sometimes consisting of a single program in ROM. Perhaps a decade ago, the need for an operating system became obvious in larger projects, and five years ago, Do-It-Yourself (DIY) operating-system designs reached the far limits of typical DIY ability.
By now, old-line embedded OS and RTOS vendors are tarting up their offerings to attract DIY designers who'd otherwise pick Linux, embedded Linux vendors are adding real-time features to entice escapees from per-unit RTOS royalties, and doughty DIY folks are scratch building Linux kernels.
One thing is clear, however: Larger and more complex embedded systems have more places for things to go wrong. Data points from the desktop world can therefore help us predict problems in the embedded realm, if only we look closely at the trouble. While the sight may not be pretty, averting our eyes won't help.
High Warble
My desktop PCs run SuSE Linux, but I keep a token Windows laptop around for those few vital programs without a GNU/Linux equivalent. Therefore, I subscribe to both the SuSE Security Announcement and the Microsoft Security Bulletin e-mail lists, which provide regular doses of problems and fixes.
Each problem includes a number that uniquely identifies it in the MITRE Corporation's Common Vulnerabilities and Exposures (CVE) list. Because the same problem may occur across many different versions and types of operating systems, the CVE number (oddly, with a CAN- prefix) helps reduce the inevitable confusion about which bug you're discussing.
First, a pair of broadsides.
CAN-2005-1206: Buffer overflow in the Server Message Block (SMB) functionality for Microsoft Windows 2000, XP SP1, and SP2, and Server 2003 and SP1 allows remote attackers to execute arbitrary code via unknown vectors, aka the "Server Message Block Vulnerability."
CAN-2004-1137: Multiple vulnerabilities in the IGMP functionality for Linux kernel 2.4.22 to 2.4.28, and 2.6.x to 2.6.9, allow local and remote attackers to cause a denial of service or execute arbitrary code via (1) the ip_mc_source function, which decrements a counter to -1, or (2) the igmp_marksources function, which does not properly validate IGMP message parameters and performs an out-of-bounds read.
These errors permit a remote attacker, one not sitting at your keyboard, to execute arbitrary code, the current euphemism for "do a hostile takeover." Because any embedded system complex enough to require an operating system will also be networked, these are particularly severe errors.
Direct network-to-kernel attacks are fairly rare, however, because kernel code receives a fair amount of scrutiny. Generally, an attacker must compromise another networked program, which is particularly easy on the desktop: Folks really like their music.
CAN-2004-0258: Multiple buffer overflows in RealOne Player, RealOne Player 2.0, RealOne Enterprise Desktop, and RealPlayer Enterprise allow remote attackers to execute arbitrary code via malformed (1) .RP, (2) .RT, (3) .RAM, (4) .RPM or (5) .SMIL files.
If you can imagine a large-scale embedded system running a music player, it's equally easy to see why it might run unattended. If not music, then surely the system uses pictures?
CAN-2005-1211: Buffer overflow in the PNG image rendering component of Microsoft Internet Explorer allows remote attackers to execute arbitrary code via a crafted PNG file.
Now we're talking! Internet Explorer is less a separate program than a thin GUI film atop a seething mass of Windows DLLs. Because DLLs were intended for reuse, I suspect any program dealing with PNGs will smack into that error. In any event, if an attacker can force-feed a bad PNG into that DLL, your system's control goes with it.
CAN-2004-0981: Buffer overflow in the EXIF parsing routine in ImageMagick before 6.1.0 allows remote attackers to execute arbitrary code via a certain image file.
That trick requires more effort than with IE, but I can see an embedded system doing image processing for other boxes.
Notice any similarities so far?
Programmed Injection
Many help-desk sites use NNTP news servers for support discussions. If you can imagine reading news from an embedded system, here's an attack path.
CAN-2005-1213: Stack-based buffer overflow in the news reader for Microsoft Outlook Express (MSOE.DLL) 5.5 SP2, 6, and 6 SP1 allows remote malicious NNTP servers to execute arbitrary code via a LIST response with a long second field.
Do you prefer instant messaging?
CAN-2005-1261: Stack-based buffer overflow in the URL parsing function in Gaim before 1.3.0 allows remote attackers to execute arbitrary code via an instant message (IM) with a large URL.
Both of these seem to require a successful server compromise to put an attacker on the far end, or at least a deliberate conversation with a Black Hat. Alas, even if an embedded system has fixed URLs for its upstream servers so that it will fetch and store data only in machines you control, there's another route into your system. When you use the Internet and OPC, you're dependent on everything working correctly, even stuff you didn't know existed.
CAN-2000-1218: The default configuration for the domain name resolver for Microsoft Windows 98, NT 4.0, 2000, and XP sets the QueryIpMatching parameter to 0, which causes Windows to accept DNS updates from hosts that it did not query, which allows remote attackers to poison the DNS cache.
Similar flaws in UNIX-flavored DNS server code permitted an exploit at the nameserver, allowing an attacker to redirect your packets to a hostile server without the inconvenience of first cracking your box. Given control of your data, the rest is easy.
It's even easier getting in when the door isn't locked.
CVE-2002-0676: SoftwareUpdate for MacOS 10.1.x does not use authentication when downloading a software update, which could allow remote attackers to execute arbitrary code by posing as the Apple update server via techniques such as DNS spoofing or cache poisoning, and supplying Trojan Horse updates.
Both of these sound like errors of omission, rather than coding errors, but I remain amazed that nobody's pulled off a similar stunt with Windows Update or Symantec Liveupdate. Should you plan to keep your embedded systems patched using a similar mechanism, remember that strong crypto forms a necessary, but not sufficient, foundation.
Exploitation
Common wisdom has it that UNIX systems will suffer less damage from an attack than a Windows box. Although Windows distinguishes between "Administrators" and "Users," in actual practice, you can't get much done without being an Administrator and some programs simply won't run for ordinary Users. As a result, Windows users generally have full Administrator privileges that translate any rogue code into a total system compromise.
UNIX-style users have severely limited access to the system's gizzard and, because that's the way it's supposed to be, users can run all the programs they should and none of the rest. Even so, if a user has write access to files used by others, an attacker can cause considerable damage without killing the system.
Unfortunately, even on Linux boxes, once an attacker gains any access to the system there's little standing in the path to root-dom. If all else fails, a carefully scripted crash will work.
CAN-2005-1263: The elf_core_dump function in binfmt_elf.c for Linux kernel 2.x.x to 2.2.27-rc2, 2.4.x to 2.4.31-pre1, and 2.6.x to 2.6.12-rc4 allows local users to execute arbitrary code via an ELF binary that, in certain conditions involving the create_elf_tables function, causes a negative length argument to pass a signed integer comparison, leading to a buffer overflow.
Common Causes
If your similarity sense is tingling by now, there's a good reason. With the possible exception of those DNS and Mac errors, the attacks come down to buffer overflows in C programs. It's easy to blame this on poor coding practices, but the real problem lies elsewhere.
Ideally, the language you pick for your next application would be the one that simplifies the solution so that your code becomes obviously correct. Yes, you can write a GUI app in Assembler or a business application in APL, but that's going about it the hard way.
A quick check shows that something like 2500-odd programming languages have come and gone in the last half-century. Although old languages rarely die or completely fade away, face it, APL just isn't in your future. Assembler, now, maybe that's a different story.
Anyhow, Hobson's Choice dictates using either C++ (C# for folks in the dot-Net gulag) or Java. Deep embedded stuff still happens in C, with C++ gaining traction for big projects. You'll find a zillion other languages complete with zealous partisans, some of whom I'll hear from within the next week, but to a good first approximation, it's a C-style language or nothing.
And there's the problem. As Kernighan and Ritchie put it in The C Programming Language, "C is a relatively 'low-level' language." Before you can tackle large-scale problems, you must first acquire the scaffolding required to support those abstract concepts. Unfortunately, while you're concentrating on the abstractions, the low-level details still matter.
C++ slathers a (massive) layer of abstraction atop the same low-level language substrate to provide the worst of both worlds: The arrogance of high-level semantics deployed on fragile syntax. Even a trivial mistake can clobber the entire system, generally providing good war-story fodder.
CAN-2005-1974: Unknown vulnerability in Java 2 Platform, Standard Edition (J2SE) 5.0 and 5.0 Update 1 and J2SE 1.4.2 up to 1.4.2_07 allows applications to assign permissions to themselves and gain privileges.
Sun's description adds a few more details to that spare note.
A vulnerability in the Java Runtime Environment may allow an untrusted applet to elevate its privileges. For example, an applet may grant itself permissions to read and write local files or execute local applications that are accessible to the user running the untrusted applet.
Even if you eschew C, it can still clobber you.
Ground Rules
While it's easy to blow off desktop problems as irrelevant to embedded systems, that's simply ignoring some conspicuous evidence of trouble ahead. None of the problems in the MITRE list got there because somebody thought it'd be cool to leave that error in the code, okay?
If you're using C, which is highly likely for a typical embedded system, you must assume that the language is working against you. Establish a style guide, turn on all the compiler's checks, use Lint, shake your heap, do everything you can to flush out errors before they hit the field. Keep in mind that all those errors came from folks who are at least as smart as you are and who thought they knew what they were doing, too.
If an attacker can gain sufficient access to your system to run a program, even a crash can compromise the kernel. An unattended box that automatically restarts after a crash may remove any evidence of the compromise, while leaving the attacker in control.
If your embedded system controls a valuable device or provides a critical service, it will attract more highly motivated attackers than a typical desktop box. Worse, they may value the system for reasons that have nothing to do with its code or data, as demonstrated by the myriad compromised Windows boxes on the Internet.
Indeed, a clever attacker may leave the normal functions running, while siphoning off CPU cycles and a little network bandwidth. Perhaps the recent decrease in zombie attacks simply means a million PCs are quietly cracking somebody's crypto instead?
If your device depends on an Internet-facing server for critical functions or updates, your security strategy must succeed despite a complete compromise of the other end of the conversation. In fact, you cannot assume the Internet infrastructure has your best interests in mind.
Even if you're using, say, Oberon (possible, but so weird that you'll certainly confuse the attackers, not to mention any bystanders), keep in mind that any system has flaws. You must provide an in-depth defense, so that a single catastrophic failure doesn't provide a direct route to the kernel.
That'll make for a good story, too.
Reentry Checklist
Windows Media Center features appear at http://www.microsoft.com/windowsxp/mediacenter/evaluation/features.mspx.
That quote's from Joni Mitchell in "Barandgrill" on her For the Roses album.
The Microsoft TechNet Security Center is at http://www.microsoft.com/technet/Security/default.mspx and SuSE's security announcements are at http://www.novell.com/linux/security/securitysupport.html.
Mitre's Common Vulnerabilities and Exposures list is at http://cve.mitre.org/. The CAN-prefixed numbers I use will change to CVE-prefixed numbers at about the time you read this, so adjust your searches accordingly. The first four digits of each CVE number indicate when the number was allocated, so it's entirely possible to have an old- looking CVE record holding a new error.
More than you want to know about APL starts at http://burks.bton.ac.uk/burks/language/apl/. You can find your favorite language at http://people.ku.edu/ ~nkinners/LangList/Extras/langlist.htm and download a genealogy poster from http://www.oreilly.com/pub/a/oreilly/news/languageposter_0504.html.The Oberon home page is at http://www.oberon.ethz.ch/.
DDJ
