News - Scientists demonstrate malware designed to attack specific CPUs

[HEXUS]

OS-agnostic attacks could be the future of malicious software.

Read more.

[TheAnimus]

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.

[miniyazz]

Wait, my computer gets a different result than my phone when calculating the same thing?

[BullDogg]

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.

[TheAnimus]

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.

[Steve]

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 [types of] 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.