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.
"
With the growth of individual workstations and personal computers, developers concluded (incorrectly) that security was not as important on minicomputers or single-user computers. As the Internet grew, it became clear that even single-user computers needed security, but those ill-founded decisions continue to haunt us today.
Big shock. AC does not read article. Weakly attempts a troll.
The opposite of progress is congress
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
> Is this award named after the A.I. theoretician?
s/A.I. theoretician/computer scientist/
He did have an influence on AI (cf. "Turing test") and on the more general concept of intelligence-as-computation (whether natural or artificial), but we generally think of him for his more fundamental contributions to computer science (cf. "Turing machine").
Sheesh, evil *and* a jerk. -- Jade
The big problem was that Multics was tied to a specific model of General Electric computer with custom security hardware. GE built some good early time-sharing systems in the 1960s, but sold off their computing business to Honeywell in the 1970s. Honeywell never marketed the Multics product line seriously, because it competed with other product lines that sold in bigger volume.
> 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'."
Plan-9 was not designed from the ground up and certainly not for security. Plan-9 had some features beyond the UNIX core but it was certainly not a clean sheet of paper job. The first version even came out with the typesetter and games programs that were long since obsolete under UNIX.
The only O/S that I know of to be designed 'from the ground up' since VM-UNIX came out is Windows NT. UNIX was started before VMS but did not leave the research lab until after VMS launched. OS-X is simply a merger of NeXTStep and Mac-OS.
Windows NT the operating system is designed from the ground up to meet the Orange book B2 security requirements. That statement means less than it might when you find out what B2 means, i.e. almost nothing relevant to the real world. A B2 O/S cannot be connected to any sort of network and remain B2 secure, still interested?
The point is that design of the O/S is irrelevant unless the applications are also designed to be secure. There have been remarkably few security compromises of either UNIX or Windows NT, almost all the bug reports are in the layered applications. Take Outlook off Windows and Sendmail off Unix and the stats look oh so much better. Ten years ago I had a flame war with Eric Altman which later made it to the UNIX Hater's list, basically he said that he had finaly got a grip on the bugs and I pointed out that he still had no process and no clue when it came to security. Guess what, he still hasn't.
There are plenty of good replacements for sendmail that do not introduce arbitrary Turing complete languages for arbitrary purposes. Unfortunately the UNIX world simply won't use them.
There is a company working on a secure O/S, it requires secure hardware and is codenamed Palladium. You still want more security?
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
Third, stacks on the Multics processors grew in the positive direction, rather than the negative direction. This meant that if you actually accomplished a buffer overflow, you would be overwriting unused stack frames rather than your own return pointer, making exploitation much more difficult.
How hard would this be to integrate this into GNU C and Linux? As I understand it, growing the heap from the bottom and growing the stack from the top with the yet unused space in the middle is just a matter of convention. How much trouble would it be to reverse the two so that the heap grows from the top and the stack from the bottom?
Seems like it ought to be a simple patch to the most vexing class of security problems we all experience.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
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
Multics had significant commercial success, both in secure timesharing applications in the US and in Europe. In the end, Honeywell placed its bets elsewhere, and Multics withered away. To those of us who worked in it, the sneering comments about 'top down debacle' are an ongoing demonstration of Gresham's law as it applies to information on the Internet. Ignorance is never, seemingly, an impediment to a smart-ass comment. Try using, perchance, a system in which all the command line arguments were consistent and predictable, and the command names were meaningful. Or, for that matter, a system in which the fundamental data access model was mapping into memory. Or in which there are more security domains than 'all-powerful-root' and 'everyone else'. Unix was born as an effort to get some approximation of Multics onto minicomputer hardware. It worked pretty well. The authors of Unix weren't too fond of our rather structured development process. They didn't need the security and reliability that we did all that work to try to get, and they did want heaps of functionality from unpaid grad students in no time flat. Over the years, many of Multics' ideas have slowly leaked back into Unix: dynamic linking, memory mapping, command args with names and not just letters, etc. No surprise: they were good ideas, and Unix has absorbed them as processor power, memory prices, and the slow pace of rediscovery of the wheel has allowed. There's quite a platoon of Multics alumni in the industry, applying the lessons we learned, good and bad, wherever we go.