6 ms·

Reproducible builds in Debian: preventing compiler backdoors

88 points by Tsiolkovsky 11y ago

giancarlostoro 11y ago
tl;dr Debian wants to have reproducible builds to ensure developer systems aren't compromised by the CIA. Not sure how that is going to shut down the CIA though, maybe I missed it.
- venomsnake 11y ago
  Probably the author meant shut out. Especially since they have the ability to tamper with the BIOS (Snowden revelations IIRC), hdd firmware and we have the whole microcode stuff that is unauditable. And too many things with vulnerabilities of their own with DMA access. But it is a step indeed.
- bdcravens 11y ago
  Maybe it's an idiomatic thing, but "shut down" doesn't necessarily mean shutting down the organization. The term is commonly used to refer to a very specific context (think sports - "shutting down" just means preventing within a specific window)
  - schoen 11y ago
    I guess I've heard that in sports coverage to mean "prevent from scoring" (or just "impede"?), but I'm not sure I've heard it with that meaning in other contexts. I guess it does appear in the context of a proposal. "The environmental group wanted to build a bike line from the park to the waterfront, but the city planners shut them down." (not implying that the group was disbanded, but that the plan was blocked) But I'm still not sure either meaning makes sense in the context of the headline.
- agumonkey 11y ago
  Debian reproducible builds create a notion of equality at the binary level (IIUC), before that, you cannot know what is inside the compiled binary. Maybe that's useless with a system of carefully signed packages .. that's above my level.
belorn 11y ago
One of the larger insight that Snowden gave was that agencies dealing with data gathering does so through several avenues simultaneous rather then relying on a single method. They request the data from companies, intercepts the cable traffic between ISP's, plants backdoors in protocols and servers, do MiTM, uses malware, and so on all in parallel. Reproducible builds won't "shut down" the CIA but it will increase the security of compilers and protect Debian's build system which would otherwise be a prime target for attacks that could compromise a very large number of users.
teddyh 11y ago
The article links to a talk at the CCC which was on august 15th. There was an even more recent talk held at DebConf 15 on august 21st: http://meetings-archive.debian.net/pub/debian-meetings/2015/debconf15/Stretching_out_for_trustworthy_reproducible_builds_creating_bit_by_bit_identical_binaries.webm http://meetings-archive.debian.net/pub/debian-meetings/2015/...
alnsn 11y ago
> Many other free software projects, including FreeBSD, NetBSD, and OpenWrt, are moving in the same direction. I might be wrong (I'm away from my NetBSD boxes) but build.sh script in NetBSD has a buildseed option which can be used to create identical builds of the base system.
elektromekatron 11y ago
Vice's headline writer should maybe dial it back a little, unless Debian has become a rather different organization than when I last checked.
bazillion 11y ago
I fail to understand how this is going to shut down the CIA, who is: 1. Not tasked with collection, that would be the NSA. Detailed in the article is a meeting that the CIA apparently hosted detailing possible exploits for Apple's phone systems. What does Debian have anything to do with exploits on Apple's phone systems? The article is talking about an operating system-level change and the presentation at the event referenced was a "compromised" Xcode that could sneak backdoors into an iPhone app. 2. Primarily involved in HUMINT (Human Intelligence) which consists of face to face interaction. The article says that the CIA is trying to expand into cyber warfare. That's because the CIA's cyber capabilities are laughable right now -- what do you think they were in 2012 when the meeting took place as detailed in the article? 3. The documents referenced do not even detail the level of success that the research has had on breaking Apple's encryption and security processes. News flash, Apple's phone is pretty much the most freaking rock solid phone on the market security-wise. It would be the holy grail for an intelligence agency to crack this thing, but instead government, state, and city agencies have to literally take physical phones to Apple and ask for them to unlock the data on them if it's crucial to their investigations. I think the article mentions the CIA to sensationalize, since pretty much anyone recognizes the initialism and a "Yeah, fight the evil government Debian!" clouds the loosely cobbled-together facts in the article. I was a CIA contractor, and I really wish there was more understanding of the scope and functions of the different agencies instead of painting every government activity as being malicious. That the nature of the CIA and NSA prevent most of the details of their operations from being understood is unfortunate, but even if they were it wouldn't fit the constant anti-government narrative on the site. I'm pondering starting a blog to educate about the roles, responsibilities, and what it's really like working in these agencies. I was an NSA linguist, programmer, and mission manager, as well as a CIA contractor, so I definitely think I have a lot to contribute to the conversation but am constantly drowned out by the rage-filled anti-government sentiment on the site, which you can see if you read my comment history.
- deleted 11y ago
  [deleted]
- bdcravens 11y ago
  It seems to me that you are equating dislike for these organizations to dislike for those like yourself who do the work. To this end, it feels like this produces internal noise. When I was reading the article, I picked up on the reproducible builds; the anti-government sentiment was at best a subtext to me. I feel it's good to have reproducible builds that are clean, regardless of who may be thwarted as a result (CIA, NSA, FBI, AWS, ISIS, malware vendors, adware vendors, whatever)
mbrutsch 11y ago
http://c2.com/cgi/wiki?TheKenThompsonHack http://c2.com/cgi/wiki?TheKenThompsonHack
- teddyh 11y ago
  https://en.wikipedia.org/wiki/Backdoor_%28computing%29#Compiler_backdoors https://en.wikipedia.org/wiki/Backdoor_%28computing%29#Compi...
nickpsecurity 11y ago
This is an old problem solved dozens of ways that mainstream just refuses to deal with. The requirement is even standard for proprietary products going for DO-178B certification. I believe they do quite manual confirmation but automated exists. The solution is called certified compilation: the verifiable transformation of source into binaries. You break the process into a series of steps which each can be verified with the CST's/AST's handed from one to the next. You can implement the steps yourself or validate someone else's, even easier if it's a safe[r] language. Examples each using different methods are VLISP [1], FLINT [2], and CompCert C [3]. Running Debian through CompCert while putting more work into CompCert for portability and optimization is the easiest solution with long-term benefits. Performance will go up steadily. Bug count will go down steadily because that's what SML/Ocaml does. Code will be more readable. Repeat for most trusted tools to drive assurance up across the board. If they don't want to do that, then the result will be something along lines of just having a bunch of people compile and sign the distro publishing signatures, etc. You will trust that they trusted whatever they all looked at. And anyone whose studied GCC's source, etc will know that basically means they all saw the same code. They'd have to understand it all to have known if there was a weakness introduced. They won't, use of C/C++ makes that harder, plenty of rope to hang one's self in any common action, and it's why those of us doing subversion-resistant development use languages like ML's or Oberon. FOSS needs to similarly transition toward safe, comprehensible tools that aren't backdoor generators just by architecture & language used. Otherwise, all this talk of preventing subversion is just talk: they're going to get in. And if not subversion, the endless stream of 0-day's from the language and architectural choices will continue to do the job. A re-implementation of the TCB's of our systems is long overdue. [1] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.51.2824&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.51.... [2] http://flint.cs.yale.edu/flint/software.html http://flint.cs.yale.edu/flint/software.html [3] http://compcert.inria.fr/ http://compcert.inria.fr/
- jeffreyrogers 11y ago
  If I remember correctly the problem Thompson described is tougher to deal with than this. Yes, the CompCert compiler is certified, but the problem is that the compiler that bootstrapped CompCert may not be. If you use some compiler (let's call it gccb, for backdoored gcc) to bootstrap CompCert that outputs ccb (backdoored compcert). Now you recompile CompCert with ccb since CompCert is certified. This gets you a final version of CompCert compiled with a bootstrapped CompCert. So the process is gccb -> ccb -> cc. But then the backdoor has just been transmitted down the line to cc. Edit: also I just looked and it appears that CompCert is written in OCaml. This doesn't substantively change anything above. It just means that rather than having a backdoored gcc you'd have a backdoored ocamlc. Realistically the only way to truly assure that your compiler is not backdoored is by writing it yourself in assembly. But then, your assembler might be backdoored. So you need to write your own assembler in binary. But then your processor might be backdoored. So you need to design your own processor. And then you might be safe. Of course, if someone really cared enough to backdoor all that stuff, they'd probably just come after you with a rubber hose at that point. And I think that was the point Thompson was trying to make.
schoen 11y ago
We also had a closely related talk about this at the 31C3 which talks primarily about the motivation for the problem and how the Tor Browser has addressed it (leading into Debian stuff, but the Debian developers couldn't join us in person, so you can hear much more about the Debian side from the later talks that the article refers to). https://media.ccc.de/browse/congress/2014/31c3_-_6240_-_en_-_saal_g_-_201412271400_-_reproducible_builds_-_mike_perry_-_seth_schoen_-_hans_steiner.html https://media.ccc.de/browse/congress/2014/31c3_-_6240_-_en_-... I had two examples in that talk that I liked a lot: * What's the smallest change that you'd have to make to a binary to introduce an exploitable vulnerability? (I work through an answer in the talk.) * I demonstrate a kernel module that tampers with source code as it's being read by the compiler, so that nothing is modified on disk, and all of the source files are unmodified as confirmed by other software on the system, but the resulting binary is corrupt. You can also hear about my co-presenter Mike Perry's heroic efforts to make the Tor Browser build reproducibly, one of the first pieces of open source software of its size and complexity to do so. And definitely one that people are trying to distribute fake modified versions of (not necessarily with network MITMs, though quite possibly -- but even with simple e-mail phishing).
jongraehl 11y ago
You also have to trust the source code of the 'untrusted' compiler (that is, read it and make sure it doesn't directly contain any back door).
- unhammer 11y ago
  Or trust the source code of a simpler compiler that is able to compile the untrusted compiler: http://www.dwheeler.com/trusting-trust/ http://www.dwheeler.com/trusting-trust/
unhammer 11y ago
https://reproducible.alioth.debian.org/presentations/2015-08-13-CCCamp15.pdf https://reproducible.alioth.debian.org/presentations/2015-08... has some tips on what you can do to ensure your own FOSS packages have reproducible builds, e.g.: * avoid storing build-timestamps (maybe use timestamp of last commit instead) * avoid storing build numbers * LC_ALL=C sort the sets of things where order is undefined/unimportant, e.g. file lists going into tar or hash keys * try building, then changing something in the environment, building again and diffing (with diffoscope)

88 points by Tsiolkovsky 11y ago

tl;dr Debian wants to have reproducible builds to ensure developer systems aren't compromised by the CIA. Not sure how that is going to shut down the CIA though, maybe I missed it.

venomsnake 11y ago
Probably the author meant shut out. Especially since they have the ability to tamper with the BIOS (Snowden revelations IIRC), hdd firmware and we have the whole microcode stuff that is unauditable. And too many things with vulnerabilities of their own with DMA access. But it is a step indeed.
bdcravens 11y ago
Maybe it's an idiomatic thing, but "shut down" doesn't necessarily mean shutting down the organization. The term is commonly used to refer to a very specific context (think sports - "shutting down" just means preventing within a specific window)
- schoen 11y ago
  I guess I've heard that in sports coverage to mean "prevent from scoring" (or just "impede"?), but I'm not sure I've heard it with that meaning in other contexts. I guess it does appear in the context of a proposal. "The environmental group wanted to build a bike line from the park to the waterfront, but the city planners shut them down." (not implying that the group was disbanded, but that the plan was blocked) But I'm still not sure either meaning makes sense in the context of the headline.
agumonkey 11y ago
Debian reproducible builds create a notion of equality at the binary level (IIUC), before that, you cannot know what is inside the compiled binary. Maybe that's useless with a system of carefully signed packages .. that's above my level.

belorn 11y ago

One of the larger insight that Snowden gave was that agencies dealing with data gathering does so through several avenues simultaneous rather then relying on a single method. They request the data from companies, intercepts the cable traffic between ISP's, plants backdoors in protocols and servers, do MiTM, uses malware, and so on all in parallel. Reproducible builds won't "shut down" the CIA but it will increase the security of compilers and protect Debian's build system which would otherwise be a prime target for attacks that could compromise a very large number of users.

teddyh 11y ago

The article links to a talk at the CCC which was on august 15th. There was an even more recent talk held at DebConf 15 on august 21st: http://meetings-archive.debian.net/pub/debian-meetings/2015/debconf15/Stretching_out_for_trustworthy_reproducible_builds_creating_bit_by_bit_identical_binaries.webm http://meetings-archive.debian.net/pub/debian-meetings/2015/...

alnsn 11y ago

> Many other free software projects, including FreeBSD, NetBSD, and OpenWrt, are moving in the same direction. I might be wrong (I'm away from my NetBSD boxes) but build.sh script in NetBSD has a buildseed option which can be used to create identical builds of the base system.

elektromekatron 11y ago

Vice's headline writer should maybe dial it back a little, unless Debian has become a rather different organization than when I last checked.

bazillion 11y ago

I fail to understand how this is going to shut down the CIA, who is: 1. Not tasked with collection, that would be the NSA. Detailed in the article is a meeting that the CIA apparently hosted detailing possible exploits for Apple's phone systems. What does Debian have anything to do with exploits on Apple's phone systems? The article is talking about an operating system-level change and the presentation at the event referenced was a "compromised" Xcode that could sneak backdoors into an iPhone app. 2. Primarily involved in HUMINT (Human Intelligence) which consists of face to face interaction. The article says that the CIA is trying to expand into cyber warfare. That's because the CIA's cyber capabilities are laughable right now -- what do you think they were in 2012 when the meeting took place as detailed in the article? 3. The documents referenced do not even detail the level of success that the research has had on breaking Apple's encryption and security processes. News flash, Apple's phone is pretty much the most freaking rock solid phone on the market security-wise. It would be the holy grail for an intelligence agency to crack this thing, but instead government, state, and city agencies have to literally take physical phones to Apple and ask for them to unlock the data on them if it's crucial to their investigations. I think the article mentions the CIA to sensationalize, since pretty much anyone recognizes the initialism and a "Yeah, fight the evil government Debian!" clouds the loosely cobbled-together facts in the article. I was a CIA contractor, and I really wish there was more understanding of the scope and functions of the different agencies instead of painting every government activity as being malicious. That the nature of the CIA and NSA prevent most of the details of their operations from being understood is unfortunate, but even if they were it wouldn't fit the constant anti-government narrative on the site. I'm pondering starting a blog to educate about the roles, responsibilities, and what it's really like working in these agencies. I was an NSA linguist, programmer, and mission manager, as well as a CIA contractor, so I definitely think I have a lot to contribute to the conversation but am constantly drowned out by the rage-filled anti-government sentiment on the site, which you can see if you read my comment history.

deleted 11y ago
[deleted]
bdcravens 11y ago
It seems to me that you are equating dislike for these organizations to dislike for those like yourself who do the work. To this end, it feels like this produces internal noise. When I was reading the article, I picked up on the reproducible builds; the anti-government sentiment was at best a subtext to me. I feel it's good to have reproducible builds that are clean, regardless of who may be thwarted as a result (CIA, NSA, FBI, AWS, ISIS, malware vendors, adware vendors, whatever)

mbrutsch 11y ago

http://c2.com/cgi/wiki?TheKenThompsonHack http://c2.com/cgi/wiki?TheKenThompsonHack

teddyh 11y ago
https://en.wikipedia.org/wiki/Backdoor_%28computing%29#Compiler_backdoors https://en.wikipedia.org/wiki/Backdoor_%28computing%29#Compi...

nickpsecurity 11y ago

This is an old problem solved dozens of ways that mainstream just refuses to deal with. The requirement is even standard for proprietary products going for DO-178B certification. I believe they do quite manual confirmation but automated exists. The solution is called certified compilation: the verifiable transformation of source into binaries. You break the process into a series of steps which each can be verified with the CST's/AST's handed from one to the next. You can implement the steps yourself or validate someone else's, even easier if it's a safe[r] language. Examples each using different methods are VLISP [1], FLINT [2], and CompCert C [3]. Running Debian through CompCert while putting more work into CompCert for portability and optimization is the easiest solution with long-term benefits. Performance will go up steadily. Bug count will go down steadily because that's what SML/Ocaml does. Code will be more readable. Repeat for most trusted tools to drive assurance up across the board. If they don't want to do that, then the result will be something along lines of just having a bunch of people compile and sign the distro publishing signatures, etc. You will trust that they trusted whatever they all looked at. And anyone whose studied GCC's source, etc will know that basically means they all saw the same code. They'd have to understand it all to have known if there was a weakness introduced. They won't, use of C/C++ makes that harder, plenty of rope to hang one's self in any common action, and it's why those of us doing subversion-resistant development use languages like ML's or Oberon. FOSS needs to similarly transition toward safe, comprehensible tools that aren't backdoor generators just by architecture & language used. Otherwise, all this talk of preventing subversion is just talk: they're going to get in. And if not subversion, the endless stream of 0-day's from the language and architectural choices will continue to do the job. A re-implementation of the TCB's of our systems is long overdue. [1] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.51.2824&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.51.... [2] http://flint.cs.yale.edu/flint/software.html http://flint.cs.yale.edu/flint/software.html [3] http://compcert.inria.fr/ http://compcert.inria.fr/

jeffreyrogers 11y ago
If I remember correctly the problem Thompson described is tougher to deal with than this. Yes, the CompCert compiler is certified, but the problem is that the compiler that bootstrapped CompCert may not be. If you use some compiler (let's call it gccb, for backdoored gcc) to bootstrap CompCert that outputs ccb (backdoored compcert). Now you recompile CompCert with ccb since CompCert is certified. This gets you a final version of CompCert compiled with a bootstrapped CompCert. So the process is gccb -> ccb -> cc. But then the backdoor has just been transmitted down the line to cc. Edit: also I just looked and it appears that CompCert is written in OCaml. This doesn't substantively change anything above. It just means that rather than having a backdoored gcc you'd have a backdoored ocamlc. Realistically the only way to truly assure that your compiler is not backdoored is by writing it yourself in assembly. But then, your assembler might be backdoored. So you need to write your own assembler in binary. But then your processor might be backdoored. So you need to design your own processor. And then you might be safe. Of course, if someone really cared enough to backdoor all that stuff, they'd probably just come after you with a rubber hose at that point. And I think that was the point Thompson was trying to make.

schoen 11y ago

We also had a closely related talk about this at the 31C3 which talks primarily about the motivation for the problem and how the Tor Browser has addressed it (leading into Debian stuff, but the Debian developers couldn't join us in person, so you can hear much more about the Debian side from the later talks that the article refers to). https://media.ccc.de/browse/congress/2014/31c3_-_6240_-_en_-_saal_g_-_201412271400_-_reproducible_builds_-_mike_perry_-_seth_schoen_-_hans_steiner.html https://media.ccc.de/browse/congress/2014/31c3_-_6240_-_en_-... I had two examples in that talk that I liked a lot: * What's the smallest change that you'd have to make to a binary to introduce an exploitable vulnerability? (I work through an answer in the talk.) * I demonstrate a kernel module that tampers with source code as it's being read by the compiler, so that nothing is modified on disk, and all of the source files are unmodified as confirmed by other software on the system, but the resulting binary is corrupt. You can also hear about my co-presenter Mike Perry's heroic efforts to make the Tor Browser build reproducibly, one of the first pieces of open source software of its size and complexity to do so. And definitely one that people are trying to distribute fake modified versions of (not necessarily with network MITMs, though quite possibly -- but even with simple e-mail phishing).

jongraehl 11y ago

You also have to trust the source code of the 'untrusted' compiler (that is, read it and make sure it doesn't directly contain any back door).

unhammer 11y ago
Or trust the source code of a simpler compiler that is able to compile the untrusted compiler: http://www.dwheeler.com/trusting-trust/ http://www.dwheeler.com/trusting-trust/

unhammer 11y ago

https://reproducible.alioth.debian.org/presentations/2015-08-13-CCCamp15.pdf https://reproducible.alioth.debian.org/presentations/2015-08... has some tips on what you can do to ensure your own FOSS packages have reproducible builds, e.g.: * avoid storing build-timestamps (maybe use timestamp of last commit instead) * avoid storing build numbers * LC_ALL=C sort the sets of things where order is undefined/unimportant, e.g. file lists going into tar or hash keys * try building, then changing something in the environment, building again and diffing (with diffoscope)