Building applications and operating systems out of open source components is definitely a good news/bad news proposition. The good news is that there are many quality components out there, which vendors can combine, do their value-add thing, and release as a capable and inexpensive product. The bad news is that if components have security vulnerabilities, those vulnerabilities show up in every product that uses them.
Unfortunately, these components have their share of security issues. If you read security advisories every morning with your Cap'n Crunch, you've probably noticed a pattern to how they spread. First, there's an advisory from the folks responsible for the component. Then, a few hours, days, weeks or months later, come the advisories from all the software vendors who include the problematic component in their products. The vulnerability ripples through applications and operating systems, like ripples across the surface of a pond.
Naturally, some vendors are faster than others in making fixes available for their flawed components. Which are quicker in supplying fixes? Which seem to be taking siestas instead? How hard are these ripple vulnerabilities to fix? Should you consider changing vendors for faster service? And what are the long-term implications of the ripple problem? By examining the Secunia advisory database for flaws that were serious, remotely exploitable and dangerous, some answers were made clear.
Ignoring component problems that only affected
One positive aspect of the ripple problem is that some vendors announce fixes for vulnerabilities as soon as the component vulnerability is disclosed. It's not unusual to find fixes the same day. However, some problems are tougher. A Point-to-Point Tunneling Protocol (PPTPd) buffer overflow flaw in April 2003 took 18 days for the first fix announcement (Gentoo) and 75 days for the last (Sun). An OpenSSH user identification vulnerability in May 2003 was fixed by Gentoo the same day, but took an average of 74 days for other vendors to announce fixes. One Bind problem took a vendor 321 days to fix.
For the 22 vulnerabilities we examined, we calculated the average time it took each vendor to fix problems (after throwing out the worst performance for each vendor). Some vendors are astonishingly fast. EnGarde, OpenBSD, Slackware and Trustix all posted fixes in a day or less. FreeBSD, Gentoo, Immunix, Mandrake, OpenPKG, Red Hat, Smoothwall and SuSE all took a week or less. On the other end of the range, SCO and Sun both averaged more than three weeks. Other vendors, including Apple, Conectiva, Debian, Hewlett-Packard, NetBSD and SGI, fell in the middle.
Of course, it's not wise to jump to conclusions from this kind of data. For example, some vendors might prefer to make fixes available on a certain schedule, or as part of larger deliveries, rather than every time a component sneezes.
Another statistic is the number of fixes by a vendor. Conectiva, Debian, Gentoo, Mandrake and SuSE all had 14 or more fixes for the 22 vulnerabilities we examined, while Apple, Cisco, EnGarde, Immunix, SCO, Smoothwall and Trustix all had four or fewer.
The ripple effect is going to get worse for vendors that rely on open source components -- and the users who rely on those vendors -- because malicious hackers are starting to make exploits available almost immediately after each vulnerability is announced. Since open source vendors can't delay announcements until all those using their products have fixes ready, this means that malicious hackers are always going to have the jump on software vendors. In many cases, hackers don't need to hurry. The Secunia database shows 29 instances where vendors took more than 30 days to fix a known problem, and 12 where some vendors took more than 60 days.
Some users might want to consider changing vendors to get fixes more rapidly. Others might be more interested in vendors that didn't make any of the lists -- because they had no published vulnerabilities. However, as the investment ads always warn us, past results are not indications of future performance. All we can do is recognize that even open-source-based software is vulnerable to security problems, and tread water so that the ripples don't swamp us.