An independent security researcher and reverse-engineer, Kris Kaspersky (who doesn’t seem to be related to the eponymous antivirus company) recently declared to have identified a way to leverage these CPU bugs (called erratas in the CPU-jargon) to bypass operating system security mechanisms and either crash the target machine or gain elevated privileges on it. Kaspersky is planning to make an actual demonstration of its proof of concept against various operating system, some of which include Windows but also Linux and BSD and possibly even MacOS by leveraging the documented erratas documented by Intel in the CPU manuals.

Little is known at the moment regarding how convenient and simple it is to make use of these erratas, but Kaspersky declared he was “going to show real working code...and make it publicly available” at the at the upcoming Hack In The Box (HITB) Security Conference in Malaysia, this October.

Disclosing proof of concepts regarding important vulnerabilities has always been subject to many controversies and different opinions in the industry, one of them being that it is irresponsible to disclose important exploits helping hackers to attack and infect systems without giving the time for the vendors to correct the problem and users to apply a patch. It is the opinion I’m inclined to have in most cases and it is one of them.

But in this case, are these erratas even patch-able anyway ? While there are BIOS updates, the BIOS and the processor are two different things and CPU flash updates are not something people see very often, if ever. Fortunately, after the infamous FDIV bug, Intel learned their lesson and the current generation of processors allow their microcode to be updated… and one of the ways to do it is through BIOS updates, after all.

That being said, updating BIOS has traditionally been a sensible and risky task usually even involving booting to a real-mode OS like MS-Dos, and while some PC manufacturers like Dell now provide BIOS updates able to be kicked off right from Windows, most home users are likely to not even realize what a BIOS is and what are the implications of applying the update, which usually comes with its load of discouraging disclaimers and warning written in red text.

Now, in the enterprise, updating hundred to thousands of machines’ BIOS at once and in a hurry is probably going to be quite troublesome as well. First, every distinct computer model is bound to have its own BIOS variant, which will need to be downloaded and properly disposed in specific directories to automate this through scripts. Now, even if the most recent models get provided by BIOS running on Windows, most of them do not support command-line switches. Some manufacturers fortunately provide some ways to do massive and automated BIOS updates, like Dell with its DCCU (Dell Client Configuration Utility) tool. The success of these updates would still have to be tracked though (through network inventory tools or WMI classes, for example).

Nevertheless, all I have listed above certainly looks like a time-consuming process and the best (as far as Windows machines are concerned) certainly would be to get updates from Windows Update or WSUS, but is it possible for an operating system to rewrite the microcode of the processor ? It turns out it is! Both Windows and Linux kernels provide this feature through a microcode update driver and Microsoft already released microcode updates for Intel processors like KB936357, which are of course entirely scriptable and not PC manufacturer/model/motherboard-dependant like a BIOS update is.

The future certainly looks brighter than it initially seemed, but Kaspersky and other CPU experts warn that some of these erratas are not patchable through microcode update since their cause doesn’t lie in the microcode itself, but hopefully, if this exploit is as serious as Kaspersky claims, Intel and other possibly impacted CPU manufacturers will provide reliable updates (better not screw up the microcode update here and kill hundreds of thousands machines in a single day) in a reasonable amount of time and let Operating System companies deploy them through their updates mechanisms.

As I already said earlier, how critical and how usable in real-world conditions this exploit can be used remains to be seen and I really wonder how such a flaw can be used remotely in a convenient and not potentially already locked-down manner (ie. having to run any ActiveX/Java applets). But if it was, it would certainly be a logical evolution for hackers and malwares : the operating systems constantly get more secure and security has become such a big concern that it changed the mindset of many software engineers and companies, which now integrate security right from the design-phase and use automated tools like security-oriented static code analyzers and fuzzy testers to reduce the vulnerabilities occurrences, like Microsoft did with their SDL. These efforts are finally starting to pay off and as the focus on security constantly grows, the only way for software vendors to evade bad reputation is to patch flaws as fast as possible.

As a result, it becomes harder for hackers and the usual malwares to get into systems and using software flaws turns out to become harder and less successful than it used to be and hackers need to find new vectors… and, social-engineering aside, the only alternative to software is hardware…