CPU Bugs, Patches and Vulnerability

By Larry Seltzer  |  Posted 2007-06-29 Print this article Print

Opinion: CPUs, like software, have always had bugs. The security implications of this are a relatively new problem, and open-source users may be at a disadvantage.

Its not your average bug report and patch. Its your CPU that has a problem, and people are debating how serious it is. CPU bugs are nothing new. Around 1990 I spent a day with an IBM programmer who worked on the companys DOS versions, and he wouldnt shut up about how buggy some of the Intel CPUs were and how they screamed to Intel about them (to no avail). Its all part of the job of writing an operating system, but the security angle on it is a relatively new one.

The outspoken Theo de Raadts blog on the subject has been widely cited on security lists. de Raadt calls the Core 2 CPU line "buggy as hell" and promises that the problems being patched are not innocuous bugs but security issues that will be exploited, and from userland code at that. This means that an exploit may require local access to run code, but not privileged access.

Intels "Specification Update" on these processors contains an errata section that has many of the bugs fixed. de Raadt refers to some of the errata as scary. From what I see of them they could lead to processor hangs or "unpredictable system behavior." Lets assume for the moment that Intel is being honest and accurate; these dont seem especially scary to me, even if they are clearly a problem.

As Microsofts Michael Howard recently said about denial-of-service attacks, crashing someones system is like ringing a doorbell and running away. Youve bothered them, but you havent accomplished anything and youre a little twerp for doing it too. I thought the hacking for fame thing was out of style years ago, so why would someone bother to spread such an attack?

The fixes are in the form of microcode for the processors. It turns out (Im just learning this today) that updates to the CPU microcode can be loaded at run-time, although they are not persistent. The usual way they are applied is by the BIOS at boot time, and therefore the CPU updates can be delivered as BIOS flash updates.

But updates can also be applied by the operating system, and in this case Microsoft has done just that. Knowledge Base article 936357 includes links to what it calls a "microcode reliability update" that it says "improves the reliability of systems that use Intel processors."

Yes, as Valdis Kletnieks explains in this message on the funsec list, Intel leaves room in the processor for transient patches to the CPUs microcode.
About 294K of data, currently 125 chunks. Each chunk is basically: family, model, stepping, checksum, length, <random-looking bytes>. Theres provisions for stripping it down, so if Dell *knows* that a particular laptop may have one of 6 CPUs, and never one of the other 119, it can include only those 6 CPUs in the BIOS. The Microsoft update would of course need to carry all 294K along.

The fact that Microsoft is delivering fixes like this and being so unclear on what its about tells me they think its serious. Well see if the updates show up on Windows Update or Microsoft Update.

Writing a patch like this isnt something that companies like Microsoft can do on their own; microcode is not like regular code, and its apt to change between different versions of the processor or even steppings. Microsoft likely got the various updates from Intel and packaged them up in a single program. Expect similar updates from, for example, Apple, but de Raadt says (and he should know) that "Intel only provides detailed fixes to BIOS vendors and large operating system groups. Open-source operating systems are largely left in the cold."

Im not afraid that processor bugs will turn into a serious vehicle for exploiting real computers. It sounds like a lot of work for what could be a low return. Youre still better off exploiting whatever Microsoft patched last month. But, as de Raadt says, Intel is probably also hiding some errata, and they have a long history of withholding documentation from the public. Who knows how bad the unknown problems are?

Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983. Check out eWEEK.coms for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzers blog Cheap Hack More from Larry Seltzer
Larry Seltzer has been writing software for and English about computers ever since—,much to his own amazement—,he graduated from the University of Pennsylvania in 1983.

He was one of the authors of NPL and NPL-R, fourth-generation languages for microcomputers by the now-defunct DeskTop Software Corporation. (Larry is sad to find absolutely no hits on any of these +products on Google.) His work at Desktop Software included programming the UCSD p-System, a virtual machine-based operating system with portable binaries that pre-dated Java by more than 10 years.

For several years, he wrote corporate software for Mathematica Policy Research (they're still in business!) and Chase Econometrics (not so lucky) before being forcibly thrown into the consulting market. He bummed around the Philadelphia consulting and contract-programming scenes for a year or two before taking a job at NSTL (National Software Testing Labs) developing product tests and managing contract testing for the computer industry, governments and publication.

In 1991 Larry moved to Massachusetts to become Technical Director of PC Week Labs (now eWeek Labs). He moved within Ziff Davis to New York in 1994 to run testing at Windows Sources. In 1995, he became Technical Director for Internet product testing at PC Magazine and stayed there till 1998.

Since then, he has been writing for numerous other publications, including Fortune Small Business, Windows 2000 Magazine (now Windows and .NET Magazine), ZDNet and Sam Whitmore's Media Survey.

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel