Awesome! Fedora also, and this is a step towards countering "Trusting Trust" toolchain issues

Posted Jan 23, 2015 19:03 UTC (Fri) by smoogen (subscriber, #97)
In reply to: Awesome! Fedora also, and this is a step towards countering "Trusting Trust" toolchain issues by PaXTeam
Parent article: Lots of progress for Debian's reproducible builds

I would expect that people looking to attack repeatable builds would figure on where people are most likely to put blind trust in something and exploit that.

Easiest? If the .changes files has to do certain things to make sure the archive is altered to "meet matching criteria" Stick something there which will get run every time that sticks in the exploit.

Hard? Everyone looks at the compiler to "deal with Thompson attack" but no one looks at m4, yacc, lex, Makefiles etc where it is easier to stick in some line noise that no one understands and then explain it away as an accident if they do.

Harder? If the system clock or other parts of the build system have to be derandomized to make sure that parts of various code are built exactly correct.. figure out which settings in such a build system are beneficial for your in-code exploit.

In any case, I could actually see where this sort of build system actually makes trust attacks easier because people will blindly say "well it built the same as the first one... must be clean." and not look at what actually was done to make it build exactly like the other part. [I also wonder what kinds of compiler optimizations have to be turned off to make sure that the code compiles the same.]

Awesome! Fedora also, and this is a step towards countering "Trusting Trust" toolchain issues

Posted Jan 23, 2015 19:06 UTC (Fri) by smoogen (subscriber, #97) [Link]

I didn't put this in originally and should have. Nothing I am saying is to mean that I don't think that verifiable build systems aren't needed or have good uses. I just think that the amount of "This solves ...." is being over stated and quickly leads to -funroll-loops level of blindness.

Awesome! Fedora also, and this is a step towards countering "Trusting Trust" toolchain issues

Posted Jan 29, 2015 15:55 UTC (Thu) by nix (subscriber, #2304) [Link] (3 responses)

I also wonder what kinds of compiler optimizations have to be turned off to make sure that the code compiles the same

Thanks to -frandom-seed, none to speak of. You just need to provide the same seed. (Well, none to speak of in the deterministic set of default optimizations. I presume that profile-guided optimizations are also out of the question, unless you distribute the .gcno files, etc, which is unlikely to happen!)

Awesome! Fedora also, and this is a step towards countering "Trusting Trust" toolchain issues

Posted Feb 3, 2015 22:29 UTC (Tue) by nix (subscriber, #2304) [Link] (2 responses)

Of course this is wrong. Profile-guided optimizations *that depend on nondeterministic test runs* are out of the question. If the test run is deterministic (thus the branches taken are unchanging across multiple runs), then of course profile-guided optimizations are not incompatible with reproducible builds.

Awesome! Fedora also, and this is a step towards countering "Trusting Trust" toolchain issues

Posted Feb 4, 2015 8:55 UTC (Wed) by cesarb (subscriber, #6266) [Link] (1 responses)

Does profile-guided optimization add profiling code to all branches, or does it use a timer (and a signal) to sample the basic blocks? If it uses a timer, it won't be deterministic.

Awesome! Fedora also, and this is a step towards countering "Trusting Trust" toolchain issues

Posted Feb 17, 2015 19:42 UTC (Tue) by nix (subscriber, #2304) [Link]

It instruments arcs between basic blocks, so it's deterministic.