Slashdot Mirror
Research Inches Toward Processor-Specific Malware
chicksdaddy writes "The Windows/Office/IE monoculture is disappearing faster than equatorial glaciers — Mac OS X and iOS, Linux and Android ... and whole new application ecosystems to go with each. That's bad news for malware authors and other bad guys, who count on 9.5 out of 10 systems running Windows and Microsoft applications to do their magic. What's the solution? Why, hardware specific hacks, of course! After all, the list of companies making CPUs is far smaller than, say, the list of companies making iPhone applications. Malware targeting one or more of those processors would work regardless of what OS or applications were installed. There's just one problem: its not easy to figure out what kind of CPU a device is running. But researchers at France's Ecole Superiore d'Informatique, Electronique, Automatique (ESIEA) are working on that problem. Threatpost.com reports on a research paper that lays out a strategy for fingerprinting processors by observing subtle differences in the way they perform complex floating point calculations. The method allows them to distinguish broad subsets of processor types by manufacturer, and researchers plan to refine their methods and release a tool that can make specific processor fingerprinting a snap."
Glad no one targets my WinChip CPU for anything.
We need an Al Gore of receding corporate monopolies!
'We are trying to prove ourselves wrong as quickly as possible, because only in that way can we find progress.' RPF
After this report 57 IT representatives quit their job in order to become store clerks.
at least at the start of this next frontier how about testing for the chip profiling software. It's one thing to be able to "detect subtle differences" in floating point operations but another to do it while also trying to avoid detection while you're doing it.
if( 4195835*3145727/3145727 != 4195835 ){
cpu = "Intel Pentium";
}
but...
where actually is the attack vector if you don't target any software platform at all?
It's really bad we have only two and a half CPU architectures in any wide use: armel and i386/amd64 -- and even worse, all smartphones use the former and big machines the latter. Using a different arch gives you extra security (by greatly reducing the amount of existing shellcode) while adding basically no issues whatsoever -- any reasonable server OS is fully portable, and having no Adobe Flash is a blessing not a curse.
Too bad, you can forget about performance-to-price, and availability is worse than abysmal.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
With stories like this, I always like to refer to the book of Star Trek Voyager for wisdom. Ensin Kim: "Why does everyone say 'relax' when they're about to do something terrible?"
WWPD - What Would Picard Do?
Also, how protected is the type of the processor and the other hardware used in a machine? I would imagine that exposing this information (such that your PC has a GPGPU) to software might help the software work better. To me, it seems that this gain easily outweigh the risks involved.
Never trust a spiritual leader who cannot dance -- Mr. Miyagi
"Windows/Office/IE monoculture is disappearing faster than equatorial glaciers..."
Do you actually work in corporate IT? Windows XP and IE6/7 dominate. Apple has little hope of taking hold in anything bigger than the art department at Comcast, and Linux is what the geekiest artist-type there uses at home.
I'm not advocating Windows... I'm simply pointing out that they are not going anywhere.
In your house, maybe.
In the server room, PowerPC is still very popular. In fact it's the only choice if you want the best straight-up single core performance.
"any reasonable server OS is fully portable" That's not true because AIX is a perfectly reasonable server OS and it's only on PowerPC.
Glad to hear someone's working on this...
Malware targeting one or more of those processors would work regardless of what OS or applications were installed.
Ok...but how are you planning on executing that? You can write a piece of code that exploits some chip vulnerability, and compile it for Windows -- but it still gives you no advantage over just writing something which targets Windows in the first place.
And if you're capable of running arbitrary machine code on the host -- which is sort of what I take this article to suggest -- then you've got way bigger fish to fry in the security department...
This is complete bullshit. First, you have to get your code to execute on my hardware, which you aren't about to do unless you compromise my OS. If you can't get your assembly code to run on the CPU in Ring 0 on the Intel Platform, for example, your processor specific malware, no matter how clever, is useless. If you can do so, you have already compromised my OS, so your code is useless.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Step 1: Fingerprint CPU
Step 2: ????
Step 3: Profit!
(workable exploits against the CPU are far more rare than attacks against applications)
seems a lot easier to me for the majority of cases. a little ASM goes a long way. When in doubt, ASK!
ok, now you can list all the architectures that don't specifically use CPUID, But they all (even PLC's) report what they are.
The Holy Grail of malware would be to modify the microcode on the CPU. Once they can do that, they *own* the machine
Just like on the Pentiums http://en.wikipedia.org/wiki/F00f
boycott slashdot February 10th - 17th check out: altSlashdot.org
So is the Ukrainian Mob giving out academic research grants these days? Not such a bad idea from their end.
This kind of thing would be handy to have for ordinary software, especially code that depends on floating point performance and routines that can optionally take advantage of processor-specific features (or route around misfeatures). The interface would still have to deal with the local OS, but the underlying libraries could be written without recourse to platform-specific code to identify the hardware -- especially since some operating systems either don't make that information available to apps or do so incorrectly.
Proud member of the Weirdo-American community.
First all intel cpus can get the cpu and stepping number easily. So why would you need to profile floating point ops.
Second, in order to send a network packet you need to comunitate with the os device driver, the os will likely crash if you bypass the os and talk to the network card directly, so how is this virus software supost to be os agnostic.
Lastly the memory maps and perifs of arm (or other) microcontrollers are very different. If you try to write to read only memory, an exception occures and it jumps to the exception vector.
The researchers claim to be working on a tool, dubbed Proc_Scope that will use specific numerical expressions to identify the processor type, and to be working on an algorithm that can help identify a specific processor.
That all sounds quite involved and somewhat fragile.
Or you could just use the CPUID instruction. Its been around since the original pentium.
You know, assuming Javascript engines in web browsers use the FPU to do floating point math operations, you could roughly categorize what hardware visitors to your website use.
And/or you could run a JS benchmark, and on the server side have baseline benchmark results for different web browsers and web browser versions on known hardware configurations - and then use that to deduce the user's clock speed. That is assuming that they aren't running anything else at the same time, but 99% of the time desktop systems are idle. You could do a run of 5 benchmarks over a period of say 30 seconds and throw out the outliers.
Of course you could combine this with the kind of stuff Panopticlick does, like detect the screen size, time zone, flash variables etc. For extra evil points, combine it with Samy Kamkar's evercookie.
With the discontinuation of their Xservs they've quite clearly said "We don't really care about the enterprise market." Can't say I'm surprised, consumer electronics is where they've been making tons of money. However it does mean that any growth potential they had in business markets is likely to dry up. That just means the market will continue to be solidly MS for now.
It's true! He just forgot to mention *which* equator he was referring to. I believe in this case, it would be the equator of Uranus.
... AIX is like that.
Platform independent malware is simply not reasonable. Different strains can be written for different systems but one piece of code to rule them all is probably a form of thought masturbation for this author, welcome to the reality.
The problems with the initial execution aside (anyone already running code on ur box can plant any strain they want anyway). The routines in malware will always be platform specific, and in some case version specific, even application specific. How can you go about harvesting information if you don't have a clue where to look? Functions need to be hooked and there is no universal function to hook for getting CCs or SSNs.
I suppose you could interact directly with the network card, but then you're going to need to build your own network stack and drivers for each of the most common types of NICs.
there is the possiblity of making it impossible for someone without say specialised JAG hardware to reflash the firmware, so once its compromised it cant be uncompromised. then there are the couterfiet bits of hardware with could be designed with backdoors that also lead to hardware that cannot be uncompromised, even if it goes into a super dormant state.
there are ways of communicating stenographically using timing delays in typing or network packets, so its actually starting to get pretty difficult to clean your system. not like removing a hdd and sticking it into a dock of a clean machine and wiping mbr+whole drive etc.
My guess is the AV companies are sensing that 'peak windows' has passed, and are manufacturing a new market.
The reason to run AV software on other platforms is to avoid inadvertently forwarding viruses to Windows users. Not a compelling story.
There is no cross-platform instruction to call the CPUID assembly instruction...so you can only use CPUID if you can run native code on the computer, and if youcan do that, you've already broken in so you don't need it.
Now imagine that you are running some generic code like javascript...which has a limited instruction set and is possibly even being run in a browser based sandbox. If you can use simple floating point arithmetic to detect the processor type, and then you know that this particular processor has a flaw such that if you evaluate: "44.5 / 222.3 + 1" then the following benign string literal in javascript gets interpreted as native binary code which executes outside of the "sandbox" imposed by the limitations of the language...do you get what I'm saying?
'...professor specific malware?
I've had to sit through my share of boring lectures, but isn't this carrying things a bit far?
This type of research doesn't appear to have any legitimate uses, it appears that it will only be useful to the malware authors.
make imaginary.friends COUNT=100 VISIBLE=false
At least they named it right. They just spelled it wrong. It SHOULD be aches.
Why is an official government department working to help malware authors? If it's for hacking terrorists then it should be classified and hidden. Is this one of those weird french things where everything is backwards?
...so you can probably determine the processor type by having someone visit a webpage, but wouldn't infecting someone involve, oh, I don't know, taking advantage of software flaws? At which point you've already got your malware inside. Also, what the hell are you going to do to with processor (or other hardware) specific malware? Sure, you can infect the drivers or firmware or whatever, but how is this different from any other vector of attack? Maybe I'm missing the point?
You don't install security patches? You're a real dare-devil, living on the edge like that...
I think the ad industry will also be interested in fingerprinting ... not for starting exploits, but for more effective tracking.
The Tao of math: The numbers you can count are not the real numbers.
ESIEA is "École Supérieure d'Informatique, Électronique, Automatique".
With "supérieure", not "superiore" (which is, maybe, Italian?). Please also note the usage of the accents on some of the letters (even the capitals, as allowed in French, even if some of the French people do not know their usage (!))
Merci.
(A verbatim translation of ESIEA would give something like "High School for Computer Science, Electronic and Control Engineering", however, an "École Supérieure" in France is more like a college in the US, not an high school.)
I agree Apple's strong point is UX and design of hardware aesthetics...
In the server world that's not applicable at all - still, OS X is more than just a pretty face, Darwin is a far more suitable server OS than windows... Server capabilities aren't crudley adhocked on, it was build for it - just like it's BSD roots.
Even so it still seems pretty pointless to pay for when Linux or BSD is free and better established as a solid reliable choice... I'm pretty ignorant of the server world but my understanding is that it's more about service than product as far as OS go.. i.e. Redhat, Sun... so i guess the only reason for apple to ever push it's OS into that market would be to provide competing services.
You may be correct, but I don't consider that a legitimate use any more than EverCookie is legitimate. The ad industry can track too much already, they don't need any more capability.
make imaginary.friends COUNT=100 VISIBLE=false
"lays out a strategy for fingerprinting processors by observing subtle differences in the way they perform complex floating point calculations. The method allows them to distinguish broad subsets of processor types by manufacturer"
cat /proc/cpuinfo, anyone?
This paper is really about how it is still possible to fingerprint CPUs, even without using the non-privileged CPUID instruction.
First of all, they state that using CPUID might trigger behavioral malware scanners/detectors.
Well, guess what: More or less every single program out there contains at least one CPUID instance somewhere in the runtime library code, some of them in order to avoid known bugs (like the Pentium FDIV case), and some in order to determine which forms of SIMD instructions are available (x87 vs SSE, scalar vs MMX/SSE/SSE2/SSE3/SSSE3/SSE4 etc.
Secondly, before CPUID turned up around the 486/Pentium changeover we used exactly the same kind of fingerprinting code to determine cpu versions: 8088/8086/80186/80286/386/486.
Some of them were based on known bugs (i.e. an 808x would not disable interrupts for the instruction following a segment register load), some on the handling of undocumented opcode sequences, like an ascii arithmetic instruction with the decimal constant replaced by another value, and some on the varying length of the instruction prefetch buffer.
Finally, the specific example they use early on (calculating square roots) is totally broken: Square root is one of the core functions in IEEE 754 arithmetic, which means that every single cpu has to generate the same result for all possible inputs, said result being the exact answer rounded correctly according to the current rounding mode and final precision (float/double).
The somewhat better example later in their paper uses trancendental functions, which is a much better choice since they do tend to change between processor families and sometimes even between different versions from the same vendor.
Terje
"almost all programming can be viewed as an exercise in caching"