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.
"
It would be a great opportunity for IBM to look back on its roots and develop another OS that is built for security from the ground up. Too bad the price for that would be ungodly. They could have a new OS platform that would be innovative, yet built on the ideas that got IBM to where they are today. I would honestly like to see ANOTHER alternative to Microsoft/UNIX/ and yes, Linux. Although I am a true believer in old school UNIX, I would like to see a new platform that is interesting, bullet-proof, and innovative. Anyone else? j
Step 1. Write code. Step 2. ??? Step 3. Profit!
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
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.
Multics was the Java of operating systems.
What do you mean by this? Do you mean Multices was originally an operating system marketed for web interoperability but eventually found its foothold in the server application arena, and is now very sucessfull both in this regard as well as a web application platform? No? Didn't think so.
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
There was an excellent docu film done on his life. http://us.imdb.com/Title?0115749
Uh, it appears that they're already on the web.
> 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.
>Isn't Multics the legendary debacle that never >turned into a usable product?
Nope. Multics begat Unix. Thompson took many of the lessons learned from Multics and used them in writing Unix.
Brian Ellenberger
DoD used Multics for a long, long time. DOCKMASTER, the NSA's public access Multics machine, ran until 1998. They couldn't find something secure enough to replace it. Finally, Honeywell just wouldn't supply parts any more.
> 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'."
Turing was an old computer theoritician, responsible for most of the foundations of computing, like the concept of a language to describe an algorithm more complex than simple standard algebraic symbols, and the "Turing Machine." Of course there were others in the field, like von Neumann. He was also noted for being gay during which it was not only discriminated against, but outright illegal. Finally, I believe there's a statue in England of him eating an apple; noteworthy because he committed suicide by eating a poisoned apple. Quite a morbid statue, huh?
Yes, he did come up with the original Turing Test but compared to his groundwork in Computers, the turing test is like a book of science fiction: somewhat innovative, but mostly inspired by other people's (Asimov) work.
I Browse at +4 Flamebait
Open Source Sysadmin
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.
and it's just so straightforward too!
- Art of War
is still relevant thousands of years later.Some people just hit the nail on the head, that's all.
WHy? Well first off they are first vendor to introduce pallidium. The proof is in the pudding. Here are some nice crippled laptops, with the ultra secure TCPA security subsystem clearly advertised. ALso here are some nice netvista workstations with the TCPA security 2.0 subsystem all nicely installed for the RIAA oops I mean your convience.
We all talk about HP comming out with drm pc's this christmass yet IBM has been selling them to the public for several months already! THe difference between the TCPA vs the Pallidium standard is that the TCPA has a protected boot sector. Meaning without a key you can not boot any other OS but WindowsXP. IBM is an enemy of Linux and should righteously be boycotted. They care more about the profits of software developers and hollywood then opensource.
http://saveie6.com/
What I found interesting was the reference to the Holy Grail... A1.
They referenced GEMSOS and a VMS variant as having reached that point. I thought it was only theoretical. Doesn't A1 cert require mathematical proof of security (as well as the usual auditing)?
Fascism starts when the efficiency of the government becomes more important than the rights of the people.
One thing I find missing for C programming is a generally accepted security tool. In the rush to get things out the door with new and whizbang features, little is done on security tools. This is true of both commercial and OpenSource environments. People still use gets, people still take things from the environment unsafely. Taintperl is great, why isn't there TaintC or the equivalent? Why is there not a single tool that has a database of past exploits and knows how to detect at least a subset of these? yes, I realize that a program can never replace a good set of eyes looking at a program, but I also keep my compiler warnings cranked up high to detect "I'm a dumb-ass" mistakes. Why can't we hook this into the optimizer, since it must do lexical and data analysis anyway? Get these mistakes caught early before they get stuck in released in the wild code. Why is sling still such vapor? AFAIK, they still haven't updated lint to work with C++ code yet, we're still in someways in the sticks and stones era of tools for programming.
And no flame wars on language choice, please.
KeyKOS solved a lot of the problems this paper describes in the 80s, and its descendent EROS is solving them today (and open source, too!).
Unfortunately, in the 80s people were so infatuated with micros that secure timesharing wasn't a big market, and today people have been living with insecure systems so long they have stopped caring.
s/A.I. theoretician/computer scientist/
actually, shouldn't that be s/A.I. theoretician/biologist\/cryptogropher\/computer scientist\/mathematician? I know he was originally a biologist by trade and then was better known for his Bletchley Park which was related to his CS theory but in a more Von Neumann sort of way.
What is music when you despise all sound?
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
The technique works fine and not difficult to do -- as long as it isn't GCC. And the rest of your post assumes that GCC is in use. (How many other compilers are out there which have source available (you mention changing contents of the source code) and are designed to be built by multiple arbitrary compilers (the GCC bootstrap mechanism)?
Of those, how may are meant to be modified by the user? (Where "meant" == "it's possible".)
So, reminding the rest of /. readers that most compilers in use are not gcc (unfortunately), we proceed:
Compilers that detect special semantics would be easy, because you don't know what the semantics are, only I do. My compiler can perform some completely useless action with no side-effects (i.e., you can't detect it), and while compiling itself, would a) realize that its own code is being compiled, and b) throw out the useless actions, like any other optimizing compiler would.
Remember that the special thing being detected doesn't have to be detectable at runtime, only at compile time. That opens the doors much wider.
So, use GCC and prevent this trojan. :-) Otherwise, yes, it's very possible.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
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.
Buy a bigger monitor. Heck I was on a laptop and it read fine.
Actually the classical world was split if we were at the center of things or if the sun was. The real controversy for Kepler... was that the earth didn't orbit the sun in a perfect circle but rather in irregular ellipse. A perfect circle implied a divine hand, an irregular ellipse looks more like chance.
From the introduction of the new paper: "However, the bottom line conclusion was that 'restructuring is essential' around a verifiable 'security kernel' before using Multics (or any other system) in an open environment (as in today's internet)".
Paragraph 3: "We hypothesised that professional penetrators would find that distribution of malicious software would prove to be the attack of choice."
Dropped in as a random sentence in paragraph 5, without much relation to the surrounding text: "Multics source code was readable by any user on the MIT site, much as source code for open source systems is generally available today."
From the conclusion of the new paper: "In nearly thirty years since the report, it has been demonstrated that the technology direction that was speculative at the time can actually be implemented and provides an effective solution to the problem of malicious software employed by well-motivated professionals. [...] And customers have said they have never been offered mainstream commercial products that give them such a choice, so they are left with several ineffective solutions [...]".
If you look at what is actually being demonstrated in the original paper, is that a monitor is needed that governs every memory access, without bypasses. The new paper admits that the VAX was the first to have this, and of course all modern MMUs do exactly that.
So what's the big deal? Why was this published at this time? If you read carefully, you can correctly conclude that we don't need no steenkin' Palladium to get secure systems today; we already have all the hardware features needed. However, if you skim the new paper, you could be led to believe that Palladium is absolutely essential...
All generalizations are false, including this one. (Mark Twain)
I hope not to get trolled for posting a reference that is probably not too hard to find on search engines. However, if any of the readers of this would like to see a much broader range of information on Multics, I can recommend:
The reference web site for Multics history
About 1980 Paul Green and (I think) other multicians started a successful fault-tolerant computer company called Stratus, an effective competitor to Tandem. VOS, the OS, was clearly inspired by Multics and had, or rather has, a consistency and reliability unparalleled in Unix.
Its Multics traits include PL/1 as the systems programming language (actually a subset), transparent networking (attach to any device or file anywhere, rather like Apollo Domain), an ancient Emacs port (or clone?) and other useful features like a transactional file system with indexing.
Lots of these expensive machines were sold to banks and other demanding users in the late 80s, there are plenty still around and indeed they're still available.
The boxes were large and well engineered. Quality seemed to be taken very seriously since any crash was a major event - I only remember one OS crash bug in 6 years of working with them. Machines were connected via dialup to the service centre, and core dumps uploaded for analysis automatically (security settings permitting).
All items of hardware, disks, CPU, memory, networking cards were duplicated - except the real-time clock (!) monitored for failures. Any failed device would be removed from service and could be replaced while the system was running - 'go on, pick a board to unplug' demos were always popular.
Coming back to Unix after platform was a pretty rude shock. What horribly eccentric and buggy shell commands! Why does it keep crashing? In many ways I'd quite like to have one today, certainly something like Java would complement it quite nicely.
When will /. get it through its skull that you don't have to use GCC to build GCC? And in fact, that most people don't use GCC to build GCC?
You cannot apply a technological solution to a sociological problem. (Edwards' Law)