5 ms·

Defending Against Compiler-Based Backdoors

35 points by caf 11y ago

caf 11y ago
The compiler-based backdoor is described by the authors in PoC||GTFO #8: https://www.alchemistowl.org/pocorgtfo/pocorgtfo08.pdf https://www.alchemistowl.org/pocorgtfo/pocorgtfo08.pdf Note that this isn't "Reflections on Trusting Trust" - the backdoor in question relies on specific non-buggy code in "sudo" triggering a pre-existing miscompilation bug in clang 3.3. If you examine the source to sudo, the backdoor isn't there; if you compile it with any other compiler, the backdoor doesn't exist.
- rdc12 11y ago
  Except that it requires a patch to sudo to work. It is more a question of, can I socially engineer a way to get a snippet of code into a project, that looks innocent (and is), but exploits version specific compiler bugs.
userbinator 11y ago
One absolute way to defend against a compiler-based backdoor is to not use a compiler at all... I've thought about how one could create a computer system that one could absolutely trust to be free of any outside interference - one that would have to be built "from scratch" by its owner - and if you assume that the hardware is OK (presumably because you built it yourself from equally simple components), it inevitably begins with manually entering individual bits into memory. Looking at the complexity of modern software stacks, and all the chances for bugs they introduce, perhaps we should not be stacking abstractions higher but wider, and making systems simpler overall.
- restalis 11y ago
  One way of defending against compiler-based backdoor would be to make the compiler binary as audit-able as possible (or to make it as easy as possible to be implemented "from scratch"), i.e. for it to be as small as possible, and what you've suggested comes out as a consequence - not stacking abstractions on the compiler, or at least not on the compiler's lowest level (that gets translated into machine code). The simplest implementation as I see it is to rely on a very small core of language primitives like C (although a simpler core was possible even there).
wmil 11y ago
"Be suspicious of baroque patch submissions" "baroque" strikes me as a bad metaphor.
- rurban 11y ago
  If you look at the patch/backdoor, I would have come to the same wording. /∗ Perfect hash function for mapping debug levels to intended verbosity ∗/ #define DEBUG_TO_VERBOSITY(d) \ (5%(3 ∗ (d))+2) You could call that over-engineering also, but baroque is a better name.
- c12 11y ago
  I googled "baroque patch submissions" to see if it was in common use; now I think about it, its quite ironic that the phrase is rather self referential.
  - caf 11y ago
    http://www.catb.org/~esr/jargon/html/B/baroque.html http://www.catb.org/~esr/jargon/html/B/baroque.html

35 points by caf 11y ago

caf 11y ago

The compiler-based backdoor is described by the authors in PoC||GTFO #8: https://www.alchemistowl.org/pocorgtfo/pocorgtfo08.pdf https://www.alchemistowl.org/pocorgtfo/pocorgtfo08.pdf Note that this isn't "Reflections on Trusting Trust" - the backdoor in question relies on specific non-buggy code in "sudo" triggering a pre-existing miscompilation bug in clang 3.3. If you examine the source to sudo, the backdoor isn't there; if you compile it with any other compiler, the backdoor doesn't exist.

rdc12 11y ago
Except that it requires a patch to sudo to work. It is more a question of, can I socially engineer a way to get a snippet of code into a project, that looks innocent (and is), but exploits version specific compiler bugs.

userbinator 11y ago

One absolute way to defend against a compiler-based backdoor is to not use a compiler at all... I've thought about how one could create a computer system that one could absolutely trust to be free of any outside interference - one that would have to be built "from scratch" by its owner - and if you assume that the hardware is OK (presumably because you built it yourself from equally simple components), it inevitably begins with manually entering individual bits into memory. Looking at the complexity of modern software stacks, and all the chances for bugs they introduce, perhaps we should not be stacking abstractions higher but wider, and making systems simpler overall.

restalis 11y ago
One way of defending against compiler-based backdoor would be to make the compiler binary as audit-able as possible (or to make it as easy as possible to be implemented "from scratch"), i.e. for it to be as small as possible, and what you've suggested comes out as a consequence - not stacking abstractions on the compiler, or at least not on the compiler's lowest level (that gets translated into machine code). The simplest implementation as I see it is to rely on a very small core of language primitives like C (although a simpler core was possible even there).

wmil 11y ago

"Be suspicious of baroque patch submissions" "baroque" strikes me as a bad metaphor.

rurban 11y ago
If you look at the patch/backdoor, I would have come to the same wording. /∗ Perfect hash function for mapping debug levels to intended verbosity ∗/ #define DEBUG_TO_VERBOSITY(d) \ (5%(3 ∗ (d))+2) You could call that over-engineering also, but baroque is a better name.
c12 11y ago
I googled "baroque patch submissions" to see if it was in common use; now I think about it, its quite ironic that the phrase is rather self referential.
- caf 11y ago
  http://www.catb.org/~esr/jargon/html/B/baroque.html http://www.catb.org/~esr/jargon/html/B/baroque.html