conferences | speakers | series

Revisiting "Trusting Trust" for binary toolchains

home

Revisiting "Trusting Trust" for binary toolchains
30. Chaos Communication Congress

Ken Thompson's classic "Reflections on Trusting Trust" examined the impacts of planted build chain bugs, from an example of a compiler Trojan to a hypothetical "well-placed microcode bug". Once theoretical & remote, such scenarios have lately been revealed as a stark reality. But what if we could have every individual piece of software or firmware in the binary toolchain bug-free, performing just as their programmers intended? Would we be safe from run-away computation if only well-formed inputs to each of the individual tools were allowed? Not so. Potential for malicious computation lurks in a variety of input formats along all steps of the binary runtime process construction and execution. Until the "glue" data of an ABI and the binary toolchains in general is reduced to predictable, statically analyzable power, plenty of room for bug-less Trojans remains. We will discuss our latest work in constructing Turing-complete computation out of different levels of metadata, present tools to normalize and disambiguate these metadata, and conclude with proposals for criteria to trust binary toolchains beyond "Trusting trust" compilers and planted bugs.

This talk develops on our previous "weird machines" work published in WOOT 2013, https://www.usenix.org/system/files/conference/woot13/woot13-shapiro.pdf and https://www.usenix.org/system/files/conference/woot13/woot13-bangert.pdf (video & slides at https://www.usenix.org/conference/woot13/tech-schedule/workshop-program) We will look at the elements of runtime that are typically overlooked as "mere engineering", and show that without restricting these to statically predictable computing power no trust in the toolchain is possible, i.e., a computation can be hijacked from a "signed" image even before it starts executing. In particular, we will show how parser differentials between images as verified and as loaded, or as seen by the kernel and the RTLD can result in completely different view of the loadable segments (and, as a result, of the runtime space).

Speakers: sergeybratus Julian Bangert bx