Slashdot Mirror

← Back to Stories (view on slashdot.org)

Imparting Malware Resistance With a Randomizing Compiler

Posted by timothy on from the well-if-it-works-for-apache-linux dept.

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.

7 of 125 comments (clear)

  1. Cute but dumb by oldhack · · Score: 5, Insightful

    You think you have buggy software now, this idea will multiply a single bug into a dozen.

    --
    Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
    1. Re:Cute but dumb by tepples · · Score: 5, Insightful

      If bugs are detected earlier, they can be fixed earlier. Randomizing can turn a latent bug into an incredibly obvious bug.

  2. ....why? by Anonymous Coward · · Score: 5, Insightful

    ..would a professor of CompSci think this is a good idea, despite the hundreds of problems it *causes* with existing practices and procedures?

    Oh, wait.. maybe because the idea is patented and he'll get paid a lot.
    http://www.google.com/patents/US8239836

  3. Re:Would cause major debugging headaches by Anonymous Coward · · Score: 5, Funny

    Ahh, but don't forget the benefits! If random bugs could appear or disappear on installs, think of how much tech support time you can save by just saying "Re-install it and you'll be fine."

    Half the time that's what they do now anyways, now you can replace ALL the calls with that!

  4. Gentoo by Bert64 · · Score: 5, Funny

    You can already do this with Gentoo, you're highly unlikely to use the same combination of compiler, kernel, assembler, libraries, use flags, compiler flags etc as anyone else...

    --
    http://spamdecoy.net - free throwaway anonymous email - avoid spam!
  5. Re:Would cause major debugging headaches by Anonymous Coward · · 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.

  6. Explain Like I'm Five by vux984 · · Score: 5, Insightful

    The problem with this in "Explain like I'm Five" terms:

    You can have no idea what the program you are running does.

    You cannot trust it. You cannot know it hasn't been tampered with. You cannot know a given copy works the same as another copy. You cannot know your executable has no back doors.

    On the security minded front we have a trend towards striving for deterministic build capability; so that we have some confidence and method of validating that a source code to executable transformation hasn't been tampered with, that the binaries you just downloaded were actually generated from the source code in a verifiable way.

    Another technique I'm seeing in secure conscious areas is executable whitelisting, where IT hashes and whitelists executables, and stuff not on the whitelist is flagged and/or rejected.

    Now this guy comes along and runs headlong in the other direction suggesting every executable should be different. And I'm not sure I see any real benefit, nevermind a benefit that offsets the losses outlined above.