Chad Perrin: SOB

4 April 2007

Security Analysis: Symantec ISTR XI (Vulnerability Trends Highlights)

Filed under: Security — apotheon @ 11:15

In yesterday’s analysis I presented some coverage of the “Attack Trends Highlights” of Symantec’s Internet Security Threat Report, volume XI. Today, I’ll present an analysis of the Vulnerability Trends Highlights from the Executive Summary Highlights section of Symantec’s report. I will be providing analysis of further content of the ISTR XI on a (hopefully) daily basis, until I decide I’m finished.

Interesting Numbers:

Symantec’s Internet Security Thread Report volume XI provides a number of interesting statistics in its “Vulnerability Trends Highlights”. The following is commentary on some of the more suggestive statistics.

  • 2,526 new vulnerabilities were documented by Symantec in the six-month period from 01 July through 31 December, 2006. This represents a 12% increase over the number documented by Symantec in the previous six months. This sort of metric is a lot more likely to be directly useful than many of the others Symantec counts, at least within a trivial margin of error, because of the nature of Symantec’s line of business. Of course, there’s nothing particularly surprising about a twelve percent increase in vulnerability detection: as detection techniques improve and the quantity of available software increases, the number of discovered vulnerabilities should increase as well.
  • 4% of discovered vulnerabilities were classified as high severity, according to Symantec. 69% were medium severity, and 27% low severity. Severity classification is based on a combination of factors, including ease of exploit, the level of access to your system or amount of damage it can allow an exploit to do directly, whether the vulnerability can be exploited remotely, and potential for harm to other network-connected systems via a single exploit, among other metrics. The “industry standard” for rating severity of vulnerabilities is FIRST‘s CVSS. Unfortunately, CVSS (and imitators as well) uses metrics that are highly arbitrary and not well suited to determining an actual useful measure of your systems’ security exposure. It’s somewhat akin to the largely useless color-code system the government now uses to rate current danger of terrorist attacks. To determine your actual exposure due to a specific vulnerability, you generally need to read as much as you can find about the vulnerability and make an informed decision for yourself — or hire someone to do so for you, assuming that person will employ all due rigor to the task and has the appropriate skills.
  • Sixty-six percent of all disclosed vulnerabilities in this period affected Web applications, according to Symantec. This, too, is not surprising, especially as Web applications become increasingly prevalent and important. It’s worth mentioning, however, if only so that readers who did not previously realize this was a likely statistic have an opportunity to consider it. This is important not only for people involved in Web application development and deployment, but also end-users of Web applications and people who might be inclined to forget about Web applications when considering vulnerability statistics.
  • Sun Solaris suffered the longest patch times of all OSes covered by the study, according to Symantec. This is important mostly because of the fact that Sun Microsystems directly disputes Symantec’s numbers. Symantec claims 63 vulnerabilities for Solaris with an average 122 day response time on patches. Sun reported 54 total “Security Sun Alerts” for the same period, only 36 of which applied to Sun Solaris. Of those, Sun’s statistics show that the majority were addressed in about five days, but averages were skewed upward slightly be “a small minority of 3rd party applications” or third party code included with Solaris as it was shipped.
  • 68% of disclosed vulnerabilities were not confirmed by vendors, according to Symantec. It’s possible this may account for disparities such as that between Sun’s numbers and Symantec’s.
  • Microsoft Internet Explorer suffered 54 documented vulnerabilities, about a 25% lead over the next highest number, according to Symantec. The second place was the Mozilla line of browsers — not a single browser, but all major Mozilla browsers.
  • Mozilla browsers saw an average patch response time of two days, according to Symantec, the shortest of any browser vendor/distributor studied.
  • 12 zero day exploits were documented by Symantec during this period. Zero day exploits (or “zero-day vulnerabilities” in Symantec’s phrasing) are exploits for vulnerabilities that exist at least concurrent with, if not prior to, disclosure of the vulnerability. In general, zero day exploits are indicators that vulnerabilities were discovered because malicious security crackers were employing them to compromise affected systems. Among other implications, this tends to suggest that the vendor/maintainer is not doing an effective job of timely vulnerability detection and resolution. The rate of zero day exploits in the second half of 2006 represented a substantial increase over the previous two consecutive six month periods in which there was one zero day exploit documented by Symantec per period, and the vast majority of these applied to Microsoft software.
  • 168 vulnerabilities were documented by Symantec for Oracle database implementations. That’s more than the number of vulnerabilities documented for any other vendor’s database systems. I don’t find this particularly interesting, personally, other than the humor factor, as I don’t use, or have much interest in using, Oracle software any time soon. It might be of interest to some of you, however.

Interlude for an Apology:

I fear this may be the least useful of my analyses so far. Hopefully it will continue to be the worst, and following analyses will be better. I must apologize, both for its lackluster quality and its lateness. A number of factors contributed to this today, factors unrelated to the task but of some impact on my available time for this.

Final Notes:

  • It’s always important to be sure you’re aware of who provides what figures, and to attempt to verify them based on the methodologies of those who gathered them, when accurate comparisons are necessary.
  • Zero day exploit vulnerabilities are the most important vulnerabilities to track for determining likely exposure of your systems based on the software you use.
  • Vulnerabilities discovered and disclosed, in and of themselves, do not constitute a reliable measure of the security of a given piece of software. High discovery rates may be an indicator of malicious activity, or perhaps of extremely diligent security testing by developers. Low discovery rates, by contrast, could easily be a result of either piss-poor developer security testing, or instead the result of a vendor’s unwillingness to reveal discovered vulnerabilities and ability to suppress disclosure.


This has been the third installment in my security analysis of the Symantec Internet Security Threat Report, volume XI. This is a series of daily posts collected under the SOB category Security. You may follow this series (and further security-specific posts) via RSS using the Security Category RSS Feed.

Next, I will continue my overview of Symantec’s “Executive Summary Highlights”, with specific attention on the “Malicious Code Trends Highlights”, in brief.

the problem with GPL thinking

Filed under: Geek,Liberty,Metalog,Popular — apotheon @ 12:11

I’ve noticed an influx of new visitors to SOB this morning, leaving comments on and linking to my entry the decay of the Debian distribution. It’s kind of a strong title, as one commenter pointed out, but I think it fits as one person’s view of what’s going on. I can’t help but wonder if what looks to me to be a first year of a slow death (and oh, how I hope I’m wrong) is somehow tied in with the controversies over paid release development that arose in the Debian community last year, and the rush to get a new Stable branch release out a mere 18 months (give or take) after Sarge hit the Stable release.

Among the sources of incoming link attention is More rants, a second coffee from a weblog called Planète Béranger. Beranger himself quoted my brief mention of my discomfort with the GPL as the point he found most interesting in my SOB entry, which kinda warms the cockles of my heart — it was a throw-away statement, but in some ways I think the most important part of what I said. Predictably, between that and his comments about GPLv3, some people took issue with his position in comments posted to his own weblog entry.

The very first sentence of the very first comment, in fact, was “One thing to remember about the BSD license is that people will exploit it for their own benefit.” This is a common sentiment, and one that I find not only silly in practice but downright disgusting when one starts examining the psychological roots of that sort of comment. Here’s the bit that immediately followed that sentence:

From time to time Theo de Raadt will rant online about the large corporations who profit from his hard work (things like OpenSSH) and don’t give one penny to help fund these projects. Granted, Theo has a hard time not annoying others as he is very opinionated and does not care how others perceive him. The point is, the spirit of Absolute Freedom associated with a BSD style license can work against a project. Money aside, the idea that software can be better through a community effort might sound like nothing more than a pipe dream, but I believe that this software development model can and will work. A BSD style license creates an opportunity to fracture community development. I don’t believe in an altruistic human nature (at least not in our daily lives).


Basically, what the originator of these words (identified as “Patrick”) seems to be thinking breaks down thusly:

  1. Theo de Raadt, as the head of the OpenBSD project, is in a position to know how bad things are on the BSD side of the fence.
  2. As evidenced by Theo’s occasional rants, people are taking ideas from open source projects and not giving anything back. Shame on them.
  3. The BSD licensing model is obviously broken, based on this evidence.
  4. The GPL is the One True Community Open Source Project License.
  5. Community development falls apart at the seams with that weakling BSD license.
  6. Because humans aren’t naturally altruistic (at least in their daily lives), we should force them to behave as if they were with regard to use of open source software.

Obviously, I’m using a little bit of hyperbole to make my point. I’m sure that Patrick will/would take some issue with my paraphrase, but my response to that is simply that if that’s not how he meant it he should have been more careful with the composition of his sentences — and I suspect that, once all is said and done, he’d either recant or end up being shown to hold those opinions to some nontrivial degree anyway. Seriously. Compare my breakdown with the implications of the quote. See if you don’t agree.


Here’s my take on those points of the breakdown:

  • Theo de Raadt is one person with some very inconsistent ideas (in that sense, bearing a glancing similarity to RMS). For instance, thanks to his guidance, everything in the OpenBSD community is about openness, except the format of the official installer CD image. No, that’s proprietary, “owned” by Theo, and you have to pay for it to acquire it legally. Yes, really. Imagine that. Gee, and people wonder why OpenBSD isn’t more popular. Based on that I’m really not at all surprised to discover that Theo seems to think someone owes him a living.

  • People make use of open source software of every stripe, including GPLed software, without “giving anything back” in terms of development or money. So what? There are a whole lot of people reading these words without clicking on the ads on SOB or posting thoughtful comments, too. News flash: I don’t hate them for it. I license all my original content on this site using the CCD CopyWrite license (edit: These days, I use the Open Works License instead — which is even more permissive than the CCD CopyWrite license.), not because I want some quid pro quo or something, or because I’m too stupid to realize someone will likely use my words without giving me money or contributing beneficial modifications back to me, but because I have a real, well-reasoned belief that it’s the ethical thing to do — that the only claim I have on the product of my intellect once I convey it into the minds of others is due credit for originating the ideas. I’m not interested in cynical, scam-like ploys to “force” people to “contribute” something. Ultimately, people should decide for themselves whether what I’m creating is valuable enough to support it somehow — or whether there is some other value to be gained from “contributing” somehow. More on that in the last point of this list.

  • The BSD licensing model is not broken. It works great. There are strong communities for both FreeBSD and OpenBSD, and since (at least in part) abandoning its focus on portability the NetBSD project seems to have ceased to maintain the same strength, probably because people aren’t seeing as much point in moving to NetBSD as they used to. That’s the way it goes. Technology evolves, and the bits that don’t evolve well die out. That’s the way it should be, as opposed to the proprietary model of “The law evolves, and technologies that cannot manipulate that die out regardless of their intrinsic value.” Good. That means the system works. Freedom works — freedom for developers, distributors, and users, rather than freedom for code with the developers, distributors, and users leashed to the code (which is more the FSF/GPL model). If anything, it’s the GPL that’s broken as a community licensing model, which I’ll address in the next two points.

  • Obviously, the GPL isn’t the One True Anything to anyone but the faithful of the Church of the FSF. The zealous pushing of radical anti-corporatism (which isn’t necessarily bad — I’m of the opinion that corporate law is a direct violation of the principles of free market capitalism) actually alienates many potential users and contributors for free/libre/open source software projects, and causes legal problems for community software development and distribution efforts. In short, the GPL is broken by design, as proven by the simple fact (among many) that the GPL actually violates the FSF’s own Freedom 2 (the third freedom) of the four freedoms it claims are necessary to actual “software freedom”. Yes, really.

  • I don’t know where people get the idea that the BSD license cannot allow a community to hold together, or that it somehow opposes the community building spirit of open source projects. The FreeBSD and OpenBSD communities are stronger (in terms of the actual community integrity, though not necessarily in terms of numbers) than most Linux distribution communities by a pretty wide margin. Even better, in the BSD community, you don’t see the BSD cops running around threatening small grass-roots *BSD projects with lawsuits for obscure violations of half-baked anti-corporate clauses of the BSD license. On the other hand, you do see the GPL cops running around threatening small grass-roots Linux distribution projects with lawsuits for obscure violations of half-baked anti-corporate clauses of the GPL. The FSF, with the GPL as its weapon, is so intent on its idea of the One True Way that it’s willing to destroy people’s attempts to do good work in its tunnel-vision focus on destroying all proprietary software. I’m for eliminating proprietary, closed source software development, and for ethical as well as technical reasons, but unlike the FSF I take a “first, do no harm” position on the matter and do not in any way condone collateral damage to the “good guys”. I do not subscribe to the “to make an omelette you’ve gotta break a few eggs” notion of utilitarian, collectivist ethics that seems to guide the FSF hand. Collectively (pun not intended in this case), the FSF, the GPL, and RMS may be the biggest threat to an eventual ethical solution to the problem of software copyrights and patents, in the “good enough is the enemy of perfect” sense — it’s the de facto flagship for open source software licensing already, and as it gets more entrenched it continues to make things worse for open source development even as it provides a focal point for open source software mindshare.

  • I don’t even want people to be altruistic. Altruism, as an ethical or moral system, is broken by design (there’s that term again): it guarantees that the “bad guys” win, because the “best” people — the most altruistic — are the losers every time, by definition. I don’t want people to provide me with stuff, whatever that stuff may be, at their own expense, out of the sheer goodness of their hearts. I want them to gain value for what they give me, whether it’s helping to propagate ideas of mine with which they agree, promoting more thoughtful exchanges, or some tangible benefit. In the case of open source software, the first and primary benefit we gain from contributing is that the software we use without paying licensing fees and the like continues to improve. Good! Idiots who think they’re “getting away with something” when they copy open source software source code into proprietary, closed source software and try to sell it are actually doing themselves a disservice, cutting themselves off from effective widespread community help with further development. It’s poetic justice, and they’re welcome to it. I’d rather people give me what they feel it’s in their best interest to give than that they feel forced to give something to me by the metaphorical (and, ultimately, very real, if somewhat abstract) gun to their heads of copyright law.

So, people exploit BSD-licensed code for their own benefit. One response: Good! Would you prefer they were forced to use it for your benefit, instead? There’s a term for that — “antisocial personality disorder”.

Another response: If you really think that the world is going to come crashing down around your ears because your open source license doesn’t have a “pass on the source code OR ELSE” clause, you haven’t spent much time in the *BSD communities. The point here is to encourage cooperation and contribution, not to punish those who don’t want to cooperate and contribute. At least, that’s how I view it. This brings me to the part that disgusts me about FSF-ish attitudes toward open source software:

I find spite utterly without redeeming quality. If there’s real evil in humans, spite is a good-sized chunk of it. The impulse to somehow visit punishment upon people who use your software creations, and pass them around to others, without passing on source code is spiteful, pure and simple. That’s all punishment really is, in general. Oh, sure, you can use it as a stick to deter people from behaving in a way you don’t like, but if the end result of that is to do harm to those that behave as you do like, as well, then your stick is being swung far too wildly. I’d rather that a hundred eeeevil corporations “get away with” using a fork of OpenSSH in their proprietary software offerings than that a single end-user find that passing it on to someone else as a friendly gesture without source code has landed him in court. Why not work on encouraging good behavior rather than trying to force it at gunpoint? From a purely engineering-based perspective, weighing the positives against the negatives, this should be a no-brainer. If you want to give something away, give it away. If you want to control how other people can use and distribute it, start a corporation and use copyright and patent lawyers to enforce your will along with the rest of the ethically unsound jackasses out there. Your spiteful focus on hurting people because they didn’t adhere to your strict rules for source code distribution makes my skin crawl.

Besides, all this nonsense about the BSD license being roughly equivalent to the Public Domain in the ability of eeeevil corporations to bury it in proprietary software is obvious poppycock. Check out the PDF, “Reading the BSD License in Isolation”, at Open Source Law of Sydney, Australia if you don’t believe me. The ideas in it about forced contribution of source code are stretched pretty thin, I think, and wouldn’t hold up in court (thank goodness — don’t need another GPL), but the rest of it about copyleft, et cetera, is excellent reading and appears to be spot-on. (IANAL, but I’m not a complete legal dunce either).

All original content Copyright Chad Perrin: Distributed under the terms of the Open Works License