Kaspersky To Demo Attack Code For Intel Chips

snydeq writes "Kris Kaspersky will demonstrate how attackers can target flaws in Intel microprocessors to remotely attack a computer using JavaScript or TCP/IP packets, regardless of OS. The demo will be presented at the Hack In The Box Security Conference in Kuala Lumpur in October and will show how processor bugs can be exploited using certain instruction sequences and a knowledge of how Java compilers work, allowing an attacker to take control of the compiler. The demonstrated attack will be made against fully patched computers running a range of OSes, including Windows XP, Vista, Windows Server 2003, Windows Server 2008, Linux, and BSD. An attack against a Mac is also a possibility."

Comments

They may

[Sycraft-fu]

Their new processors can have their microcode updated, and indeed they do update it with BIOS updates. Dunno if people would bother to update their BIOS to patch it, but yes Intel processors can be patched in the field.

Re:They may

[Gazzonyx]

Yeah, most Linux distros have a microcode update service, although it has to be enabled in the kernel at compilation time, IIRC.

Re:They may

[AcidPenguin9873]

Only some things can be fixed via a ucode patch, others cannot. See AMD's TLB errata for an example of something that cannot. Other things can be fixed by disabling a feature, but disabling that feature might cost performance. Once again, see AMD's TLB errata for an example. Still other things can be worked around in the OS, sometimes for negligible performance loss, sometimes not. The Intel F00F bug was a perfect example of something that could be worked around in the OS with no performance loss, and the AMD TLB errata had an OS workaround too which incurred a small (1%?) performance loss. Other things have almost no workaround, and require Intel or AMD to recall silicon and give out new processors. Intel's Pentium FDIV bug was a good example of that. It depends entirely on what piece of the chip is at fault.

If something can be fixed in ucode for a negligible performance loss, or worked around in the OS for a negligible performance loss, that's the best-case scenario for Intel. In that case it's just a matter of getting BIOSes/OSes updated and patches rolled out to OEMs.

Re:Java or Javascript?

[MindStalker]

The official conference website says the same thing
http://conference.hackinthebox.org/hitbsecconf2008kl/?page_id=214

Reading the conference website sounds like he is saying the can crash computers through forced tight loops via multiple languages, javascript, java, even TCP/IP

It must depend some on the OS

[jd]

For starters, OS' running on either virtual or simulated processors rather than physical ones won't necessarily use the physical instructions that have the vulnerabilities, no matter what the physical processor that the OS is technically using. (If I run Linux under ArcEm, and run ArcEm on an Intel processor, unless ArcEm itself uses the broken instructions, I cannot see how an attacker can reach the Intel processor from the Linux environment for the attack to take place. This is important because the composite environment is nothing more than a really heavy, multi-layer OS as far as the applications are concerned, and this attack is supposedly independent of OS.)

If it's via Java, then it must also depend some on the implementation. I doubt that IBM's java engine uses the same calls to the processor as Sun's, which means that there is further abstraction that the claim has to somehow deal with.

Now, on the opposite side of the argument, there's the issue of what happens if the claim is justified. If this is a remote exploit that is truly OS-independent, then it is a remote exploit that can hit OpenBSD, Trusted Solaris, and other secure OS'. These are OS' used for commercially-sensitive work and classified work. If they are potentially vulnerable to attack, that could seriously impact a lot of organizations that, well, really aren't going to like it. In the event of a conflict flaring up between Intel and the US Marines, we may see them moving the bombing practice areas for their aircraft into the North American mainland after all.

Re:It must depend some on the OS

[the_brobdingnagian]

Now that you mention OpenBSD, I recall an email from Theo de Raadt (2007-06-27 17:08:16 - source):

Note that some errata like AI65, AI79, AI43, AI39, AI90, AI99 scare the hell out of us. Some of these are things that cannot be fixed in running code, and some are things that every operating system will do until about mid-2008, because that is how the MMU has always been managed on all generations of Intel/AMD/whoeverelse hardware. Now Intel is telling people to manage the MMU's TLB flushes in a new and different way. Yet even if we do so, some of the errata listed are unaffected by doing so.
As I said before, hiding in this list are 20-30 bugs that cannot be worked around by operating systems, and will be potentially exploitable. I would bet a lot of money that at least 2-3 of them are.

And from TFA:

"It's possible to fix most of the bugs, and Intel provides workarounds to the major BIOS vendors," Kaspersky said, referring to the code that controls the most basic functions of a PC. "However, not every vendor uses it and some bugs have no workarounds."

Sounds like the the same issues to me.

Re:It must depend some on the OS

[grcumb]

Now that you mention OpenBSD, I recall an email from Theo de Raadt (2007-06-27 17:08:16 - source):

As I said before, hiding in this list are 20-30 bugs that cannot be worked around by operating systems, and will be potentially exploitable. I would bet a lot of money that at least 2-3 of them are.

People have been aware that microprocessor bugs are potentially quite dangerous for some time now. Here's a write-up of Adi Shamir's report to RISKS about using processing bugs to steal private encryption keys.

Re:Speculative

[Anonymous Coward]

An attack against a Mac is also a possibility

That's a bit of a conjecture isn't it? Can we at least have a demonstration?

OMFG! From the summary:

Attack Code For Intel Chips ... regardless of OS

Re:Publicly available?

[pclminion]

I see, so your argument is that if it can't be fixed by the discoverer, they should keep it obscure. That way, there is no incentive for the vendor to solve the problem since they don't even know about it. Thus, leaving the door open for other nasty people to discover it and exploit it with nobody aware it is even possible. Good plan you got there.

i've read a number of story summaries in my time

[circletimessquare]

and this one ranks among the hallowed few best described as "excuse me, i just crapped my pants"

Re:Im sure his Anti Virus will stop it :)

[Clandestine_Blaze]

Im sure his Anti Virus will stop it :)

I initially made that mistake too, but Kris Kaspersky != Eugene Kaspersky

Kris is a security researcher and author.
Eugene is the guy behind Kaspersky Lab.

I wish the article had made the distinction, since some people are more familiar with Kaspersky the anti-virus creator and not the author.

Though this does remind me of the urban legend that anti-virus companies are behind all of the anti-viruses:
http://xkcd.com/250/

Re:That's Nothing, This November I'm Going To...

[Anonymous Coward]

Err, Kris Kaspersky has a good reputation and does write pretty good books.

Re:That's Nothing, This November I'm Going To...

[TheRaven64]

The Core and Core 2 both have serious errata relating to how they handle virtual memory. It is possible to violate page and segment protections using these, although it is not obvious how to do so in a way that does anything other than crashing (i.e. there is a quite difficult possible DoS and may be a very difficult arbitrary privileged code execution hole). This requires running arbitrary (unprivileged) code, but apparently he's found a way of generating the required code in a JVM.