Slashdot Mirror

← Back to Stories (view on slashdot.org)

Classic Computer Vulnerability Analysis Revisited

Posted by timothy on from the mr-potatohead-mr-potatohead dept.

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. "

5 of 173 comments (clear)

  1. Re: Alan Turing? by Black+Parrot · · Score: 3, Informative


    > 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
  2. Wrong. by Animats · · Score: 5, Informative
    Multics was one of the best operating systems ever in terms of reliablity and security. Go read the papers. People are still reusing basic ideas from Multics, like good CPU schedulers. Ease of use was mediocre, but then, this was ten years before DOS.

    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.

  3. Re:Self-inserting compiler. by agurkan · · Score: 2, Informative

    I think you are missing the point. This is more of a theoretical argument than a real threat. I am pretty sure none of the compilers I had used had this kind of bug. It is a very clever and sophisticated attack. And of course, it is hard to implement. The very interesting conclusion is, opensourcing cannot help this kind of attack. This attack moves the broken link in security chain out of the source.

    It is not impossible though. Realize that if you are actually planning to attack someone by this method you must be a trusted party by your victim-to-be. You must be the party that provides the compiler, so you probably also have the manpower to implement this.

    Your suggestion of discovering this during a patch can be bypassed very simply by putting the trojan code into initialization or cleanup part of the code which nobody would dare to change because it would break compatibilities.Also probably we are talking about a well established compiler that comes as the standard compiler with the OS itself. Those compilers have huge areas which are (believed to be) bug-free so will typically never be patched.

    This kind of attack can be prevented though, by monitoring. "Secrets and Lies" by Bruce Schneier deals with this issue. If you cannot stop someone at the gates, you can always catch them inside :-)

    --
    ato
  4. Facts, anyone? by bensonm · · Score: 3, Informative

    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.

  5. Resource for the curious by bensonm · · Score: 2, Informative

    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