Secure Coding mailing list archives
Re: Re: White paper: "Many Eyes" - No Assurance Against Many Spies
From: Glenn and Mary Everhart <Everhart () gce com>
Date: Mon, 03 May 2004 16:31:40 +0100
Tad Anhalt wrote: Jeremy Epstein wrote: I agree with much of what he says about the potential for infiltration of bad stuff into Linux, but he's comparing apples and oranges. He's comparing a large, complex open source product to a small, simple closed source product. I claim that if you ignore the open/closed part, the difference in trustworthiness comes from the difference between small and large. It's a lot deeper than that. Here's the link to the original Ken Thompson speech for convenience sake: http://www.acm.org/classics/sep95 This should be required reading (with a test following) for everyone who ever touches code IMHO. Simple, elegant, understandable and devastating. It's the difference between proving that there aren't problems and hoping that there aren't problems. Linux is really a peripheral issue. The same arguments could be used against any operating system and/or software system that hasn't been designed and implemented from day 1 with this sort of issue in mind. A more interesting quote is this one: "A few people who understood Ken Thompsonâs paper wrote to me saying that every operating system has this problem, so my indictment of Linux security on this point is meaningless. They ask: âcouldnât someone at Green Hills Software install a binary virus in the baseline Green Hills Software compiler distribution and corrupt Green Hills Softwareâs INTEGRITY operating system?â No, the FAA DO-178B Level A certification process systematically checks every byte of object code of our INTEGRITY-178B operating system to ensure that if malicious code is introduced at any point throughout the tool chain (compiler, assembler, linker, run-time libraries, etc.) it will be detected and removed. Since INTEGRITY has only a few thousand lines of privileged-mode code, not the millions of lines that burden Linux, this means of preventing viruses is feasible for INTEGRITY, but not for Linux." How did they bootstrap their system? In other words, how did they ensure that they could trust their entire tool chain in the first place? They hint that the whole system was written by a few trusted persons. Did they write the whole tool chain as well? The scheme above protects against future attack, but not against something that was there before they started. I'm sure that they have an answer for that question, it's a pretty obvious one to ask... Maybe I missed it on my read-through? That's the whole point of the Thompson lecture. The hole is really deep. How far can you afford to dig? How do you decide what to trust? Green Hills Software obviously has a vested interest in convincing the reader that it's worth paying them whatever it is that they're charging for the extra depth... In some situations, it may be... That's a risk management decision. Tad Anhalt I remember back when DoD was trying to get a processor and OS combination certified as Class A1 per the Orange Book. I also happened to be working (on a separate project) with Richard Platek at the time, when he discovered that the MLS prover had some failures that would allow it to miss insecure data flows, thus throwing the whole proof into a cocked hat. This was for I think SCOMP. Anyway, he was asked not to disclose this but felt he had to, and did. Now, the exception conditions were manually checked for and there was a certification that all was well, but underneath it all, the premise that a Federal certification of security was a guarantee was destroyed by that incident. And now we are expected to believe a commercial vendor's assurance that something is checking OBJECT CODE against a Thompson type Trojan? Well, if the trojan is large enough and the rest of the code small, I could believe it would be hard to hide. A real life intro of a subtlety that might just involve a BGTR instead of a BGE branch somewhere, or a "=" instead of "==" in C, could be much harder to find. At any rate trusting a Federal cert lacks credibility taken alone. Show us the high quality decompilations of large systems first. Then maybe such a thing would be easier to believe.
Current thread:
- White paper: "Many Eyes" - No Assurance Against Many Spies Kenneth R. van Wyk (Apr 29)
- Re: White paper: "Many Eyes" - No Assurance Against Many Spies dtalk-ml (Apr 29)
- RE: White paper: "Many Eyes" - No Assurance Against Many Spies Dave Paris (Apr 30)
- Re: White paper: "Many Eyes" - No Assurance Against Many Spies der Mouse (Apr 30)
- <Possible follow-ups>
- RE: Re: White paper: "Many Eyes" - No Assurance Against Many Spies Jeremy Epstein (Apr 29)
- Re: Re: White paper: "Many Eyes" - No Assurance Against Many Spies James Walden (Apr 30)
- Re: Re: White paper: "Many Eyes" - No Assurance Against Many Spies Tad Anhalt (Apr 30)
- Re: Re: White paper: "Many Eyes" - No Assurance Against Many Spies ljknews (Apr 30)
- Re: Re: White paper: "Many Eyes" - No Assurance Against Many Spies Glenn and Mary Everhart (May 03)
- Re: Re: White paper: "Many Eyes" - No Assurance Against Many Spies Crispin Cowan (May 03)
- Re: Re: White paper: "Many Eyes" - No Assurance Against Many Spies Tad Anhalt (May 04)