Open Source Doesn’t Makes Linux More Secure than Windows
There is a widespread misconception that open source is inherently more secure than proprietary software. To investigate this urban legend, it is only necessary to peruse the U.S. Government’s database of computer security vulnerabilities maintained by the National Institute of Standards and Technology (http://icat.nist.gov). As of April 15, 2004, there have been many more High Severity (the highest severity) vulnerabilities found in the Linux operating system than in Microsoft Windows. This count removes duplicate reports of the same vulnerability against multiple versions of Linux or Windows. In fact, in every year for the last ten years the number of vulnerabilities reported against Linux exceeds Windows! And this is despite the fact that:
| (i) |
|
the total number of lines of source code in Windows is far higher than the number of lines of source code in Linux;
|
| (ii) |
|
there are far more Windows systems than Linux systems, meaning that hackers can cause more widespread damage by attacking Windows;
|
| (iii) |
|
more interesting, more valuable, and more sensitive information can be stolen or disrupted on Windows systems. |
It seems that the only reason that hackers would prefer to attack Linux over Windows is because Linux is easier to attack.
The Common Criteria Says Linux Security Problems Can’t be Fixed
Many people are under the misconception that since Linux has been evaluated under the Common Criteria for IT Security Evaluation (ISO Standard 15408) that Linux must be secure. But here are the facts: Linux has been certified to EAL 2 under the Common Criteria. By comparison, Windows has been certified to EAL 4 (higher is better)! As discussed in Part I of this series of white papers, EAL 7 certification should be required for operating systems that run critical defense systems.
The Common Criteria standard states: “EAL 4 is the highest level at which it is likely to be economically feasible to retrofit an existing product line.” This means that if a product was not originally designed for security, it will probably never exceed EAL 4. Security was not a focus of the original design of Linux, Unix, or Windows. They were all originally single user systems with no network access and therefore no need for security. Since Linux, UNIX, and Windows were not originally designed for security, they are unlikely to ever exceed Common Criteria EAL 4. They all have millions of lines of insecure code that can’t be fixed.
Our INTEGRITY real-time operating system was designed from day one to meet the highest levels of software security. The only way to come close to the level of security that INTEGRITY has already attained is to start over from scratch. But if such an effort were to result in a secure operating system, it would not be Linux, it would be something else.
It is not possible for the open source process to fix Linux so that it provides the level of security that defense systems require, and that INTEGRITY has already achieved.
NSA Security Enhanced Linux (SELinux) is not the Solution
There is a widespread misconception that the NSA is going to solve Linux’s security problems with its Security Enhanced Linux (SELinux). But to find the truth behind this urban legend, just read the frequently asked questions page from the NSA website for SELinux, http://www.nsa.gov/selinux/info/faq.cfm. Here are a few excerpts (emphasis added):
- “Security-enhanced Linux is only a research prototype that is intended to demonstrate mandatory controls in a modern operating system like Linux and thus is very unlikely to meet any interesting definition of secure system.”
- “there has been no work focused on increasing the assurance of Linux”
- “we did not look for or find any vulnerabilities in the course of our work”
The NSA has not fixed, or even seriously tried to fix, the security problems (documented in this series of white papers) that make Linux unsafe for defense systems.
Secrecy is an Important Component of Security
Many of the objections to my assertion that Linux is not suitable for defense systems are based on the truly bizarre misconception that secrecy reduces security.
If secrecy isn’t important to security, then why does Linus Torvalds keep the means of accessing the core Linux development tree a secret from all but a few people? Because if he published the details of his defenses, some jerk would break in and screw up the Linux development effort. Doesn’t the military have more important things to protect than the Linux development tree? Don’t they have people who want to attack them as well? Maybe they need a little secrecy, too.
The operating system of a defense system controls all of its functions, communications, and security. If the operating system is compromised, the enemy can spy on, disable, or commandeer the entire system. No one would consider publishing the wiring diagrams for our military base security systems so that lots of people could look at them and help us find vulnerabilities. If we allow our enemies to study our security systems at their leisure, they won’t tell us when they find a vulnerability, they will exploit it for their maximum advantage. Publishing the source code for the operating systems used in our most critical defense systems is analogous to publishing the wiring diagrams for our military base security systems. Our enemies will be able to study the vulnerabilities of the software controlling our defense systems at their leisure. Unless an operating system has no vulnerabilities, publishing its source code is sure to reduce security.
Many people argue that open source programs are inherently more secure than “proprietary” programs because publishing the source code for the program enables many people to look at the source code and find any vulnerabilities in it. This is based on the misconception that looking at the source code is an effective means of finding vulnerabilities, which it is not (this is addressed in Part II of this series of white papers). Thousands of vulnerabilities escape source level scrutiny of Linux every year. Far more bugs are found by debugging than by source level scrutiny. Since only a small percentage of all vulnerabilities are found by source level scrutiny (compared to conventional debugging), the positive effect of opening the source code to public inspection is only a small percentage reduction in the number of vulnerabilities that are found (and remain unfound) each year.
On the other hand, opening the source code to foreign intelligence agents and terrorists enables them to find many more vulnerabilities than if the source code were to be kept secret. Since publishing the source code reduces the vulnerabilities by only a small percentage, but it increases the number of vulnerabilities that our enemies can find by many-fold, publishing the source code results in our enemies finding many more vulnerabilities. Open source definitely reduces the security of defense systems.
Secrecy improves security. When a poor security system, such as Linux, is made public, attackers can carefully study its defenses looking for vulnerabilities, so they have no difficulty defeating it. When a poor security system, such as Windows, is kept secret, attackers have greater difficulty finding vulnerabilities so it is harder to defeat. But within days after a large chunk of secret Windows source code was stolen and made public in early 2004, hackers had released viruses and worms based on vulnerabilities they found in the stolen source code.
Secrecy also improves an otherwise good security system for the same reasons. Any vulnerability is much easier to find if the security system details are made public. Keeping the security system secret can make a good security system highly effective.
It is a fundamental tenet of the open source movement that Linux source code will always be published for everyone to see. It will always be easy for our enemies to study Linux at their leisure in order to find ways to exploit the many vulnerabilities that exist in every version of Linux. This security problem is inherent in the Linux open source philosophy, it can’t be “fixed.” The open source process by which Linux has been developed should rule it out of defense systems.
Disclosing Operating System Source Code Discloses Secret Hardware Designs
The operating system source code provides a blueprint for the software security system: demonstrating how to program, control, and disable all of the secret devices in a defense system. From the source code, it is often possible to ascertain the performance, timing, capabilities, and much of the design of the secret devices and encryption chips in the system.
Defense contractors would not publish the design for circuit boards, chips, and algorithms in defense systems. But that can be the effect of publishing operating system source code. Open source will certainly reduce the security of defense systems.
Security through Obscurity
“Security through obscurity” is a derisive slogan invented by the open source community to describe the practice of hiding the source code of sloppy software to prevent attackers from finding the vulnerabilities. Many open source advocates claim that anyone who doesn’t publish their source code does so only to hide the terrible quality of their code, but this is just mindless prejudice. Commercial vendors keep their source code secret to preserve the proprietary advantages that permit them to make a profit.
Green Hills Software doesn’t practice “security through obscurity.” We supply our INTEGRITY operating system source code to our customers. The Federal Aviation Administration has found our products compliant with their highest level of software reliability. Linux wouldn’t last 5 seconds in an FAA audit.
Nearly all bugs and subversions escape visual inspection for a very long time, but formal review of every line of source code with verification tests that demonstrate that it implements the detailed high level and low level specifications assure a very high degree of reliability and security.
Many people have tried to tar Green Hills Software with the security problems of other “proprietary” software. “Proprietary” software can be hopelessly insecure, absolutely secure, or anywhere in between. The more appropriate security distinction is between FAA DO-178B Level A safety-certified real-time operating systems, such as INTEGRITY, and general purpose desktop operating systems, such as Linux and Windows. From the perspective of safety-certified operating systems, it is the desktop operating systems that are virtually indistinguishable: hundreds of vulnerabilities found (and created) every year, tens of thousands of bugs found (and created) every year, no consistent product design, and woefully poor testing.
Defense Linux
Some people have argued that defense contractors could avoid the largest security vulnerabilities of Linux (i.e. that much of Linux has been developed offshore by unknown personnel and that the source code must be made public exposing its capabilities and vulnerabilities to attackers), by taking a copy of Linux, thoroughly evaluating it for subversions, securing its source code, and proceeding with development with security checked personnel.
Green Hills Software’s extensive experience with safety certifications by the Federal Aviation Administration (which is just a subset of a full security certification) is that it costs over $1,000 per source code line that runs in privileged mode. A full security certification must be performed by someone who is a formal methods mathematician, a software engineer, and an experienced evaluator. That is a rare and expensive breed of individual. A thorough evaluation of Linux for subversions would cost billions of dollars. So much for the argument that Linux is low cost.
And it gets worse! Once this version (let’s call it “Defense Linux”) is cut off from the main Linux development effort, it would lose all of the benefits and character of open source development. The Defense Linux project could no longer download code from other open source efforts or bring down new kernels without going through that multi-billion dollar expense again. Defense Linux would not benefit from any further cooperative development from the open source community. It would be a proprietary system!
Open source programmers want to build new software to help people. No self respecting first-rate open source programmer would take a job building “proprietary” software for the military. Defense Linux would be a hugely expensive boondoggle that would have to be staffed with an army of second- and third-rate programmers who did not write the software that they work on. Is that really good for national defense?
If defense contractors want to develop their own operating system for defense systems why would they want to start with Linux instead of an operating system that is already used in defense systems? Linux is huge, it is not real-time, it is not well documented, and it has huge security vulnerabilities. Defense contractors gain nothing but trouble by starting with Linux. They should start with a small, fast, royalty-free, proven reliable, well documented, secure real-time operating system developed under tight controls that has been deployed in hundreds of military systems already: our INTEGRITY real-time operating system.
A further impediment to Defense Linux is created by the GNU General Public License (GPL) under which Linux is licensed. Some people have pointed out that you don’t need to release your secret source code modifications if you don’t distribute Linux. This does not work in the defense community. The government doesn’t develop weapons systems. Private defense contractors develop weapons systems. If a defense contractor were to pick up a copy of Defense Linux (or any other Linux) and incorporate it into a weapons system and deliver that weapons system to the government, the defense contractor would be a distributor of Linux under the GPL. The defense contractor would then be legally required by the GPL to make the modified Defense Linux source code available to all third parties (including foreign intelligence services and terrorists). GPL Section 2b (emphasis added):
“You must cause any work that you distribute or publish, that in whole or in part contains or is derived from [Linux] or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.”
The government could simply abrogate the GPL or immunize every defense contractor from liability for using Linux in violation of the GPL, but that would not be a good precedent for the GPL or the open source movement.
A Defense Linux project would be extremely expensive for the government, it would reduce national security, and it would be bad for the Linux community.
Linux has been Selected for Defense Systems without Adequate Security Analysis
Many people claim that I an alarmist, because as one critic put it, “code put into major military systems undergoes extensive analysis, review, vulnerability assessment and planning.” This is true for newly developed code, but the cost of evaluating the millions of lines of Linux source code at the level to which newly developed software is evaluated would put the cost of Linux out of the reach of even the U.S. military! Linux has been selected for use in defense systems with insufficient analysis, review, vulnerability assessment, and planning.
The operating system is the most critical piece of software in any defense system, so Linux must be subject to the same (or higher) standards as every other piece of software being used in the system. If a defense program requires that all of the implementers and testers be U.S. citizens, it should require that any operating system code that is imported is developed and tested only by U.S. citizens. If a defense program requires a certain process for development, code review, analysis, or vulnerability assessment, then any imported operating system code must undergo development, code review, analysis, and vulnerability assessment at the same (or a higher) level. If a defense program requires that a certain level of documentation, testing, or product requirements specification, then any imported operating system code must meet the same (or a higher) level.
The operating system controls all of a defense system’s functionality, communications, and security. If the operating system does not meet the same (or higher) security and reliability requirements than the rest of the software, all of the efforts to meet those security and reliability requirements for the rest of the software are meaningless.
If Linux was subjected to the same security, reliability, and documentation requirements as the other software in critical defense systems, it would never be allowed in any critical defense system. What defense contractors would contract out national security software development and support to Russia and China (as do some Linux vendors)?
Every principle of security is being violated to enable Linux to spread through our defense systems. This must not be allowed to continue.
Next week in Part IV of this series of white papers, “Linux in Defense: Free Software is Just Too Expensive,” I will show that Linux is not the lowest cost operating system for defense systems nor does it offer the long term support model that defense systems need.
|
