Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Security Software

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.
This discussion has been archived. No new comments can be posted.

Imparting Malware Resistance With a Randomizing Compiler

Comments Filter:
  • Copying the Bad Guys (Score:3, Informative)

    by alphaminus ( 1809974 ) on Thursday May 29, 2014 @05:48PM (#47123837)
    Some malware already does this, which definitely helps it evade heuristic scans. Sounds worth exploring, but i bet it will make the AV they force me to run at work that much more frustratingly restrictive.
  • Trusting trust (Score:4, Informative)

    by tepples ( 727027 ) <tepples.gmail@com> on Thursday May 29, 2014 @05:55PM (#47123873) Homepage Journal

    The problem with any nondeterministic compiler is that it prevents use of diverse double-compiling [dwheeler.com], a method to detect the sort of compiler backdoor described by Ken Thompson in "Reflections on Trusting Trust" [bell-labs.com]. You'd have to bootstrap the compiler with nondeterminism turned off (and with GUIDs, timestamps, and multithreaded allocation of symbols for anonymous objects turned off too) in order for the DDC bootstrap construction to converge.

    In any case, I've implemented a technique like this on the Nintendo Entertainment System. I wrote a preprocessor that shuffles the order of functions in the file, the order of opcodes within a function that don't depend on each other's results, and the order of global variables (or the order of fields in an object). One reason I implemented it was to use one variable as another's canary [wikipedia.org] to make buffer overflows easier to detect in an assembly language program. The other is watermarking the binary [nesdev.com] so that I can tell who leaked a particular copy of the beta version to the public. If you're interested, you can find my shuffle tool in the source code of Concentration Room [pineight.com].

  • Re:Cute but dumb (Score:3, Informative)

    by oldhack ( 1037484 ) on Thursday May 29, 2014 @06:19PM (#47124113)

    And broken clocks tells the right time twice a day. How often do you expect the randomization could/would help rather than hinder bug zapping?

    Bug reporting itself would become a much bigger problem due to the greater difficulty in reproducing them.

  • by perpenso ( 1613749 ) on Thursday May 29, 2014 @09:32PM (#47125649)

    ..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/... [google.com]

    As an employee of the University of California a professor is *required* to report any discovery or method that *might* be patentable to the University.

    The University takes it from there, it has an office that researches viability, handles the process and then licenses the patents to "industry". With respect to licensing small local companies are given a better deal than larger internationals. As for the licensing fees collected, 50% goes to the University, 25% to the department (UC Irvine's Computer Science department in this case) and 25% to the employee(s).

    At least that is how it was a few years ago when I was a grad student at UC.

Software production is assumed to be a line function, but it is run like a staff function. -- Paul Licker

Working...