full-disclosure - Re: OpenBSD has Open Backdoored Software Distribution

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <10792.1293069349@localhost>
Date: Wed, 22 Dec 2010 20:55:49 -0500
From: Valdis.Kletnieks@...edu
To: mrx <mrx@...pergander.org.uk>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: OpenBSD has Open Backdoored Software
	Distribution - admitted by Theo

On Thu, 23 Dec 2010 00:36:03 GMT, mrx said:

> I am aware that compilers can be coded to introduce "features" into binaries that are not in the actual source code itself.
> So with all due respect and possibly much ignorance on my part, what is a code audit going to achieve if one uses the shipped compiler to
> compile the source? Unless one codes ones own compiler can any binary be trusted?

Although Kargen and Schell did it during the Multics pen-test for *one* release
of *one* compiler on *one* system, and Thompson referenced it in his Turing
Award lecture, it's probably *not* on anybody's serious threat model.

You'd have to find a way to put your backdoored compiler onto the
distribution's build farm (so *all* copies got backdoored), and ensure that it
stayed in place across releases - which means you probably need to re-backdoor
it for each release of the compiler (code generators, especially optimizing
ones, are moving targets - if your backdoor gets munched by the dead-code
eliminator, or mutated by the CSE code, you don't get your backdoors).  And of
course, if your code inserts the backdoor-the-compiler code by recognizing 7
specific lines in one function, life gets interesting when a bugfix changes
those 7 lines to 9. You either lose your backdoor, or it gets detected because
the bugfix doesn't work because your code is overriding it.

I'll overlook the minor detail that (for instance) today's gcc compiler is a *lot*
more sophisticated, with a lot more code-generation intelligence, than what
was available in 1972 when Karger and Schell and Thompson were doing
this stuff - so the backdoor will have to be equally more subtle and thus fragile.

You'd also have to find a clever way to deal with paranoids who rebuild their
source tree with their previous toolchain - if anybody pulls down the new source
and rebuilds it with their old compiler, you don't get a backdoor.  And if the
compiler they build doesn't binary-match the distro's, the jig is up (and you *know*
that if they're paranoid to rebuild the compiler, they'll notice a difference ;)

It's probably easier to get a backdoored BIOS loaded onto the target, and use the
microcode-update function on many CPUs to install a backdoor that way.

And at some point, you really have to ask yourself "Is this really a plausible attack
method, or did I forget to take my meds again?".

Content of type "application/pgp-signature" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/