Slashdot Mirror
Classic Computer Vulnerability Analysis Revisited
redtail writes "The original authors of the classic vulnerability analysis of Multics have
revisited the lessons learned almost thirty years later. Their new
paper, along with the original vulnerability analysis is published here
by IBM. The original vulnerability analysis inspired the self-inserting
compiler back door described by Ken Thompson in his Turing
Award Lecture.
"
Poll: what might they refer to with these "major vendors". Sadly, I think that is very true. These "major vendors" are digging a huge hole behind the average users by just kludging together cheap fixes when the system is fundamentally wrong. As result, many will be in deep - unkludgeable - %&t in some 5-7 years when the system collapses.
Isn't Multics the legendary debacle that never turned into a usable product? Wasn't it a Grand Unified Solve-Everything Architecture? Wasn't it some kind of apotheosis of top-down design and other Best Practices?
Right! So, lesson number one from Multics is this: Don't do it that way. That, in fact, is the only lesson to be learned from Multics. You want more detail? Shoot the academics if they dare set foot off campus. Tucked away in their offices honing their algorithms, they do useful work -- but you can't ever, ever, ever let 'em influence the design of anything bigger than an algorithm.
Multics was the Java of operating systems.
"Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive" -- hey, that's me!
It's disappointing to see that a computer security paper written 30 years ago is still relevant today.
Indeed it is. However, if I recall correctly (the link is slashdotted, so I cannot check) the whole point of the paper is that this is a security "hole" (actually, it's not really a hole in itself, but more of a way to ascertain that a hole is not discovered) that cannot be closed. It describes a way of inserting a trojan into a program without it being visible in the source; the bottom line being that you can never trust code you didn't write directly for the machine, from scratch, yourself. And if this sort of bug was implemeted at hardware microcode level, you could not even trust writing directly for the machine.
That summary does not make the paper justice. Read it yourself when someone has posted a mirror. It's fascinating, simple, and absolutely brilliant.
"If you think education is expensive, try ignorance" - Derek Bok
> The original vulnerability analysis inspired the self-inserting compiler back door described by Ken Thompson in his Turing Award Lecture.
This is a nifty concept, but I remain skeptical that it would ever work in practice, at least for an open-source produce such as gcc.
For starts, the compiler would have to detect that it was compiling itself. I.e., if you compile your favorite flight similator and the resulting program is a compiler rather than a flight simulator, the game is up already.
But recognizing itself isn't going to be such an easy task. For instance, if it just compressed the input and compared the result to a saved target, you could easily defeat it by something as simple as changing the names of identifiers in the source code. (If the match was done on just part of the code, you would merely need to do global string substitutions on the identifiers.)
So AFAICT, the trojan would have to identify itself by looking at the structure or semantics of the source file. But that's going to be tricky too. If I add a feature to the compiler or fix a bug in it, recompile, and discover that the feature is missing or the bug is still present, the game is up (after a bit of vigorous head-scratching). So it looks to me like the trojan must not only detect structure or semantics reliably, it must also limit detection to a very small block of code, to reduce the risk that it will be modified and break the trojan. That block of code must be specific enough that the trojan is never triggered when compiling other programs, and non-arbitrary enough that no one will re-write it in a zeal of code clean-up.
And, as others have pointed out in the past, the trojan has no way of slipping past if you use another compiler to compile it with. Even with two untrusted compilers, you can get a clean compile so long as the two compilers don't support each others' trojans.
Sheesh, evil *and* a jerk. -- Jade
You learned about Turing from a Gibson novel? Is this a troll? I am suddenly overcome by a strange and unusual desire to yell something that usually confronts newbies in #linux on undernet when they want help installing Mandrake.
But I will resist it. I don't know what you mean by "the subject," so I'll try different angles.
For a biography, try Hodges' Alan Turing: The Enigma. I've not read it myself, but it has been very well received.
For an intro to some of his most influential ideas, try Introduction to the Theory of Computation by Sipser (the easiest book on the subject I've come across, but might be too hard anyway if you have no background in math or CS).
For his ideas on AI, see his original paper from 1950, which is now since long available online.
Also, you could just do a Google search (and should! Resorting to this kind of off topic questions is usually only defensible when finding information is hard).
"If you think education is expensive, try ignorance" - Derek Bok
Ken's back door program is most definitely the most interesting hack ever devised, IMO. Read about it here.
At the bottom, ESR claims that he "has heard two separate reports that suggest that the crocked login did make it out of Bell Labs, notably to BBN, and that it enabled at least one late-night login across the network by someone using the login name `kt'."
Unfortunately, the mainstream products of major vendors largely ignore these demonstrated technologies. In their defense most of the vendors would claim that the market-place is not prepared to pay for high price for high assurance of security
Keep in mind that the price to pay for security is often not simply a higher initial purchase price.
It can be in difficulty maintaining code. If you write something in Eiffel or SML, you avoid buffer overflow attacks on the stack, but you have a much smaller pool of programmers to hire from.
It can be in performance. Java is the most popular "safe" (array and pointer deref checked) language, but you pay a severe performance hit when using Java over C/C++.
It can be in convenience. I'm used to troubleshooting my system by just booting into single-user mode. If I was really secure, I'd have the bootloader passworded and an encrypted filesystem. But that's enough of an irritation to me that it's just not worth it.
And it's very difficult to get a good, objective overview of security. Most security analysts don't really know all that much -- they're working off their own biases and feelings as well. They tend to try to sell companies on one-time-cost, backed-by-a-big-name products like firewalls or expensive IDS systems, because that's what companies want to hear. Also, *so* many products are so insecure that it's really painful and can feel futile to try to secure a system -- you might fix one problem with your device only to find that an IC manufacturer that's one of your vendors has some testing mode that breaks all your security guarantees.
We need people willing to pay the price, a wider bed of knowledgeable security consultants, software written from scratch in a safe language, with strong constraints on it, components that one can build secure products out of, and a decade to put everything into place before we can really get secure products.
May we never see th
To quote from http://www.radium.ncsc.mil/tpep/epl/epl-by-class.h tml: "The distinguishing feature of systems in this class is the analysis derived from formal design specification and verification techniques and the resulting high degree of assurance that the TCB is correctly implemented. This assurance is developmental in nature, starting with a formal model of the security policy and a formal top-level specification (FTLS) of the design. In keeping with the extensive design and development analysis of the TCB required of systems in class (A1), more stringent configuration management is required and procedures are established for securely distributing the system to sites. A system security administrator is supported."
There haven't been many A1 systems: GEMSOS, SCOMP, and Boeing's MLS LAN are the only that completed (see http://www.radium.ncsc.mil/tpep/epl/historical.htm l for the full list of every product). The VAX project referred to in the paper never got the A1 approval, although it was clearly designed to meet the requirements.