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's disappointing to see that a computer security paper written 30 years ago is still relevant today.
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!
I thought the point of the DMCA was to let technology move faster by encouraging companies to leave their systems unsecure and making it illegal to discuss and exploit the vulnerabilities instead.
This kinda makes you wonder how today's security problems / vulnerabilities / exploits will be viewed in 30 years from now, and how these views will differ from today's.
quidquid latine dictum sit altum videtur.
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
""Wintermute is the recognition code for an AI. I've got the Turing Registry numbers. Artificial intelligence."
Can anyone recommend any good books on the subject?
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!
1) Windows *is* insecure, as many here point out. Those who know what they are talking about are not bitching but discussing. Those who don't have a clue are trolling. They are hardly the majority.
2) *Nix can also be insecure, depending on the software, and more importantly the skills of the person running the show. However (next point),
3) The article is *not* an OS comparison.
4) The article is *about* security flaws.
5) Most anti-"M$" security complaints here are regarding how Outlook automatically allows binary attachments to run unauthorized (and there are no priveleges to prevent anything).
6) The parent posted as an AC.
Slashdot: Where people pretend to be twice as smart as they really are by behaving like children.
"Funny how you guys bitch about how insecure Windows is .. yet I note with interest that it is not mentioned a single time in this report."
:-)
By now I think it is just understood.
The race isn't always to the swift... but that's the way to bet!
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.
Hmm, I think you better run off and get back to class. Kinder garden class that is.
Look up the history of Multics. What came before Multics?
Yes indeed! Multics was the "Java of operating systems." Later, it evolved into UNIX, and still later into Linux. Some of the old multics commands still work, essentially the same, as the original multics commands.
Multics could well and easily competed with any commercial system on the market -- however,
GE, Bell Labs, et. al. sold the multics system (and the GE computer business) to Honeywell in the early 70's. As a former Honeywell IS employee let me again assert a quote about Honeywell -- "Never underestimate the ability of Honeywell management to snatch defeat out of the jaws of victory."
Uh, it appears that they're already on the web.
The more they remain the same...
I'm amazed at how many simple problems we've failed to eliminate in the past 30 years. This 'false' laziness is perhaps one of the biggest enemies of security.
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.
Erm a circle *IS* a flat 2D shape. Only a sphere is 3D You cant just infer sphere from circle...
You've just countered your own argument...
>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
C'mon, everyone with any education in the classical world knew the Earth to be a sphere. The controversy was about not having Earth at the center of things -- you know, the Copernican/Galilean/Keplerian cosmology.
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
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'."
While it may be true that the earth was thought to be flat in the popular imagination, it was long understood by educated classes going back to some of the earliest seafaring civilizations that the world was indeed spherical.
Next time you pick a straw-man argument to pitch your faith, do us all a favor and pick a better one. In this case, your Liberty U. education is clearly showing.
But the real question is:
Is anyone using it?
Is anyone seriously considering using it?
There's way too many wonderful, innovative technologies that never really get off the ground because of sociological adoption issues.
Do you mean Multices was [blah blah web web blah McNealy marketing blah blah]...?
No, I mean it was a grotesquely overengineered fiasco which never had any practical use, just like Java. In both cases, the design was finalized before it was implemented. In both cases, hubris took over. Compare to successful operating systems like UNIX (or even Windows: Windows may be a dog, but people do at least find it usable), or to successful programming languages like C or that ugly little monstrosity Perl.
The verdict of history seems to be that good software designs start out relatively modest, and then they grow and change as people use them in the real world. Neither Multics nor Java was designed that way, and it shows.
Some people have found Java useful for some applications. So? That's also true of Smalltalk. It's true of batch files, for God's sake. Sun's multimillion-dollar advertising push has produced a resounding indifference among damn near everybody who actually writes code.
Java had two reasons for existing. One: Cross-platform binaries. That was a total failure. So they want us to use it on servers now -- where cross-platform binaries are irrelevant and the order-of-magnitude speed penalty of the JVM over native code is therefore totally unnecessary (yes, and Sun's marketing always did, and still does, conflate the AWT, the JVM, and the language itself, which is just plain annoying). Two: An OOP language with garbage collection and with a crude pretense of having no pointers. Well, okay, Point Two may have some value, if you've got a real low forehead and you can't cope with pointers or the delete operator, but it's not worth all that much in the end. Let's face it, pointers aren't hard to deal with. If you can't cope with pointers, you've got no business calling yourself a programmer anyhow. The "no-pointers" gibberish suggests that Java was aimed at the idiot market, but the idiots are saturated with Visual Basic already.
Java was a product of the reality-proof Internet hype of the late '90's. It was on life-support from day one. Let it die in peace.
"Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive" -- hey, that's me!
You shouldn't believe everything the teach you in school.
If it smells like fish....
Ken Thompson stole some cool ideas from Multics, like for example command-line plumbing and a hierarchical filesystem.
Nevertheless, Unix was an entirely new and much less ambitious system. See Thompson's thoughts on the subject here.
"Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive" -- hey, that's me!
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
Actually UNIX owes as much to the Berkeley Timeshring System developed for Project Genie running on the hacked SDS 930 that became the SDS 940 as it does to Multics.
The UNIX name pun and the command names like "ls" are Multicisms but fork() is from Project Genie
The lecture was given in 1983...
Or am I missing something?
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.
The UNIX name pun and the command names like "ls" are Multicisms but fork() is from Project Genie
/bin/ed and his RUNOFF was the ancestor of nroff.
Some commands came from Project Genie into Multics and then UNIX. Ken Thompson's QED begat
Not to put too fine a point on it, but your original post tends to confirm point 1 -- which I don't, btw, happen to agree with. Complaining about another idiotic post by responding with same merely adds even more weight to the assertion in 1. Whining about lame moderation doesn't help either. In fact, I think it would be better for Christians everywhere if you took a little hiatus from the Internet for a while.
80md! Glad to see you back in the habit! :)
At any rate, you speak the truth; those of us in the moral community have long known that academics are only good for three things: sociology, folk dancing, and guzzling expensive cappucino paid for by taxpayer dollars.
Yeah right. He was trolling... The :-) couldn't possibly mean that he was joking!
I tried to read it but after scrolling up and down over and over for a few pages thanks to that damn layout they chose I stoped after a few pages, why do people think that pdf is a good format for the web it doesnt scroll well, the font typicly look like crap, if your going to post pdf least have the damn sence to chose a one colom layout so you dont have to scroll and zoom constintly just to read it
Technically, it's an Oblate Spheriod, slightly flattened at the poles.
Pythagoras theorized in the 6th century BCE that the earth must be a sphere. However, those same "educated classes" continued to worship numerous astrological deities that today are recognized as false. But 200 years before Pythagoras, Isaiah 40:22 referred to the 'circle of the earth', using a Hebrew term 'chugh' which is defined as round or spherical object.
It is amazing that the Bible presented a scientifically sound statement, free from mythological ideas, thousands of years before the invention of UNIX . . . Quite amazing!
sorry!
Training the college students of America to play video games when they should be taking a bath.
If the Montana Freemen can be tortured and killed in the Gulags of North Carolina while their once-brave children mindlessly vegetate in front of their Pong games (ATARI IS A JAPANESE ORGANIZATION! ATARI IS NEITHER AMERICAN NOR CHRISTIAN!), who, indeed, can claim to be FREE?
I love my country, but I fear the Coca-Cola corporation. Surely, God will provide.
and it's just so straightforward too!
They could write the kernel in LISP, or maybe Smalltalk. It could be a walking museum of really great ideas which somehow got left behind for no reason at all -- I mean, aside from the fact that they were shit. Yeah, that's one small point to consider, but really, all also-rans turn out to be shit in the end, don't they?
Look at Linux! The darling of Wall Street for three weeks, until everybody realized it was a toy operating system with no tech support, no QA, and no future.
If it can't survive in the marketplace, it's garbage. Charles Darwin never sleeps. IBM isn't going to bother writing this magic SnakeOilOS for you because they know perfectly well that they can't compete with Windows. IBM just can't make a product that good. They'd be fools to waste money trying. IBM is a business, not a charity. They care more about their obligations to their stockholders matter than they do about your bong dreams. Get that through your thick head, Beavis.
In fact, let me just say this right now: I am absolutely sickened, I am disgusted, I am nauseated by your whimpering welfare-mother demand for the moon on a platter. Are you offering to donate one instant of your time or one penny of your own funds to this foredoomed catastrophe? No, of course not. Even if you were so willing, your time is worthless and you have no funds to speak of. You're just sitting on your fat ass in a dorm room somewhere with a can of cheap beer in your hand, gnawing on cold pizza with congealed grease on your chin. And food stamps paid for it all! Listen up, you lousy, filthy, adipose, flatulent, pock-marked, verminous parasite: If this were a just nation, we'd feed scum like you to the wolverines.
that's right, the backdoor will go in main(), all programs have main() in C/C++. The backdoor will be the first piece of code that executes when you run the program, so if you run the program and it doesn't see a compiler environment, it continues. Pretty simple.
Segmond
plump, rounded youngsters are far more tasty (and much easier to catch) than the physically-fit and God-fearing offspring of right-thinking real Americans.
It's more than just fleetness of foot, my friend: How popular is the Junior NRA in liberal hellholes like Cambridge, MA and Madison, Wisconsin? Don't make me laugh!
My children are armed and trained. They shoot straight and they know how to stay safe. Just let Susan Sontag or Marlon Brando come salivating after the tender little Christian delicacies I'm raising! They'll get a hollow-point between the eyes for their trouble. My little Lisa just got a new CZ .40 S&W for her birthday, and boy does she love that gun! She's like a kid in a candy store, shooting everything in sight.
God's been good to us, and as long as the youngsters keep their powder dry (and believe me, they will!), there won't be any leftist cannibals chowing down on my family.
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.
How many people contribute Open Source or Free Software to the world? How many opportunities have been created by the existence of successful, minimally reviewed GNU/Linux distributions for professional cracker community members to quietly introduce bugs? How many sites now run Red Hat, for example? How many of those installations are mission or security critical?
The security problems pointed at (ever so esoterically) in the cited articles are vast, serious, real, and pressing. They are made worse by vendors who persue dubious features and broken, overly complex architectures rather than remembering to KISS and empower customers to differentiate their installations and (especially in a disaster) manage their own source.
The good news: using plenty of available technologies and techniques to reduce the RISKS here can, as a side effect, radically improve the overall quality of the Free/Open Source software being vended these days. We need fewer, but much better features, managed by much better software engineering practices.
That (in my opinion), rather than panicing over security issues, is where our various corporate friends ought to focus in response to this and similar articles.
-t
Even then, they understood that bugs should be published openly. To quote section 1.3.1 "Concealment of such penetrations does nothing to deter a sophisticated penetrator and can in fact impede technical interchange and delay the development of a proper solutions. A system which contains nulnerabilities cannot be protected by keeping those vulnerabilities secret. It can only be protected by the constraining (sic) of physical access to the system."
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.
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)
BigGreen03 & Chexsum, you are two A1 schmucks!
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.
I believe that you are the first.
Well done!
(/me reads at -1)
Face it... if it was assembled, it can be disassembled. Once disassembled, the secrets implanted by a compiler or programmer are revealed. DeCSS is a good example of disassembly finding something hidden.
Worried about your login program being trojaned? Open it up in a disassembler and check near the login part of the code. Hell, open the program up in a debugger and just step through the code. That would trivially show you any "if password = backdoorpassword" statements. In many ways this is even faster than looking at the source itself. For those paranoid about the OS itself, there is even hardware you can buy that'll debug the os itself.
What really worries me isn't this kinda security issue... what worries me is not being able to legally look for these kind of security issues at all. (read: DMCA)
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
How do you compile gcc? You build it from source using a binary of gcc and
Even gcc isn't safe.
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.
Multics was still in use in installations for high-security military use as recently as 1987.
When I did an '87 summer course on compiler design on the Stanford campus, one of my classmates was from a Canadian company that had taken over some portion of the software maintenance for it. I'm sure by that time they had a hell of a time repairing the hardware, but it was still in use.
They had also spent the intervening years on auditing the system for security and finding and fixing ever more subtle holes and privilege escalation problems.... Part of the moral should be don't ever assume you're done finding bugs, because you can always find some more.