To Foil Hackers, 'Morpheus' Chip Can Change Its Code In the Blink of An Eye (technologyreview.com) 80
Todd Austin, a professor at the University of Michigan, is working on an approach known as Morpheus that aims to frustrate hackers trying to gain control of microchips by presenting them with a rapidly changing target. At a conference in Detroit this week organized by the U.S. Defense Department's Defense Advanced Research Projects Agency (DARPA), Austin described how the prototype Morpheus chip works. MIT Technology Review reports: The aim is to make it incredibly difficult for hackers to exploit key software that helps govern the chip's operation. Morpheus does this by repeatedly randomizing elements of the code that attackers need access to in order to compromise the hardware. This can be achieved without disrupting the software applications that are powered by the processor. Austin has been able to get the chip's code "churning" to happen once every 50 milliseconds -- way faster than needed to frustrate the most powerful automated hacking tools. So even if hackers find a vulnerability, the information needed to exploit it disappears in the blink of an eye.
There's a cost to all this: the technology causes a slight drop in performance and requires somewhat bigger chips. The military may accept this trade-off in return for greater security on the battlefield, but it could limit Morpheus's appeal to businesses and consumers. Austin said a prototype has already resisted every known variant of a widely-used hacking technique known as a control-flow attack, which does things like tampering with the way a processor handles memory in order to allow hackers to sneak in malware. More tests lie ahead. A team of U.S. national security experts will soon begin probing the prototype chip to see if they can compromise its defenses, and Austin also plans to post some of Morpheus's code online so that other researchers can try to find flaws in it, too.
There's a cost to all this: the technology causes a slight drop in performance and requires somewhat bigger chips. The military may accept this trade-off in return for greater security on the battlefield, but it could limit Morpheus's appeal to businesses and consumers. Austin said a prototype has already resisted every known variant of a widely-used hacking technique known as a control-flow attack, which does things like tampering with the way a processor handles memory in order to allow hackers to sneak in malware. More tests lie ahead. A team of U.S. national security experts will soon begin probing the prototype chip to see if they can compromise its defenses, and Austin also plans to post some of Morpheus's code online so that other researchers can try to find flaws in it, too.
m0rpheus (Score:5, Funny)
From the IRC Matrix:
"I'm m0rpheus."
"Don't you mean 'Morpheus'?"
"Yes, but that nick was taken."
blow the whistle (Score:1)
We need a whistleblower.
Who is behind the forum disruption trolls who have beset Slashdot with racist shitposts, homoerotic incivility, anti-semitic screeds, and general crapflooding?
What PR firms do they work for? Who pays for them?
Re: (Score:2)
I have been unable to find any remaining copies. It was really great.
Does not sound impressive (Score:1)
Does sound like a lot of grande claims with little substance. If the code that gets morphed has vulnerabilities, they can still be exploited. In addition, the morphing system itself increases complexity and hence attack surface. Also, if this is about attacking hardware, then 50ms is half an eternity.
My prediction is that this will not be that hard to attack. That is if anybody even tries. This thing sounds like a nightmare to write reliable firmware on.
Re: (Score:2)
Weelll....that does sound like a reasonable argument. But note the prediction that it will only have a small use case. One can speculate that only a couple of languages would compile to it. That it would use a different op-code collection, etc. So that limits the size of the attack base. And if it also renders the chip invulnerable to the standard attacks (i.e. it's only vulnerable to those attacks specifically targeted at it) then is might be quite safe for it's use case (military applications that ar
Re: (Score:2)
If you're curious, some companies took longer (some a LOT longer), but the morphing only defeated the antivirus programmers for about a month, then they worked out how to easily exploit the big flaw that all morphing computer viruses have. (Here's a hint, they have to be able to run)
Re: (Score:1)
You're not understanding what is actually being "morphed" here and are applying unrelated paradigms of software polymorphic techniques. That's not what this is. Guesswork from previous dissimilar references really doesn't apply.
Your guess may be right, but definitely not for the reasons you seem to be mentioning in support.
Re: (Score:1)
They need a purpose-built HARDWARE tool FASTER than known/existing microchip systems widely available to be able to read and then transfer the values out to exploit existing exploit pathways. That isn't a "talented programmer" problem.
Whether or not a chip "with" it can be exploited by other unrelated side-chan implementation vulns is not really related to this, the "morpheus" approach, which is not limited to a chip's other vulns whatever they turn out to be.
It's really only blocking off a particular type
Re: (Score:2)
My thoughts exactly. So you can now just sit there repeatedly probing a system for the same exploit while the morpheus code iterates through code permuations underneath you.
This is just security by obscurity and will likely be just as effective.
Re: (Score:2)
However the chip is not designed to be widely distributed. This will make it difficult to design the custom attack. The weakness is probably the pipeline from fab to purchaser (since the purchaser will probably be either military, or someone working in a secret of better environment).
Expect those chips to soldered to the motherboard AND otherwise secured in place. Even so, if it goes into use, some will be stolen and sold to the highest bidder.
Re: (Score:2)
Probably the $10,000 toilet seat, and certainly the $5,000 monkey wrench was an attempt to avoid the paperwork, by making it worthwhile to buy a single money wrench at the hardware store rather than making the company do all the paperwork required to fill the order for a single wrench. But the government wanted to "go through established channels", and that demanded the paperwork. "OK, I'll do it, but it'll cost you!".
randomize opcodes (Score:5, Interesting)
Here's a less ambitious approach that works well on existing hardware: every boot, randomly shuffle the opcodes by loading an altered microcode. The software running on the machine needs to be rebuilt to match, but that's not a big problem with today's boxes, especially with a less optimizing compiler: tcc could compiler the kernel in 8 seconds on a 1-core Pentium 4 -- compiling the world on a modern 64-thread box might take similar time. Or you could prepare microcode+system images beforehand.
Randomize argument order in the ABI as well, and a few other bits -- and you've killed most exploits that rely on anything binary. Scripting languages are another story, but if IBM could invent EBCDIC encryption, so can you.
Rebuilding not a problem? (Score:5, Insightful)
"The software running on the machine needs to be rebuilt to match, but that's not a big problem with today's boxes"
So you think recompiling the entire OS and application suite on every boot is not a big problem not to mention how do you run the compiler itself if all the opcodes have changed?
"tcc could compiler the kernel in 8 seconds on a 1-core Pentium 4 "
Sorry? Which kernel exactly? You *might* compile the linux kernel in 8 minutes if you leave out a lot of drivers.
Whatever it is you're smoking I think I'll give it a miss.
Re: (Score:2)
I am not sure why you were modded insightful. This has been done: https://bellard.org/tcc/tccboo... [bellard.org]
Re: (Score:2)
That was in 2004 you clown when the linux kernel was a *teensy* bit smaller. Plus it mentions nothing about compiling the rest of the OS or any applications.
Re: (Score:2)
I don't know about you, but when I'm looking at a binary image, I can't be certain which parts are data and which parts are compiled code. Many integers (not sure about floats) look like perfectly good opcode instances...and conversely.
OTOH, I suppose it's possible that modern compilers strictly separate code segments from data...but they sure didn't used to do so. (For that matter, I remember some self-modifying code that intentionally treated opcodes as data...though that was a rare event...and required
Re: (Score:1)
Re: (Score:2)
Who exactly is going to wait for the OS to compile when their machine boots? And then wait for all the OS commands and applications to compile after? My PC with an SSD boots in about 10 seconds. Good luck matching that.
Re: (Score:2)
I don't think any of that would help, and neither will the technique outlined in TFA either.
The basic problem is that timing of certain events can be used to leak information about those events. Instruction timing, cache access timing, memory access timing, disk access timing, network timing etc. The goal here is to make instruction and possibly cache/memory timing vary, changing every 50ms.
50ms is way too long though. Say you have some crap code comparing two strings, which aborts as soon as it finds a mis
Re: (Score:2)
Well, the approach you're suggesting wouldn't work, because the mapping changes too quickly.
But I really think that this isn't the right approach, is quite limited in effectiveness, and has other problems. Isolation is a much better answer. Where you can't isolate, limit permissions. (You can write in this folder, you can read from that one, and you can't execute anything except listing the contents of those directories, reading, and writing to those directories.) But you also need to limit outgoing com
Re: (Score:2)
They will instead take a memory snap shot, use the same memory offsets legitimate programs to and then use offsets to attack where they need to.
On x86, even just randomizing opcodes is enough to disturb offsets, as different instructions have different lengths. So will randomizing the argument order (compiler will use different optimizations). And there's so many other places in the compiler to randomize.
That'll also somewhat disturb timings; you can alter the compiler some more to make the builds unreproducible.
It's called Polymorphism... (Score:3)
... and it's been done in Malware for decades now.
It's just a layer of obfuscation. Any real attacker will just use a FIB microscope and read out anything they want.
Re: (Score:1)
Wrong. Polymorphism is a single component of the approach you don't understand and are using reductionist logic to equate.
Re: (Score:2)
I note that you post a lot of smug shit implying you know something about this. We're not impressed. Now either you post some information or fuck off like the coward you are.
In 1987, Dallas Semiconductor/Maxim introduced the (Score:1)
DS5000 microcontroller, with an 8051 core.
Software Security Feature: Executes Encrypted Software to Prevent Unauthorized Disclosure
https://www.maximintegrated.co... [maximintegrated.com]
https://datasheets.maximintegr... [maximintegrated.com]
Nothing new - not easy to crack (was actually used by hackers to secure pirated tv/satellite decryption cards), but if you own it - you can pwn it, especially if you dig enough and have resources.
Blink of An Eye (Score:2)
To a CPU, the blink of an eye is a *really* long time.