Chad Perrin: SOB

6 April 2007

Security Analysis: Symantec ISTR XI (Malicious Code Trends Highlights, Part 1)

Filed under: Security — apotheon @ 10:25

In my immediately previous analysis I presented some coverage of the “Vulnerability Trends Highlights” of Symantec’s Internet Security Threat Report, volume XI. Today, I’ll present an analysis of conditions surrounding one statistic from the Malicious Code 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.

Symantec’s Vulnerability Documentation Conflict of Interest:

Today, I will be dealing with exactly one statistic cited in the Malicious Code Trends Highlights, and no more. The reason for this is simple: explanation of the underlying circumstances of this statistic’s reporting by Symantec require a somewhat lengthy discussion of the nature of security vulnerabilities and Symantec’s relationship with them.

Symantec documented 1,318 malicious code instances in the second half of 2006. The company reports that 23% of them exploited vulnerabilities. This, of course, is a ridiculous statement: 100% of malicious code instances exploited vulnerabilities.

Symantec can be excused for failing to classify some of these malicious code instances as exploiting vulnerabilities. The types of vulnerabilities exploited fall roughly into three main categories:

  1. configuration vulnerabilities
  2. procedural vulnerabilities
  3. software vulnerabilities

It is excusable to exclude procedural vulnerabilities. These are vulnerabilities that arise as a result of poor adherence to security procedures, or security procedures that are incomplete or otherwise substandard, by those who maintain real-world deployments of software. As such, one might consider these to be a result of something other than a “vulnerability”, if one does not consider a social engineering opportunity or other human security failure to be a vulnerability — even though, by definition, that is exactly what it is.

It is not exactly excusable, but at least an understandable and probably honest mistake, to exclude configuration vulnerabilities from a measure of vulnerabilities. These are vulnerabilities that arise as a result of either unsecured configurations implemented in real-world deployments or a failure to account for and fix unsecured default configurations in for software as it ships.

Certainly, both of these types of vulnerabilities may be inappropriate to the purpose of this reported statistic, but choosing the terminology used so poorly — referring merely to “vulnerabilities”, rather than specifically to “software vulnerabilities” — is misleading and prone to produce errors in the way consumers of the Internet Security Threat Report think about system security. It is critically important that security professionals seeking to educate the members of the computer using public on the threats to their systems’ security educate them using correct, precise terminology and clearly presented concepts and principles. Otherwise, that “education” is at best deeply flawed, and at worst actually counterproductive, serving to confuse rather than clarify issues of security.

Software Vulnerabilities:

The third category of vulnerability — software vulnerabilities — can be further broken down into two subcategories:

  1. software vulnerabilities that Symantec records as vulnerabilities, for which all major operating system distributors generally issue patches
  2. software vulnerabilities that Symantec does not record as vulnerabilities, and for which only certain operating system distributors generally issue patches

The latter subcategory represent’s the one class of vulnerabilities for which Symantec cannot, if it is to be held to honest and competent standards of security professionalism, be excused. These are vulnerabilities that primarily form the basis for the antivirus scanning software industry — Symantec’s main niche of market penetration. All open source operating systems, to my knowledge at this time, actively patch all vulnerabilities related to malicious mobile code such as viruses and worms, as do at least many of the commercial Unix-based operating systems on the market. Microsoft Windows does not receive patches for these vulnerabilities at all — instead, Microsoft chooses to submit to a scan-and-block security model, which has materially contributed to the ever expanding threat represented by virus and worm propagation and proliferation on the Internet.

Virus scanners such as those licensed to organizations and individuals for a profit use databases of virus and worm definitions. The scanner uses these definitions to recognize malicious code when it is encountered, and removes or blocks the code (as appropriate). As new viruses and worms are discovered in the wild, scanner databases of definitions are updated with new definitions. This is a reactive approach that not only does not provide true preventative security in the aggregate, but also fails to effectively address the problems represented by the vulnerabilities these viruses and worms exploit.

A single virus definition essentially protects against a single virus — and nothing more. Similar, but sufficiently different to fool antivirus scanners, viruses are created to circumvent the dubious protection provided by extant definitions in scanner databases. These new variants usually exploit exactly the same vulnerabilities, but in a different manner, because the vulnerability still exists. The situation is analogous to a medieval castle whose drawbridge cannot be raised in the event of attack. Instead, descriptions of enemy uniforms are passed around to guards, and the guards are instructed to kill intruders who match these descriptions. Anyone who does not match such a uniform’s description is allowed through. Nobody patches the vulnerability — in this case, fixes the broken chains that, repaired, would allow the drawbridge to be raised — but every time someone notices that a pack of enemy soldiers in unrecognized uniforms has infiltrated the castle and started killing people, descriptions matching these new uniforms are circulated to the guards. The folly of this approach should be obvious, as should the simple fact that this results in an ever increasing catalog of discoverable but unpatched vulnerabilities that continue to be exploited by viruses — or “enemy soldiers”.

Symantec is, in this analogy, a large mercenary company that hires out guards to many castles, and distributes enemy uniform descriptions to these guards any time the owners of a Symantec-guarded castle requests it. It is lucrative for Symantec to operate under such conditions where virus and worm enabling vulnerabilities are never fixed, as this would largely obviate the need for its services by users of operating systems that thus suffer unpatched in the face of wave after wave of new viruses and worms exploiting old vulnerabilities.


This has been the fourth installment in my security analysis of the Symantec Internet Security Threat Report, volume XI. This is a series of (mostly) 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 continuing specific attention on the “Malicious Code Trends Highlights”, in brief.

don’t hold your breath

Filed under: Metalog — apotheon @ 01:30

I’m still catching my breath, so don’t hold yours.

I played two half-games of Go (lost both), talked about computer games and RPGs and music and war, hung out at a bar, went for a run, and realized it was midnight while I was dying on the couch (haven’t run in a LONG time). You’ll just have to suffer with the fact that I didn’t get around to a Symantec ISTR XI analysis for a whole day.

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