|
| Linux Security Controversy Dan O’Dowd, CEO of Green Hills Software, Inc. Part II
|
|
||||||||||||||||||||||||||||||||||||
| Privileged-Mode Code The most critical software in a computer system is the operating system code that runs in the computer’s privileged mode. Privileged-mode code controls all of the operations, communications, and security of the computer system. It has unrestricted access to anything in the computer. Privileged-mode code can read or write any data on any device. It can send or receive messages from any other computer system, disk drive, or monitor. It can do anything it wants with anything that the computer controls, it can turn (or not turn) the tank, fire (or not fire) the missile, transmit (or not transmit) a message. Privileged-mode code can read any secret encryption keys stored on the computer system, it can monitor the keyboard to capture any passwords as they are typed in, and it can use those encryption keys, passwords, and its complete control over every encryption device and all encryption software on the system to encrypt or decrypt any message that passes through or is stored on the computer system. It can then transmit that message to any other computer system on any computer network to which the computer system is connected without creating any record of the transmission. Privileged-mode code can bypass all security checks and encryption. There is no hardware security system that can protect a computer system from complete seizure by malicious privileged-mode code. The primary objective of an attacker is to insert privileged-mode code into the operating system. This enables the attacker to gain complete control of the system and download any amount of additional attack, analysis, disruption, or spy software. No matter how secure the design of the hardware, algorithms, encryption chips, and application software, a few lines of malicious privileged-mode code defeats the security of the entire system and any other systems that depend on it. There are plans to deploy Linux in new defense systems including the Global Information Grid and Future Combat Systems. These systems (command and control, radios, tanks, aircraft, etc.) will share information over the Internet from sensors to decision makers and back out to field-based military personnel, “edge-to-edge.” Relying on an insecure operating system at any point in the chain, from data gathering to communications to control of equipment, means that these defense systems can be easily subverted, spied on, or redirected at any time by our enemies. Many Spies The most basic security principle goes back thousands of years and is firmly rooted in common sense: don’t have your potential enemies build your military defenses. You would have to be extremely naïve to not expect a potential enemy to try to sabotage your defenses if given the chance. In addition, if your enemies know exactly what your defenses are, they can effectively plan how to overcome them. MontaVista and LynuxWorks, two of the largest embedded Linux vendors, outsource their embedded Linux development to Russia, China, and other countries from which we would never buy defense software. Every day code is added to Linux in Russia and China. Every day Linux code is being downloaded and embedded into our most advanced defense systems where it can be exploited to seize total control. We must always be aware of the possibility that the low bidder for our defense work may be foreign intelligence services or terrorists. In fact, they would do it for free. They might even leave free software lying around on the Internet hoping their potential enemies would incorporate it into their defense systems. Linux is the classic Trojan horse scenario. Some people object to my characterization of Linux as a Trojan horse based on the misconception that the Trojans couldn’t see inside of the Trojan horse, whereas anyone can see inside Linux. The Trojans could have seen inside the wooden horse by employing a few hand tools. They chose not to look inside. The Trojans’ error was bringing a gift horse of questionable origin inside their defenses without demanding proof that there was nothing dangerous inside. Just a few Greek soldiers concealed inside the wooden horse were all that it took to open the gates of Troy to let in the Greek army. Seeing dangerous code inside of Linux is far more difficult than some would have you believe. Linux is so large that a few lines of malicious privileged-mode code could be easily hidden among millions of lines of innocent code. If we put Linux in charge of our defense systems, just a few lines of malicious code could open up the Linux security system for an enemy to spy on, destroy, or commandeer our defense systems. Since Linux development and support are being outsourced to countries from which defense software would never be purchased, it is not enough for us to know of no subversions in Linux. We must assume that Linux has been subverted. Before we turn our defense systems over to Linux, we must demand irrefutable proof that it contains no malicious code. If we treat Linux like a gift horse and bring it inside of our defenses without demanding proof that there is nothing dangerous inside, we deserve the fate of Troy. Infiltrating back doors into Linux is trivial It is trivial to infiltrate the loose association of Linux organizations which have developers all over the world, especially when these organizations don’t even try to prevent infiltration, they accept code from anyone. There are over a million lines of privileged-mode (and setuid root) code in Linux in which to hide vulnerabilities. Much of the code is poorly documented and there aren’t unit tests for each function and line of code, so no one really knows exactly what each of these millions of lines are supposed to do. And there has never been a systematic safety or security certification of Linux by a third party agency like the Federal Aviation Administration or the NSA. A “back door” is code that is intentionally inserted into a program that enables the attacker to penetrate the system’s security at a later time. Some people have argued that it would be very difficult to infiltrate a back door into Linux because the Linux kernel is closely controlled by Linus Torvalds. But remember that Ken Thompson, the originator of the UNIX operating system upon which Linux is modeled, infiltrated a back door into UNIX (as described below). Even if no one in the core Linux team intentionally introduces a back door into Linux, they could be tricked into inserting a back door by a clever contributor making several submissions, each of which appears innocuous. In addition, since Linux device drivers run in privileged-mode, they are ideal places to insert back doors that can seize total control of the system. And where do Linux device drivers originate? They are written by large numbers of developers from all over the world with no central supervision. Corrupted device drivers are an easy way to attack Linux. Linux networking and communications protocol stacks usually run in privileged-mode so they could be subverted without Linus Torvalds being involved. There are also a large number of setuid root programs in Linux, each of which, if compromised, could seize total control of the system. Another vulnerability of Linux is that even though there is one central place for the official Linux kernels approved by Linus Torvalds, there are dozens of vendors, such as Red Hat, MontaVista, LynuxWorks, Debian, SuSE/Novell, TimeSys and FSM Labs and open source consortiums such as Open Source Development Labs and the Consumer Electronics Linux Forum, each of which modifies and maintains its own versions of the kernel outside of Linus Torvalds’ control. These organizations offer many points for an attacker to infiltrate. If you download a kernel from any place other than Linus Torvalds’ site, you can’t count on his personal integrity and competence to protect you from back doors inserted after the kernel left his control. The chance of someone infiltrating a back door into Linux is close to 100%. Infiltrating back doors into the INTEGRITY-178B operating system is virtually impossible Our INTEGRITY-178B real-time operating system was developed and is supported by a small tight-knit team. There are only a few thousand lines of privileged-mode code in the INTEGRITY-178B operating system. Every single line of privileged mode code is comprehensively documented and tested. Every single change must be justified, documented, and approved by many people, including several who have a comprehensive understanding of security vulnerabilities. They also have a complete understanding of the purpose and function of every single line of privileged-mode code, so they know how each line of privileged mode code interacts with every other line of privileged-mode code. And the INTEGRITY-178B operating system has passed many audits and certifications by third parties such as the FAA, NSA, and our customers. INTEGRITY device drivers and networking and communication protocol stacks don’t have to operate in privileged-mode so they don’t create the same opportunities for subversion as in Linux. All versions of our high reliability and high security certified INTEGRITY-178B distributions are controlled by Green Hills Software. There are no external variants creating opportunities for subversion. The chance of someone infiltrating a back door into our DO-178B Level A certified INTEGRITY-178B real-time operating system is close to 0%. The “Many Eyes” Security Fallacy Most serious security problems are the result of bugs in privileged-mode code. Every bug in privileged-mode code is a potential security hole. Most viruses and worms exploit a bug that has often existed for years in the privileged-mode code without detection. Once a virus or worm exploits a bug to get into privileged mode, it is game-over: the attacker completely owns the computer system. Hundreds of bugs in Linux privileged-mode code are identified every year. Many of these critical security bugs have been in the code for years without being detected. In fact, few security bugs are detected by source code inspection at all, they are usually only detected when someone figures out how to release a worm or virus that exploits the bug. Proactive (“many eyes”) source code inspection of Linux finds only a small percentage of all Linux security holes. An infiltrator can insert an intentional bug (similar to the many unintentional bugs that slip by source code detection) in privileged-mode code to create a back door, malicious code, a Trojan horse, or some other subversion. There is no functional difference between an unintentional bug and an intentional bug, the only difference is the intent of the person who put the bug in the code. Most subtle unintentional bugs that last for a long time are the result of an unexpected interaction of two parts of the code which are far apart in the program. Anyone looking at either part of the bug sees a reasonable piece of code. Similarly, it is easy to hide an intentional bug by separating the bug into several distinct pieces of code, each of which by itself is innocuous. If these pieces of code are placed far apart in the program, it is very unlikely that any one person will look at all of the pieces of code close enough in time to recognize that they can cooperate to create a vulnerability. The misconception that publishing the source code for a program will lead to finding all of the intentional bugs placed in the code is based on the silly assumption that looking at source code is an effective way of finding all the bugs. If it were possible to find all of the bugs (accidental or intentional) in a program by source code inspection, then we would have no need to debug code. We would write the source code, inspect the source code, and remove all of the bugs. We would have no need for source-level debuggers. All of our programs would be bug-free. Removing the majority of the bugs by source code inspection is pure fantasy. Almost all operating system bugs are found only because someone reported that the operating system didn’t work correctly and a programmer used a debugger (or print statements) to find the bug. It is rare for anyone to even try to find an operating system bug until it causes the operating system to work incorrectly. A clever subversion will never cause the operating system to work incorrectly except when it is being exploited by its inventor. Even then, only the inventor usually sees the incorrect operation. If an intentional bug never manifests itself for the development team they will never even look for it. This will allow the intentional bug to live in the code for a very long time among the thousands of other undetected bugs. Is it harder to find an unintentional bug or an intentional bug? An unintentional bug was placed in the source code by an honest developer by accident with no intent of hiding it. An intentional bug was placed in the source code by an infiltrator with the knowledge that others will be looking at the code attempting to remove all bugs (intentional and unintentional), therefore the infiltrator tries to hide the bug. How can anyone believe that the open source process efficiently eradicates all of the cleverly hidden intentional bugs when it can’t find thousands of unintentional bugs left lying around in the source code? You can’t defend the proposition that Linux is immune to subversion until you can defend the proposition that there are no bugs in Linux privileged-mode code. Most people are under the misconception that it is impossible for any operating system to have no known bugs in privileged-mode code, implying that no operating system is really secure. But that is not true. There are no outstanding bugs in our DO-178B Level A certified INTEGRITY-178B real-time operating system. This is the true reliability and security that our national defense systems need. Ken Thompson’s Subversion Before most Linux developers were born, Ken Thompson irrefutably proved that an open source process couldn’t find clever subversions, no matter how many people of whatever competence looked at the source code: http://www.acm.org/classics/sep95. A lot of people thought that I didn’t know what I was talking about when I said there was a way to create a back door that could not possibly be found by source code inspection. What needs to be understood is that the back door that Ken Thompson describes is not in the operating system source code. No amount of examination of the operating system source code can ever find it. The back door is in the binary code. Some people think that you can get rid of this back door by recompiling the operating system from source code. You can’t. The back door is in the compiler binary that is used to build the operating system. The corrupted compiler binary re-corrupts the operating system by adding the back door in every time it is compiled. Some people think that you can get rid of this back door by recompiling the compiler from source code. You can’t. The back door in the compiler binary re-installs itself in every new compiler binary every time the compiler is rebuilt. Some people think that you can find the corruption in the compiler source code. You can’t. It is not there. It is only in the compiler binary, not in the compiler source code. It propagates itself into all subsequent compiler binaries that it builds. Some people say that I have confused Linux with UNIX, so any example of a back door in UNIX has nothing to do with Linux. If anyone spends the time to study this back door, they will find that it is equally easy to add a similar one to Linux. In fact, every open source program has this vulnerability. If a compiler implementer knows a program’s source code, the compiler can recognize any unique sequence of source code from the program and intentionally mis-compile it to install a back door in the binary code that does not exist in the source code. In Linux, the mis-compilation can be done by a virus that infects the GNU compiler. The virus changes the GNU compiler functionality to recognize a particular sequence of source code in Linux and insert additional binary code (which implements the back door) into the object code output by the compiler. When this object code is linked into Linux, the back door is installed. The binary virus propagates itself into future GNU compilers by also recognizing the GNU compiler’s source code and mis-compiling the GNU compiler’s source code by inserting itself into the new GNU compiler binary code. Anyone who can figure out how to implement this back door by themselves deserves a medal. But Ken Thompson describes the entire process one step at a time in his original paper at http://www.acm.org/classics/sep95. If you don’t believe that Ken Thompson is right, show his paper to the smartest compiler/operating system person that you know. He or she will confirm what Ken Thompson said: “No amount of source-level verification or scrutiny will protect you from using untrusted code.” The open source development process is not capable of detecting this form of subversion. A talented programmer can implement and install this undetectable back door in a standard GNU compiler distribution in a matter of hours. There are hundreds of people in the various open source organizations with the talent and access to GNU compiler distributions necessary to accomplish this. Some people believe that they can solve this problem by recompiling everything with an uncorrupted compiler. But how can you know if a compiler is uncorrupted? Someone may have introduced a back door into one of the earliest GNU compilers, just as Ken Thompson introduced a back door into one of the very first UNIX C compilers. Ken Thompson shows how to implement this back door with a compiler, but someone could do the same thing with any binary code that is required to build Linux. For example, someone could also corrupt the assembler or linker. Someone could also hide a binary virus in a library that is used to build the compiler, assembler, linker, or the kernel. Once you understand this kind of vulnerability, you quickly realize that it is very easy to think of many ways to silently subvert Linux that could never be found by any method of source code examination. So how do you know that your Linux has not been infected with this kind of binary virus? You must verify that there is no “extra” binary code in the millions of bytes of Linux privileged-mode code and setuid root programs that is not represented in the corresponding millions of lines source code. Of course, this verification will have to be done each and every time Linux is built or patched, to make sure no one snuck in a virus when no one was looking. This is not feasible. A few people who understood Ken Thompson’s paper wrote to me saying that every operating system has this problem, so my indictment of Linux security on this point is meaningless. They ask: “couldn’t someone at Green Hills Software install a binary virus in the baseline Green Hills Software compiler distribution and corrupt Green Hills Software’s INTEGRITY operating system?” No, the FAA DO-178B Level A certification process systematically checks every byte of object code of our INTEGRITY-178B operating system to ensure that if malicious code is introduced at any point throughout the tool chain (compiler, assembler, linker, run-time libraries, etc.) it will be detected and removed. Since INTEGRITY has only a few thousand lines of privileged-mode code, not the millions of lines that burden Linux, this means of preventing viruses is feasible for INTEGRITY, but not for Linux. Conclusion Now that foreign intelligence services and the terrorists know that we plan to trust Linux to run some of our most advanced defense systems, we must expect them to deploy spies who will easily infiltrate the Linux project. It will be easy for them to insert back doors and other malicious code into Linux that the open source process can’t find. Just one success in infiltrating a few lines of privileged-mode code into Linux could enable our enemies to disable, spy on, or commandeer some of our most advanced defense systems at the outbreak of war. On the other hand, it is very hard to infiltrate our small tightly-knit INTEGRITY real-time operating system development and support team. And our design and development processes, comprehensive documentation and testing, commitment to security and reliability above everything else, and third party audits and certifications by the FAA, NSA, and customers would detect an attempt by any development or support team member to insert a back door or any malicious code into INTEGRITY. Our INTEGRITY real-time operating system solves the critical reliability and security problems that make Linux a national security risk when used in defense systems. Now that I have shown that Linux in its current form is not secure enough for defense systems, next week I will show in Part III of my white paper series, “Linux Security: Unfit for Retrofit”, that it is not possible to fix Linux to make it secure enough for defense systems. I will also include an analysis of the NSA’s Security Enhanced Linux, or SELinux. |
 |
|
 |
RSS