Reproducible builds in Debian: preventing compiler backdoors
motherboard.vice.com
motherboard.vice.com
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).
Not sure how that is going to shut down the CIA though, maybe I missed it.
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.
"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.
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....
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.
Now, I did have a method to solve problem you're addressing. You implement an assembler first. Then a macro assembler with macro's for HLL primitives. You can use that immediately to jmplement certified compiler. Alternately, you can pick up Oberon report or Scheme book to implement that to get a true HLL plus compiler. Then you implememt the certified compiler with it. Comprehension, code complexity, and trust are kept manageable by building layer by layer. This, for productivity not security, is how Wirth and Carl first built Lilith then Oberon. Same method will work again and good that ML/Scheme/Oberon folks already gave us doc's plus code to use. Lets use them.
https://speakerdeck.com/nineties/creating-a-language-using-o...
Note: LISP/Scheme interpreters and processors with plenty of detail (including source) can be found with Google. Many implemented before 1990. Will run on cheap FPGA's or process nodes. Can take it all the way to hardware. ;)
The macro ASM can be built on something like P-code: an idealized, low-level machine easy to deploy on CISC and RISC architectures. A good example of how to bridge ASM and HLL's is Hyde's High Level Assembly:
http://www.plantation-productions.com/Webster/
The HLL, for non-LISP audience, can be Oberon with aid of Wirth's Compiler Construction book among other papers:
http://www.ethoberon.ethz.ch/WirthPubl/CBEAll.pdf
So, many possibilities. People just gotta use them. Build a LISP w/ macros to build everything else still seems to be easiest strategy. Esp as one can reuse code from textbooks unlikely to be subverted. Wirth's next best.
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.
Not to get too far away from your overall point, which may be valid, but... is it relevant what any of these agencies is "tasked" with on paper? It's quite clear, and has been for decades, that these agencies are so powerful that they are effectively outside / above the law, and can do whatever they want. The NSA wasn't "tasked with" conducting indiscriminate surveillance on damn near everybody alive, but they did it anyway, lied about it, and never got punished. The CIA wasn't tasked with experimenting on innocent American citizens by dosing them with drugs against their will and without they knowledge, but they did it anyway.
As far as I'm concerned, every single shred of skepticism and scorn for these agencies that you encounter, is something they earned through their actions.
I'm sure there are good people inside the CIA, FBI, NSA, TSA, DHS, etc. And I feel bad for saying hurtful things towards or about those people. But their agencies have created a state of war between themselves and the American people, if not the entire global population. I'm sorry, but if the good people inside these agencies don't want to get slagged, the onus is on them to find a way to change things, or to get out.
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)
If by "unlocked" you mean get access to their data, and phones can just be unlocked by taking them to Apple, they are certainly not the most freaking rock solid phone security-wise.
It's not like you take it to Apple and Apple says to you "Here's the user's data.". There is something like a 60-90 day wait period while they analyze each individual request for approval, and do their due diligence to make sure access is justified. Juxtapose that with a typical android phone that can be rooted without the help of the manufacturer, and then you get that the customer is better served by one process over the other.
Edit: previously in his paper with Ross Anderson https://www.cl.cam.ac.uk/~fms27/papers/1999-StajanoAnd-duckl...
My ThinkPad can easily be reinstalled with a new OS, but my OS vendor can't give someone else my full-disk encryption keys or make them root on my device. And even with firmware-level security features we can separate "transfer ownership of device" from "access existing protected device state".
I don't see any more reason that mobile phone vendors must be able to bypass screen locks or disk encryption than that desktop OS vendors must be able to do these things. (Sure, in both cases some users would want the vendor to be able to and others wouldn't.)
The best security is when only you can get your data and nobody else.
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.