Monthly Archives: November, 2005

National Computer Security Day

November 30th was National Computer Security Day. It came and went .. did you notice? I previously blogged about National Cyber Security Awareness Month, calling into question the value of awareness months of any kind. Awareness days are no different. As William Knowles said, “might have been national kick a penguin day, I wouldn’t have known any difference..

Perl Format Strings

Dyad Security announced a new vulnerability in the Webmin web server component. The perl is vulnerable to a format string bug, which is mostly unseen in perl and quite common in C programs. The post calls this a “a new class of exploitable (remote code) perl format string“. Shortly after, Steven Christey of CVE posted that he had done research into this type of vulnerability as far back as 2002. His post gives a nice timeline of the discovery and research of these bugs, three programs that show the flaws, and references.

So while not quite a new class of vulnerability, it is one that is mostly overlooked by auditors no doubt. It will be interesting to see how many perl based format string vulnerabilities are discovered in coming months.

SANS Top 20 Report Value

SANS has released their Top 20 Internet Security Vulnerabilities for 2005. Started in June 2000, “the SANS Institute and the National Infrastructure Protection Center (NIPC) at the FBI released a document summarizing the Ten Most Critical Internet Security Vulnerabilities”. The list was designed to help administrators tackle the most critical issues on their network, targeting the most often exploited vulnerabilities.

Looking back at the first report, the list covers fairly specific programs or services with known vulnerabilities. BIND (named), RPC services (rpc.ttdbserverd, rpc.cmsd, rpc.statd), IIS RDS, Sendmail, sadmind and mountd, unpassworded default accounts, IMAP/POP and SNMP are eight of the ten on the original list. Two of the items are more abstract, covering “CGI programs and application extensions (e.g., ColdFusion) installed on web servers” as well as “Global file sharing and inappropriate information sharing via NetBIOS [..] or UNIX NFS exports”. Overall, this list provides a good basis for mitigating vulnerabilities, which is arguable based on your definition of the word.

Wikipedia defines a vulnerability as “a weakness or other opening in a system”. Fortunately for me/us, CVE has already covered this issue with their Terminology page and I don’t have to expand on this in more depth. This definition is a fundamental distinction in the world of VDBs and important when evaluating anything (especially papers) on vulnerabilities. While SANS does not explicitly define ‘vulnerability’, the wording of the introduction leans toward a definition of a specific software flaw that can be used to gain access or elevated privileges, rather than the more broad definition of a weakness/opening (or ‘exposure‘ as CVE calls it).

Based on that observation, the original Top20 list kept to the point and formed a list of specific flaws in computer systems (8 of 10) as well as two exposures. Looking at the current list, one has to wonder if the current level of abstraction has made the list more like a beginner’s guide to securing your computer rather than a list of often exploited vulnerabilities. The 2005 list does not make a distinction between the use of the word vulnerability over the last five years, nor does it define the word. In future lists, I believe it is essential that SANS begin to do so and disclaim their work accordingly.

The first entry on the 2005 list is “Windows Services” (W1) which covers just about every major Microsoft Windows service imaginable, including MSDTC and COM+ Service, Print Spooler Service, Plug and Play Service, Server Message Block Service, Exchange SMTP Service, Message Queuing Service, License Logging Service, WINS Service, NNTP Service, NetDDE Service and Task Scheduler. This type of entry more qualifies as an exposure backed by dozens of vulnerabilities. The second and third entries are “Microsoft Internet Explorer” (W2), an entire Web Browser, and “Windows Libraries” (W3) which are most certainly general exposures, not specific vulnerabilities. Fourth, “Microsoft Office and Outlook Express” (W4) cover half a dozen programs including Word, Excel, PowerPoint and Access. Many of the vulnerabilities associated with these products may overlap with “Windows Libraries” as well. The fifth entry “Windows Configuration Weaknesses” (W5) is an abstract entry that can cover an enormous range of exposures that can leave a system open to attack. So far, 5 out of 5 Windows related entries are exposures, not vulnerabilities.

The second section covers Cross-Platform Applications which sets itself up to be a fairly high level entry. Backup software (C1), Anti-virus Software (C2), PHP-based Applications (C3), Database Software (C4), File Sharing Applications (C5), DNS Software (C6), Media Players (C7), Instant Messaging Applications (C8), Mozilla and Firefox Browsers (C9), and Other Cross-platform Applications (C10) make up this wide ranged list that covers an incredible amount of software, operating systems and protocols. It is easy to argue that this list covers well over 50% of the vulnerabilities reported in 2004 (over 4,500 disclosed, and over 6,200 in 2005), making one question the value of a “Top 20” list that covers thousands of vulnerabilities. Consider that “backup software” or “media players” is fairly high level and reaches a level of abstraction that matches beginner security literature. Then consider “other cross-platform applications” is a catch-all for almost everything else out there since most products can be installed on any operating system these days.

The third section starts out with a high level of abstraction and gets worse. First is UNIX Configuration Weaknesses (U1) which would cover a wide range of operating systems such as Linux (all flavors), FreeBSD, NetBSD, OpenBSD, Solaris, AIX, HP-UX, IRIX and dozens of other UNIX variants. This would also cover Mac OS X which is a UNIX based operating system, which is very curious given the second entry under this section. “Mac OS X” (U2) is an entire operating system, and this entry even covers some software that comes with it such as the Safari web browser. Considering Microsoft IE and Mozilla browsers got their own entries above, we begin to see that the list doesn’t even maintain a consistant level of abstraction.

The last sections covers “Top Vulnerabilities in Networking Products”. We start with “Cisco IOS and non-IOS Products” (N1) which covers any product made by Cisco. Given their high installation base, they are an obvious target for vulnerabilities but once again, listing an entire vendor which includes their thousands of products? Next it lists “Juniper, CheckPoint and Symantec Products” (N2) which cover all products by these three vendors. Reading the definition of this entry makes me wonder if they ran out of time when trying to finish the document. Vulnerabilities were announced in these products.. exploit code available for some.. duh? This applies to any software out there, even other vendors with a high installation base. Last on the list is “Cisco Devices Configuration Weaknesses” (N3) which seems to be redundant to N1. One entry for “all Cisco products” and a second entry for “misconfiguring all Cisco products”?!

In summary, the “The Twenty Most Critical Internet Security Vulnerabilities (Updated) ~ The Experts Consensus” covers what? Certainly not the Top 20 vulnerabilities as defined by many security practitioners and vulnerability databases. You can’t even argue the list contains 20 exposures when it lists entire operating systems (Mac OS X/U2), configuration weaknesses (Windows/W5, Unix/U1, Cisco/N3) as well as redundant entries (Cisco N1 and N3). So, what does this list really cover? Who is this list supposed to help exactly? Telling administrators to upgrade all software and verify all configurations seems like a shorter and sweeter way of saying the same thing.

Google Device Vulnerabilities, EULA and more

H D Moore recently wrote that he discovered several vulnerabilities in Google Search Appliances. You can find details of these on the Metasploit Vulnerability Page, as well as search OSVDB for the corresponding entries. Normally this wouldn’t be worth posting about, however Moore’s comments on the Google EULA and how it impacts vulnerability research is worth noting. From his mail:

I found some fun bugs in the Google Search Appliance and uploaded the results in preparation for a Monday morning release. To get an idea of how many affected systems there are, just Google for inurl:proxystylesheet. Google released a patch on August 16th and I agreed to wait at least 60 days past that before disclosing the bugs.

A warning to anyone who owns one of these appliances – the EULA and confidentiality agreement prohibit any form of security research or publication of results. After I reported the issue, their security team offered to send me a Mini for patch verification, but agreeing to the license terms would prevent me from publishing any information about the product in the future. I got a beach towel and shirt instead 🙂

This also brings up why Google won’t publicly release their security advisories. Searching Google for “GA-2005-08-m” finds one reference to someone having problems with the latest patches, but no copies of the advisory. Seems Google is all about organizing and sharing world information.. unless it’s information on their own vulnerabilities? Oh wait, “the Google Search Appliance does not create security issues”!

Decreasing Time Between Web Application Vulnerability and Exploitation


Vulnerabilities in web applications continue to be the most frequently discovered security problem. This article illustrates how an attacker can take a vulnerability and quickly produce a functional exploit using the Perl LWP module. It demonstrates the process on two recently announced vulnerabilities. Finally, based on this knowledge, it addresses the question of how quickly administrators must patch systems after a new web application vulnerability is announced.

Decreasing Time Between Web Application Vulnerability and Exploitation


Vulnerabilities in web applications continue to be the most frequently discovered security problem. This article illustrates how an attacker can take a vulnerability and quickly produce a functional exploit using the Perl LWP module. It demonstrates the process on two recently announced vulnerabilities. Finally, based on this knowledge, it addresses the question of how quickly administrators must patch systems after a new web application vulnerability is announced.

Oracle: Three years and ten months without a patch

David Litchfield posted to Full-Disclosure pointing out more Oracle errata:

From: David Litchfield (
Date: Tue, 15 Nov 2005 13:12:41 -0000
Subject: [Full-disclosure] Three years and ten months without a patch

Whilst looking over old Oracle bugs I discovered that a fully patched Oracle server is still vulnerable to the old extproc flaw; this flaw, when exploited, allows a remote attacker without a userID and password to take control of the server. Why, you may ask, has a supported product gone for so long without a patch for a serious problem that was made public 3 years and 10 months ago and reported to Oracle over 4 years ago?


Litchfield’s mail contains a link to additional commentary with an answer to the question above. Oracle can spin this how they please, but I think Litchfield has hit the nail on the head.

Seeking an answer to this I found the following in Alert 57:

Currently, due to architectural constraints, there are no plans to release a patch for versions,, 8.1.6.x, 8.1.5.x,, 8.0.5.x, 7.3.x, or other patchsets of the supported releases.

What? Wait a minute. They managed to fix the flaw and deal with the same “architectural constraints” in other versions – why not A cynical observer might conclude that Oracle have deliberately left this unpatched in order to improve the chances of their user base upgrading to a version of Oracle that has a patch and having to part with more money. Oracle customers running, or any of the versions listed above would be right to feel indignant. This is exactly the kind of thing I was referring to when I posted this open letter.

NISCC Witholding Information from Vendors?

The idea behind CERT-like groups is the responsible disclosure and handling of vulnerability information. NISCC, in their own words:

Welcome to the National Infrastructure Security Co-ordination Centre

A fundamental role for any government is to ensure the continuity of society in times of crisis. This often involves providing extra protection to essential services and systems to make them more resistant to disruption and better able to recover quickly.

NISCC has no regulatory, legislative or law enforcement role; it seeks to achieve its aim through four broad work streams:

Outreach. Promoting protection and assurance by encouraging information sharing, offering advice and fostering best practice.

Despite their claims of outreach, the Openswan project is calling this into question. From a post to the DailyDave mail list:

NISCC’s achievement this time:

– do not release vulnerability information to open source vendors prior to release. Just tell them they cannot have the information for 4 months.
– try to postpone another 3 months, but getting their hands forced by CERT-FI
– do not list vendors impacted in their announcement.
– do not request a CVE.
– give the public absolutely no information on the vulnerability and whether they are impacted or need to urgently upgrade or not.

National Vulnerability Database (New Vulnerability Outage)

From: nvd @
To: Multiple recipients of list (nvdupdate @
Date: Mon, 14 Nov 2005 14:03:33 -0500 (EST)
Subject: National Vulnerability Database (New Vulnerability Outage)

There has been a serious and unexpected failure with the National Vulnerability Database (NVD) and Common Vulnerabilities and Exposures (CVE) vulnerability processing system. While all newly discovered vulnerabilities are being processed internally, these vulnerabilities are not being added to CVE or NVD. Due to the nature of the problem, it may take several days before the situation can be resolved. At that time, you will see a surge in vulnerability publication activity as we catch back up.

We apologize profusely for the outage and assure you that this will never happen again. We take our job of providing a timely and comprehensive vulnerability service very seriously and we are working hard to constantly improve the service for you.

Security Advisories, Mail Lists, and You

When a security researcher finds a vulnerability, they may choose to release the details in a formal advisory. The different between a random post to a mail list and an advisory typically involves the level of detail and the amount of peripheral information to the vulnerability. This includes discovery date, vendor communication timeline, patch information, formal writeup and technical details of the vulnerability. Because advisories are used as marketing material as much (or more) as vulnerability research/disclosure, some security companies would rather use them to attract attention to their web site.

To do this, they may post a brief message to a mail list announcing the discovery of a new vulnerability and a link to the advisory on their web page. This may seem logical and understandable, but in the long run this does a huge disservice to the security community. What happens when the security company goes out of business or gets purchased by another company? Overnight, all of their advisories and research may disappear. Mail list archives will then contain no useful information and a dead link to a site/advisory no longer there.

This problem (and debate) goes back a ways, most notably in 2000 when Elias Levy (then moderator of Bugtraq) rejected a post from @stake because the vulnerability report did not contain enough information. Thomas Greene covered this incident and dug into the issue. Levy later cited his reason for rejecting the post, which touches on my previous post:

“For very long we have tolerated the marketing copy on vendor advisories because while annoying they were accompanied by useful information. But in this change there is no value added to list subscribers. It’s for this reason that we are not accepting such advisories,”

For those of you who side with companies that post glorified advertisements without technical details, consider the following quote from Levy:

“I’ve asked the list subscribers for their opinions. I’ve received over five-hundred messages to far. While a handful of people liked the notices, the large majority of them, probably around 95 per cent, found the change to be a negative one and want me to hold firm to the policy of not approving them.”

The ultimate irony here is the Levy work[s|ed] for SecurityFocus, who was purchased by Symantec, who also recently purchased @stake and subsequently removed the @stake advisories from the web site a few weeks ago.