Security and open source software: An analysis.

COMMENTARY-- Perhaps due to the unnecessarily high volume of publicity surrounding the positive security aspects of Linux and open source software and the enviable security track-record of kindred platforms like OpenBSD, it's coming as no surprise that a number of commentators are pointing out that Linux, just like every other platform, does indeed have security issues. Members of the open source community know this and have always known this; it was never in dispute. There are no Linux professionals who deem Linux to be immune from security threats.

Almost all Linux professionals are also Unix professionals, who, as a community, have been dealing with online security threats surrounding Unix for over 20 years. Remember, the Unix (and subsequently the Linux community) is the group that (literally) created and constituted and still forms the backbone of the Internet. The modern Internet began with the implementation of the TCP/IP protocol stack in Berkeley Unix 23 years ago. This community has been dealing with the complex interconnection of powerful systems on public networks since then. They were dealing with serious security threats, like the Internet (i.e Morris) Worm, before Windows NT even existed. They know network and host security and were the first to implement almost all the core protocols, network infrastructure software stacks, firewall, intrusion detection and other perimeter-defence and security analysis technologies that our industry uses daily. None would ever claim that the design and implementation of the Unix/Linux platform has no threats and to imply that this group holds this viewpoint is both absurd and misguided, to say the least.

Yet, the pundits who have raised their voice in recent months, including people who should know much better, like Chris Wysopal (of @Stake) and Paul Thurrott (of WinInformant) are questioning the generally accepted notion amongst IT professionals that Linux is more inherently secure than Microsoft's professional operating system platforms. For instance, Thurrott has stated:

"Let's examine a more recent example. In Friday's WinInfo Daily UPDATE newsletter, I mentioned a set of statistics from BugTraq, a reputable security- information provider, that shows how various OSs compare security-wise. The statistics show a surprising trend: When you aggregate all the Linux distributions, Linux, not Windows, has had the most security vulnerabilities, year after year."

There has been much discussion about the security vulnerability rates between Windows and Linux. Firstly, let me state that this focus on pure numbers and graph plots of vulnerabilities is pointless. There is no such thing as a truly secure operating system, there is only the ongoing process of keeping a host or network secure. One can never achieve a state of 'security Nirvana'. Think of it as a treadmill, constantly moving you (as the administrator of a system) back-wards. You have to 'walk' forward just to keep still. If you don't move forward with security patches, security tools and revamped system security processes, you'll be flung off the end of the treadmill from sheer inactivit. Oh, and by the way, the crackers have access to the treadmill's speed control knob, and keep pushing up the speed.

As an ancillary, all operating systems can be made 'secure', by whatever reckoning you attribute to this term. It all boils down to time, effort, money and will. Some operating systems seem to need more of these, some less. They all need some. It all boils down to what is security worth to you and your network.

The Open Source community has made much of the 'with enough eyeballs, all bugs are shallow' concept; that by using enough technical users, some or many security concerns can be overcome. I am a believer of this epithet, however, think about it for a second: 'with enough eyeballs, all bugs are shallow'. What this is saying, in effect, that when a bug becomes an issue, many people have the source code, and it can be quickly resolved. To paraphrase, when we get hit by a bug, we can swat it quickly and without waiting for a vendor. I believe that for widely-used free software projects, this too is true. There is one important proviso to this train-of-thought to keep in mind though, which makes exploitable security bugs a slightly different beastie to general-purpose bugs.

A general bug which hits an individual user or site, gets reported to the maintainers and gets resolved, generally doesn't have the same possible impact as a security bug, particularly a remotely exploitable one. A general bug (if catastrophic enough) can cause loss of data or system un-availability, but a security bug can cause your system to become 'owned' by a cracker, for you to lose data through deletion, have data sent to your competitors or leaked to the trade press, have invalid data inserted into your records, have customer credit cards stolen etc.

Further, vulnerabilities become known and spread on back-room IRC channels like wildfire. While a general bug may be encountered by you and a few others over the course of longish period of time; a remotely exploitable vulnerability has the attribute of attracting penetrative tests against tens of thousands of hosts in a matter of hours of discovery, causing far more damage and strife than a general bug.

Finally, catastrophic general bugs which affect many are few and farbetween (unless you include various Microsoft Service Packs), as mostpeople do not tread the bleeding edge of operating system releases, andwidely used systems and sub-system software generally doesn't harbour catastrophic general bugs for long. Security vulnerabilities, however, can arise in code or a subsystem which is widespread and very well entrenched, further accentuating the possible spread of damage.

In summary, the dues-ex-machina of 'with enough eyeballs, all bugs are shallow' holds, but possibly only after substantial damage has been done to many hosts on many networks. At least we know that if it's important for users of the said sub-system, the security problem will be resolved at the source-level, a surety we don't have with commercial closed-source or orphaned software.

Perhaps the core advantage here that Open Source software can provide is that widely-used code sub-systems which are shown to have security vulnerabilities, are fixed and re-issued quickly. Microsoft and many closed-source vendors have historically had a woeful history of tardy or non-existent vulnerability-resolution of their code. This has (thankfully changed) in the past year or two, more than likely due to the torrents of negative publicity given to these vendors on each security threat announcement. One can almost be excused for thinking that if it weren't for the negative press pressure, they might not be lifting their game at all.

How do we, as an industry, help improve the security of our software technology? While there are various industry correspondents who have eloquently outlined the steps that are necessary in the design and development of software which has a tendency to be more secure, a good, simple approach to software security can be quickly given:

• Design the software with multiple layers of trust.
• Design it so that no part immediately trusts the other part.
• Make it small.
• Make it modular.
• Use languages which can either avoid buffer-overflow problems, or perhaps can be put through automated testing and parsing of the source for signatures of these problems.
• Allocate enough resources to security audits and reviews of the code from a security perspective.
• Design simple checklists for your coders (junior and senior) which point out the 10 most likely security failings for the platform/language/development paradigm you are developing your project under.

It's easy stuff. Avoid complex security jargon, or excessive overtones of ideas or terminology which overshadows the many simple automaton-like things that can be done to improve information system security; it just scares developers away.

Now, onto a rebuttal of some of the points raised by Paul Thurrott, and a hint to others who have tried to run the vulnerability numbers through the analysis wringer. There is one crucial concept which seems to have gone missing from all the mainstream trade-press discussion to date, which I will present here.

Thurrott claims that through sheer raw-number of vulnerabilities calculated by BugTraq, Linux is less secure than Windows. Now, keeping in mind all we have said above about how the security of a system or network is linked to the process the system administrator uses and the security policies defined by the organisation running the systems, rather than it being a question of 'which OS is more secure', let us proceed. Thurrott states:

If you break down those numbers by Linux distribution (despite the fact that Windows 2000 and Windows NT are lumped together), Win2K/NT had 42 vulnerabilities in 2001 (data is through August only), and the leading Linux distribution, Red Hat, had 54. In 2000, Win2K/NT had 97 and Red Hat Linux had 95.

These numbers may in toto, be accurate. I don't dispute them. They appear to be slightly in Windows' favour. However, as mentioned above, what has not been discussed widely, reviewed and broadly digested (to my amazement), is that none of these industry observers has taken into account the substantial disparity in system functionality which is shipped on each platform, and which forms the software basis from which vulnerabilities arise. Let me elaborate.

I reviewed the broadly categorised functionality packages which ship with Windows 2000 Server, presuming it be a reasonable superset of a generally available Microsoft platform, bundling most of the sub-systems which are needed by a user or business. The list of features is quite reasonable, and is shown by Microsoft here: (http://www.microsoft.com/catalog/display.asp site=656&subid=22&pg=2) I count approximately 120 sub-systems in Windows 2000 Server. These include such this as Internet Information Services web server, Active Server Pages (ASP) Programming Environment, XML Parser etc. Now, to compare, I quickly researched a list of sub-systems which are shipped with a modern Linux distro. SuSe seemed to have such a list readily available for their 7.3 Professional release, so I used their's. You too can view this list here: (http://www.suse.de/en/products/suse_linux/i386/packages_professional/index.html)

I'm sure the Red Hat, Debian et al. lists are similar. The weigh-in? Just under 2600 packages. This means that, based on just this simple analysis, a modern Linux distribution ships with approximately _20 times_ more functionality in the box, than Microsoft ships with Windows 2000 Server. Note, this is just a count of approximate functionality. With the hundreds of millions of lines of source code shipping for these platforms, a much deeper analysis would be un-tenable. When one does a quick and dirty calculation therefore, Linux on a per-atomic-functionality basis, can be viewed as being 20 times more secure than Windows, i.e it ships with 20 times as much 'materiel', but releases approximately the same number of security alerts as Windows.

If this analysis proves anything, it's that this simple-minded churning of numbers is pointless. This is merely rhetoric flying back and forth. What our industry needs is the elevation of security to the front and centre of design and coding practices. Any organisation, community or vendor which credibly attempts to achieve this, is worth supporting. What should not, however, be condoned, are instances where an organisation or vendor touts this approach primarily primarily as a cynical marketing exercise, without procuring end-results.

Con Zymaris is the CEO of Cybersource, a long-standing Australian IT & Internet Professional Services company.