I wrote yesterday about the two exploits, Spectre and Meltdown . I think that the most amazing thing about the security weakness exposed is that it has been around for 20 years, in dozens of microprocessors, before coming to light this year. The only equivalent thing that I can remember was when Ken Thompson revealed, in his acceptance for the Turing Award, that "I cannot be trusted." Unix Ken Thompson, along with Dennis Ritchie, is the original author of Unix. This is the basis of iOS, MacOS, Linux, Android, and more. So it is the most important operating system ever developed. It can't have seemed like that at the time, since the reason it got developed at all is that Ken and Dennis "only" had a PDP-11 at Bell Labs and they wanted to get some work done. If you can read C and want to know more about it, I highly recommend trying to find a copy of John Lions' Commentary on UNIX 6th Edition with Source Code . It is just what it says, a book containing a full annotated version of the source code of the 6th edition of Unix. He created it to go with his course on operating systems at UNSW, but due to copyright restrictions on the code, it was not allowed to be published and so it was passed along like some sort of samizdat publication. Even today, although the operating system version is obsolete, it is a masterpiece of commentary on a complex program, and it is also a way to see the brilliant way that Ritchie and Thompson did so much with so limited resources. it also created a generation of computer scientists familiar with the UNIX operating system internals. As a result, Ritchie and Thompson won the 1983 ACM A.M. Turing Award, the rough equivalent of the Nobel Prize for Computer Science. In his acceptance speech/paper, Reflections on Trusting Trust , Ken Thompson revealed that (maybe) he had been able to log into any Unix system the world over, despite nothing showing in the source code. There were a lot of Unix systems in the world even then, since AT&T, as part of settling an anti-trust suit, had agreed not to enter the computer marketplace, so it gave Unix away for free since it couldn't sell it. This was before the days of the internet and open source, but was the closest thing to a piece of modern open-source software infrastructure, widely used in academia and, having infected the student population, eventually widely used in industry, too. It is only a slight exaggeration to say that the cloud runs on Unix. The Unix story itself is for another day. This is a look at what Ken revealed in his acceptance. He says it is not totally original, the basic idea came from an Air Force review of an early version of Multics. The similar sounding name is not a coincidence. Multics was a huge project involving a lot of institutions to develop the ultimate operating system. One of those institutions was Bell Labs, and Ritchie and Thompson worked on it. But AT&T pulled out of it, and Ritchie and Thompson wrote a little operating system for themselves, punned on the Multics name, and just happened, without any plan, to develop the ultimate operating system anyway. Ken Thompson Hack As a result of this lecture over 30 years ago, this is known as the Ken Thompson Hack or KTH. I should point out that Ken, on other occasions, said that they never implemented KTH. But one thing in the security world is that if something can be done, it should be assumed someone has done it. So, for example, recent proclamations that there is no evidence that Spectre and Meltdown have ever been used in the field should be taken with a grain of salt. There would be no way to tell if they have, and a good rule of thumb is that if security researchers discover some weakness, then the NSA (and their equivalents in China, UK, Russia, Israel and more) already knows about it and has exploited it. If you had control of the Unix source, like Ken did, then one way to make it so you could log into any Unix system would be to add a couple of lines of code to the login command to accept not just the correct password, but also your special magic password. However, that would be really obvious and somebody would soon notice it. But Ken had control of the C compiler source code, too. It is a bit mind-blowing the first time you come across it, but the compiler for the C programming language is itself written in C. KTH doesn't depend on this though. But a sneakier way to make your magic password work is to leave the source code to the login command unchanged, but fix the compiler so that it notices when it is compiling the login command, and adds your little bit of extra code. This is step one of the hack. If you read the source code of the login command then it is completely correct, and does not contain the security vulnerability. However, the C compiler contains some obviously wrong code. As he said in his lecture: Such blatant code would not go undetected for long. Even the most casual perusal of the source code of the C compiler would raise suspicions. Phase 2 is where it gets really sneaky. In addition to adding code to the C compiler to corrupt the login program, you also add code to the C compiler to corrupt the C compiler itself, by adding both the code to corrupt the login program, and the code to corrupt the C compiler. When the C compiler compiles the login program, it adds the magic password. When the C compiler compiles its own source code to create a new version of the compiler, it adds both the code to add the magic password, and adds the code to add the code to add the magic password. I know that is a bit complex and hard to get your head around. Ken's acceptance speech goes over the ideas of self-reproducing programs (of which this is sort of example). I remember myself when I went from deciding that a self-reproducing program was "obviously" impossible, to having the aha moment to see how to do it. But now for the real mind-blowing trick. Once you have created a new version of the C compiler, you go back and take out the code you added. The source code of the login command was already clean, but now, too, the source code of the C compiler is completely clean. And yet, if you make a new version of the login program, it will automatically get your backdoor inserted. Sneakier still, if you make a new version of the C compiler, even though you took the code out, the compiler will insert it anyway. Implications As Ken said: The moral is obvious. You can't trust code that you didn't totally create yourself (especially code from companies that employ people like me). No amount of source-level verification or scrutiny will protect you from using untrusted code. But that's just Unix. We work in the semiconductor and EDA industries. So the thought experiment is what happens if, instead of corrupting the source code for the login command, you corrupt the source code for a test insertion program? Instead of adding a backdoor password to the login command, if the corrupted tool detects it is adding scan test to a security block, it can add a few extra gates. Obviously, if you add a million gates to a design it will get noticed. But a few gates in a billion-gate design might well go unnoticed. Nobody has a clue what all those scan test gates do exactly, they just have to make sure the timing is right. A couple of years ago, I think in a DVCon keynote, Wally Rhines of Mentor said that he asked some "three-letter agency types" whether they were worried that the bad guys had broken into IP companies, and inserted some backdoors. He said they just laughed, in a way that implied he was naive to ask the question. Of course, the bad guys where doing it, and so were they. The KTH means that it would be possible to do that not by breaching the security of an IP company, and changing their Verilog, but going upstream to the compiler companies. Once the malicious code is inserted into the compiler (and then removed), the compiler source code is clean, the source code for the test insertion tool is clean, the Verilog for the chip is clean. And yet, there are a few extra gates added to every design to allow the test logic to be used to read out the secret keys (or something equally bad). Have a nice day! Sign up for Sunday Brunch, the weekly Breakfast Bytes email.![]()
↧