facebook rss twitter

Scientists demonstrate malware designed to attack specific CPUs

by Pete Mason on 11 November 2010, 16:45

Quick Link: HEXUS.net/qa22i

Add to My Vault: x

We all know how the old argument goes - Windows is full of holes, Linux is built like Fort Knox and OS X makes anti-virus software unnecessary. None of this might matter for much longer though, as computer scientists at ESIEA in Paris have shown that it could be possible to create malware that can target a specific CPU, regardless of the OS.

Though these kind of attacks are still some way off, the team, led by Anthony Desnos, demonstrated (PDF) a way in which they could theoretically work. The hard part, apparently, is to identify which processor it is that's being used. To achieve this, the researchers took advantage of the unique way in which different chips - or at least families of chips - calculate certain values.

In this case, the team calculated sin(10^χ π) for various different numerical values of π, which enabled them to pinpoint a specific family of processors. At that point it would just be a matter of running the malicious code on the CPU.

The researchers commented that, using this technique, it would be possible to "enable far more precise and targeted attacks, at a finer level in a large network of heterogeneous machines but with generic malware".

Even though the team has yet to find a method of identifying specific processors, it does open the door for further research into OS-independent malware. It also raises a lot of further issues, including how to defend against such an attack and the reality of a virus targeted against mobile devices.

For those interested, Technology Review offers a more detailed analysis of the paper.



HEXUS Forums :: 5 Comments

Login with Forum Account

Don't have an account? Register today!
err am I missing something? FSINCOS can let them see the family of the CPU. Oh horror.

A buffer overflow is often more dependant on the compiler and OS than how to differentiate between an Atom and a i7.

There was the whole thing a while ago, someone with physical access could potentially determine the result of a calculation they shouldn't by looking at tiny variations in the voltage, and then by seeing how the pipelining changed, but that would require knowledge of everything else on the machine, not just the OS but EVERY module running.

Compared to that knowledge of every process (heck a decent VAX team decened OS won't even let you know the pid/name/anything of a process your not able to know about) is far more worrying that guessing my CPU family.

Fail to really see the story? Am I just lacking imagination.
Wait, my computer gets a different result than my phone when calculating the same thing? :confused:
TheAnimus
Fail to really see the story? Am I just lacking imagination.

You probably know far more about it than me, but I recommend you either go read the original paper or the detailed analysis. These guys are computer scientists specialising in malicious software, so I trust that if they think it's important enough to publish a paper on, it probably is. I can't for the life of me tell you why though.

As far as I can tell, it's not to do with the complier or OS, and that's the whole point. You can run the code directly on the CPU without interacting with the OS at all. But again, I'm not entirely sure. This is just the first step saying that it MIGHT be possible.
Which OS lets you do that? If your outside of the usermode, and in kernel mode (ring 0) even that is ‘fettered’ by the OS.

Also an academic publishing a paper that is pointless, who'd have thought it.
I was about to yell “CPUID”, but the paper has that one covered:
The Intel Assembly Language instruction CPUID can be used both on Intel
and AMD processors, but it has at least two severe drawbacks:
– it is easy to “find” it whenever scanning the file (malware detection issue);
– some other processors cannot recognize and process this instruction.
Very quickly reading the paper, it looks like they propose that the method would be used for “surgical strikes” against particular machines, so it's more about identifying what to attack, rather than identifying the processor to enable them to use a particular exploit.

So, TheAnimus' point about buffer overflows remains true, but it doesn't appear they care about that. However, if for your malware to be successful it depends on a particular OS/app bug to embed itself, what's the point of an OS/app agnostic CPU identification process, unless perhaps it simplifies the process of writing malware?

Flipping the coin, and assuming you did want to attack a particular processor because of the fact that processor P enables you to use some exploit X, would that be possible? Well, modern microarchitectures are so damn complicated and the errata run for pages, so it wouldn't surprise me if this was so. Then again, microcode, BIOS and OS updates are usually put in place to work around the most serious of these.

As for using dynamic power analysis as an attack on systems, I've seen just how weak smart card and chip & pin devices are - it's scary. Using it on a bigger system? I think once your attacker has physical access to the system, you probably have other things to worry about, although I guess it's a case of whether a DPA attack on such a complex system is less effort than breaking the encryption on whatever link it is you have access to tap into.

Disclaimer: I skipped over most of the paper, as it was 8:10 in the morning and too early to be digesting formal definitions of polymorphic virii.