This concept seems to be very difficult for people to understand, so I'll try to explain it here. Put simply, just because an application happens to be runnable on Linux, have been ported to Linux but not yet run on it, run via a scripting language that happens to also run on Linux, or any other possibility you can think of that doesn't directly involve the kernel, technically it is not part of Linux. Therefore, any bug or security flaw should not be attributed to Linux, but to the application. Now I'm going to bang off a couple rebuttals for common arguments to the above fact.
That's right. This is a fact. But even if I went a step further, and was willing to include the gnu tools in what is dubbed Linux, one would find that security flaws in Linux are still very rare indeed.
Yes they are. But this actually hurts your argument. Microsoft considers those applications part of Windows. They said so under oath many times during their anti-trust trial. They make it nearly impossible to uninstall them. You certainly can't choose not to install them in the first place. Therefore, they are considered part of Windows.
Now how about two case studies? First, the recent Apache security hole. I've seen many call this a hole in Linux. But the fact is Apache runs on tons of operating systems, including Windows! Clearly this is a flaw in Apache, not Linux. It is not forced as part of the install by any distributions I know of. And if it was, I would simply not use that distro. I like choice, and you get it with most distros.
Next, the OpenSSH bug. OpenSSH is written by the author of OpenBSD. It was ported to Linux and many other operating systems. A flaw in OpenSSH is not one in Linux. It is that simple.
I also commonly see people use Security Focus's statistics list as a comparison of OS security. This started when some "journalist" who's name escapes me used this list to claim Windows was more secure than Linux. It then became a FUDmiester's favorite. It was used incorrectly so often that Security Focus put up a warning describing why doing so was totally inaccurate.
Below are their two key points, quoted directly:
There is a distinct difference in the way that vulnerabilities are counted for Microsoft Windows and other operating systems. For instance, applications for Linux and BSD are often grouped in as subcomponents with the operating systems that they are shipped with. For Windows, applications and subcomponents such as Explorer often have their own packages that are considered vulnerable or not vulnerable outside of Windows and therefore may not be included in the count. This may skew numbers. This is a simple raw count of the vulnerabilities in our database that are associated directly with an operating system. The factors mentioned above were not taken into consideration when generating these graphs.
Basically, these numbers are comparing apples to elephants. A Linux distro comes with TONS of software, where Windows comes with very little. The default server install of Linux would have considerably fewer security holes when compared to Windows.
Comparing apples to apples would mean comparing Apache to IIS, for example. A check of ALL the security flaws found in the Apache 1.3.x series (released in June 1998 and still used today, including on this webserver) shows sixteen flaws. Of that sixteen, only 2 involve running arbitrary code thereby exposing the possibility of cracking the box itself. The rest are DOS attacks and less serious flaws. So that's four bugs a year, .5 a year being major. I found a list of Apache's security flaws at Apache Week. Finding a list of all the security flaws in IIS is somewhat more difficult. After manually sifting through CVE to eliminate duplicates or flaws in applications other than IIS, I found eighteen vulnerabilities which could allow taking over the box, and the best estimate I could get was over fifty minor security bugs in the same span of time. Here's the kicker: this was only for IIS 5.0. So in about three years, IIS 5.0 sees 6 major vulnerabilities a year to Apache's .5. And I won't even get into how long it takes Microsoft to release a fix for flaws.
My day job is at a Microsoft shop. I work all day with IIS and Visual Basic. We fight all sorts of strange bugs and weirdnesses in Microsoft's software and without the source, we have no hope of finding the cause. Our server admin team is top notch, and knows their stuff. We've always kept up to date with patches, and due to this, as far as I know, we've never had a public box hacked. We did have a few boxes behind the firewall get infected by Nimbda.
The boxes in our server farm have to be rebooted constantly. I know, as I get emails when they are rebooted. IIS hung, rebooting. Such and such service hung, rebooting. Server is sluggish, rebooting. MS SQL Server jobs aren't running, rebooting.
I've never had to reboot a production Linux server for any reason other than a kernel update. Rocket, the box this and many other high profile sites are served from, has been up now for 90 days. Other than hardware problems, a Linux box is rock solid, and runs all by itself. That just doesn't happen with NT boxen. I know. Remember, I get those pesky emails all day.
Did you like this article? Do you want to encourage us to continue writing cool stuff like this? Please subscribe to LinuxMuse.
I used Jedit to write this, running on a Gentoo Linux 1.3a workstation built with GCC 3.1 and all sorts of tweaks and changes. I'm just the comedy relief here. Even gbot agrees!
<greg> gbot, greg? <gbot> you are the Head Village Idiot and one of the knights who say "BAH"
Linux is a registered trademark of Linus Torvalds. Linux systems contain a large component of GNU Software, see www.gnu.org for details.
All other brand and product names are or may be trademarks of, and are used to identify the products and services of their respective owners.
All other content Copyright (C) 2002 Linux Muse. Powered by MagaMuse v0.3.5, (C) 2002 Greg Lincoln.