Imparting Malware Resistance With a Randomizing Compiler 125
First time accepted submitter wheelbarrio (1784594) writes with this news from the Economist: "Inspired by the natural resistance offered to pathogens by genetically diverse host populations, Dr Michael Franz at UCI suggests that common software be similarly hardened against attack by generating a unique executable for each install. It sounds like a cute idea, although the article doesn't provide examples of what kinds of diversity are possible whilst maintaining the program logic, nor what kind of attacks would be prevented with this approach." This might reduce the value of MD5 sums, though.
Re:Would cause major debugging headaches (Score:5, Interesting)
The randomizing compiler could easily be designed to base it's randomizations on a seed, and then include that seed in the obj headers and stack dump trace library of the libc it links against. Then the bug would be just as reproducable as with a standard compiler.
the crutch of determinism (Score:5, Interesting)
I must respectfully disagree with you on every point you raise.
A randomised stack would cause certain types of bugs to manifest themselves much earlier in the development process. Nothing decreases the cost of a bug hunt more than proximity to the actual coding event.
Such an environment rewards programmers who invest more to validate their loops and bounds more rigorously in the first place. Nothing reduces the cost of a bug more than not coding it in the first place.
There's nothing that stops the debugging team from debugging against a canonical build, if they wish to do so. If they have a bug that the canonical build won't manifest, they wouldn't even have known about the bug without this technique added to the repertoire. If many such bugs become known early in the development process—bugs that manifest on some randomised builds, but not on the canonical debug build—you're got an excellent warning klaxon telling you what you need to know—your coding or management standards suck. Debugging suck, if instigated soon enough to matter, returns 100x ROI as compared to debugging code.
Certainly the number of critical vulnerabilities that exist against some compiled binary can only increase in number. So what? The attacker most likely doesn't know in advance which version any particular target will run. The attacker must now develop ten or one hundred exploits where previously one sufficed (or one exploit twice as large and ten times more clever).
If the program code mutated on every execution, you would have some valid points. That would be stupid beyond all comprehension. An attacker could just keep running your program until it comes up cherries.
The developer controls the determinism model. It's an asset in the war. There can be more when it helps our own cause, and less when it assists our adversaries.
Determinism should be not reduced to a crutch for failing to code correctly in the first place. Get over it. Learn how. Live in an environment that punishes mistakes early and often.
Re:Would cause major debugging headaches (Score:4, Interesting)
Re:Explain Like I'm Five (Score:5, Interesting)
It's simple. You use signed source code instead of signed binaries.
That doesn't really help.
If every executable is different, then I have no information about the binaries i downloaded. I have to download the source, verify that its the 'audited trusted source' by checking its hash and signatures, and then I have to compile it myself. Most people don't want to compile all their own code.
It is good enough that OpenBSD released the source code, trusted auditing group audited the source code, and trusted build validation group verifies that the binaries on the OpenBSD site were generated from the audited source. I can just download the binaries check the hash/signatures and I'm good to go.
And in the case of a corporate IT department, you use the randomizing compiler to build the binary that you push out to your clients. It may be the same throughout your company, but it will be different from anything anyone outside would have access to, which is probably good enough.
The technique can be expanded to the home market; whereby joe-sixpack is running executable whitelist-reputation subscription software that will flag anything on his system that isn't "known good". Antivirus software is starting to head in this direction -- where it maintains databases of 'known good' executables; you've probably even seen them say "this executable is not known... submit it for analysis" -- take that system to its logical conclusion; and we could see community sites maintain executable whitelists that are as effective as adware blockers. (And they'd have no qualms about flagging "technically not illegal malware but nobody actually wants to run this shit" (e.g. toolbar search redirections through popup advertisting portals that the AV guys are currently too scared to just block outright.)
Community managed executable whitelists with operating system level enforcement support could potentially make a serious dent in malware on the average uninformed users computer. It would help close a lot of attack vectors. More effective I think than 'randomizing' variable layout at in the compiled executable.
Also re:
Then you use a compiler and linker that does some simple things like randomly ordering variables and functions in the executable and on the stack.
Stronger ASLR and DEP type features in the OS to do executable layout randomization at runtime I think represents a better approach to this than randomization at compile time.
So you are arguing to leave bugs in place ? (Score:5, Interesting)
What kinds of bugs do you think would manifest earlier using this technique ...
The GP mentioned a randomized stack. An uninitialized variable would be one, something that often accidentally has a value that does no harm (a zero possibly).
... and why do you think that earlier manifestation of that class of bugs will outweigh the tremendous burden of chasing down all the heisenbugs that only occur on some small percentage of randomized builds?
You do realize that your argument for the status quo and not dealing with the "heisenbugs" is essentially arguing to leave a coding bug in place? Recompiling will not necessarily introduce new bugs, rather change the behavior of existing bugs.
I've seen many of the sort of bugs this recompiling technique may expose, I spent some years porting software between different architectures. Not only did we have different compilers but we had different target CPUs. It was a friggin awesome environment for exposing unnoticed bugs. Software that had run reliably under internal testing for weeks on its original platform failed immediately when run on a second platform. And it kept failing immediately after several crashing bugs were fixed. The original developers, who were actually quite skilled, looked at several of the bugs eventually found and wondered how the program ever ran at all. I've seen this repeated on multiple teams at multiple companies over the years.
Also developers working on one platform eventually learned to visit a colleague working on the "other" platform when they had a bug that was hard to reproduce. There was a good chance that a hard to manifest bug on one platform would be easier to reproduce on the other.
There is nothing like cross platform development to help shake out bugs.
This recompilation idea would seem to offer some of these same benefits. Yes it complicates reproducibility of crashes in the field but if one can get a recompilation seed with that crash dump/log its more like of dealing with an extra step not some impossible hurdle.
Plus recompiling with a different seed each time the developer does a test run at their workstation could help find bugs in the first place, reducing the occurrences of these pesky crashes in the field.
I'm not saying these proposed recompilations in the field are definitely a good idea, just that the negatives seem to be exaggerated. It looks like something interesting, worth looking into a bit more.