Monthly Archives: August, 2006

I think I may have found it. Claus Assmann (no no, too easy) of sendmail.org recently said some words to the CVE team regarding a recent Sendmail DoS. Look at the words and think about it:

BTW: it would be nice if your process of creating a candidate for inclusion in the CVE list makes sure that the security contact for the software is informed, so we don’t have to rely on some 3rd party to hear about this “DoS” for the software that we maintain. http://www.sendmail.org/security/

Yes, because the VDBs can maintain a list of vendors and think to mail each and every one regarding the 30 – 60 vulnerabilities disclosed each day. Yes, it is entirely our job to make sure you are informed that your code sucks ass. Had this been any vendor other than sendmail, you wouldn’t be reading this.

Hey Sendmail .. you hold the record, or are tied for, the WORST CODE EVER when it comes to security. Back in August of 1981 you were dealing with “multiple security issues”, you were a core part of the Morris Worm in 1988, and you have been a plague upon security administrators for 25 years. You do not have the right to talk to VDB admins like that sir.

There is a phrase about choosing who you sleep with because you may get fleas or some such. Claus, Sendmail as a program/group/whatever lost *all* rights to bitch about any vulnerability disclosure. In this case, that “3rd party” (you can hear him spitting as he typed that) is someone with OpenBSD, likely Theo de Raadt, who definitely knows security when it comes to coding. If that isn’t good enough, Sendmail (collectively) can shut their pie hole lest they choke on their own words:

SENDMAIL RELEASE NOTES
8.7.6/8.7.3 96/09/17
SECURITY: fix some buffer overruns; in at least one case this allows a local user to get root. This is not known to be exploitable from off-site. The workaround is to disable chfn(1) commands.

Let me quote the comment of another piece of working code as a response:

Hrm… and Eric Allman told me to my face that there were *no* buffer overflows in 8.7.5 — .mudge
This works on systems that have the chpass program runable by users. Tested on FreeBSD, though the vulnerability exists in all Sendmail8.7.5. Granted you need to be able to change your gecos field ;-)

The problem is in buildfnam() which lives in util.c – it treats the static allocated array nbuf[MAXSIZE+1], from recipient.c, in an unbounded fashion.

I’m so far behind in my daily routine and missed Thomas Ptacek’s post on Vuln Research In Numbers. Fortunately, Dave Aitel referenced the blog entry which prompted me to check it out. I so desperately want Ptacek to run his numbers against a complete OSVDB data set, but alas, I know that we do not have a complete data set for 2004. Symantec’s BID database has some problems with consistancy, citing sources (aka provenance) and missing vulnerabilities (which plagues most VDBs to one degree or another). In my mind, OSVDB tends to be more complete than most VDBs and maintains a creditee field, but due to a lack of volunteers we just don’t have enough entries public for him to do the same generation of statistics. Some day maybe! Until then, this is a very neat post with a different slant.

No, this isn’t some odd contest with a disappointing reward. Date an OSVDB moderator! *shudder*

Think of dates in the context of vulnerability disclosure. Think of how many dates we don’t know, even in the more formal advisories (some with time lines even). OSVDB currently tracks three dates: Vulnerability Published, Vulnerability Discovered, Exploit Published. We have additional dates that we will add to the system as developer time permits, but unfortunately most vulnerabilities don’t come with the information we need. In a perfect disclosure world, each vulnerability posted would come with a robust timeline:

Vulnerability Discovered

Disclosed to Vendor

Vendor Acknowledgement

Vendor Patch

Public Disclosure

This would allow VDBs to track better metrics, including vendor response time, patch development time and more. Are there more dates that would be relevant and of interest?

I’ve mentioned the sociology aspect of the hacker, vuln researcher and security companies before, specifically how they interact, how one will influence another and more. The list of fun ideas I have on these topics is great, and maybe some day i’ll find the time to write more on them. In the mean time, this obvious one popped up and focuses on vulnerability researchers, how they find bugs, and how some feed off the work of others. We see this often where ResearcherA will find a vulnerability in one script, disclose the information, and ResearcherB will followup shortly after with the same type of vulnerability in a different script of the same product.

Recently we’ve seen a rash of remote file inclusion bugs in various add-ons to Mambo and Joomla. These add-ons are typically not written by the same developers nor are they distributed with the base installation of each product. However, they all seem to have one thing in common: “mosConfig_absolute_path” (or sometimes “absolute_path”). The same variable is being exploited in dozens of different add-ons and being found by different people. If we examine the chain of disclosure, can we see patterns in who consistently does followup research (low hanging fruit) instead of finding original vulnerabilities? Are there more observations in the way they are disclosed such as reporting to exploit sites vs Bugtraq or Full Disclosure? Are there misplaced signs of ego that accompany what amounts to trivial vulnerability finds while others are more modest and take it for what it is? Is it surprising that as people jump on the bandwagon, more and more reports end up being inaccurate and not a real vulnerability?

While skimming the list, strike-out text indicates the vulnerability has been disputed or proven false. The names of the researchers who didn’t fully check their find are in bold (and I’m curious if the other disclosures hold up under scrutiny). There is one occurrence of italics that potentially shows this type of “research” being used in the wild.

On December 20, 2005, I posted a contest looking for the oldest documented vulnerability. This generated a lot of interest and was posted to the FunSec Mail List which generated even more interest and information. It also lead to me spending more time digging through my own notes and archives, something I had been meaning to do for ages. Even after all this time, the list of old papers and resources I have to track down is daunting. Since it is an ongoing project, I am overdue in posting about the winner of this contest. Not only did he eventually lead me to the documentation referencing what we call “Multics System Text Editor Multiple Instance CTSS Password File Disclosure” (Jan 1, 1965), but during ongoing e-mail discussion we were able to uncover several more in 1972. For that, Ryan Russell is the winner of this contest. We’ll be sending him some OSVDB schwag in return for his time and research.

Symantec posted a message to Bugtraq earlier this month announcing the availability of a new advisory. The advisory presumably covers a vulnerability or issue in Symantec On-Demand Protection. If you are reading this blog entry a year from now, that is all you may find on it. Yes, even in this day and age, not everything is archived in Google cache or archive.org! In December of 2000, Elias Levy (moderator of Bugtraq at the time) said that such posts were not acceptable because security company web sites had a habit of disappearing, leaving no trace of the information behind. Years later, Symantec bought SecurityFocus (who hosts/moderates the Bugtraq mail list) and we see this rule being ignored, and of course the approved post comes from their owner. Some may argue that Symantec is huge and won’t disappear like those other companies. Many said the same about @stake but shortly after they were purchased, their new owner (Symantec) opted to yank all of the old advisories off the web site making Elias Levy’s concerns reality. As Chris Wysopal said in reply, Symantec needs to post their advisories to the list just like everyone else. While Symantec may stick around, their web site may change or corporate policy may be altered, and that information may not be readily available in the future.

On December 20, 2005, I posted a contest looking for the oldest documented vulnerability. This generated a lot of interest and was posted to the FunSec Mail List which generated even more interest and information. It also lead to me spending more time digging through my own notes and archives, something I had been meaning to do for ages. Even after all this time, the list of old papers and resources I have to track down is daunting. Since it is an ongoing project, I am overdue in posting about the winner of this contest. Not only did he eventually lead me to the documentation referencing what we call “Multics System Text Editor Multiple Instance CTSS Password File Disclosure” (Jan 1, 1965), but during ongoing e-mail discussion we were able to uncover several more in 1972. For that, Ryan Russell is the winner of this contest. We’ll be sending him some OSVDB schwag in return for his time and research.

I keep telling myself, “keep it short!” since writing about a week in Las Vegas tends to be wordy. No promises!

Some 3000 people apparently showed for BlackHat briefings and it showed. Despite that much money coming in and the amount of warning Caesars/BH had before the con, it was extremely frustrating attending (or giving) talks/panels where the speakers didn’t even have chairs. Like previous years, having to decide between six different tracks makes it difficult to see everything you want. Given that the videos are not always released in a timely manner, some slides don’t do the talks justice, and the professional/official videos of talks cost money, you really end up missing out on a lot of good material despite the high price tag for entry. Also frustrating this year was the abundance of “technical” talks chosen because some BH staffers they are what draws people in. While often true, having so many tracks on SQL injection or Cross-Site Scripting gets old .. even with the various “new twists” or new methods for bypassing current protection schemes. I only mention this because I read several other proposals for talks that weren’t accepted, likely due to them being a bit less technical, even though they would have been in conjunction with new tools or information. If there will be six tracks next year, please consider keeping four of them for highly technical (but focused on *new*) presentations, and two for other presentations that are of interest to the security field.

Defcon’s big change was moving from the Alexis Park to the Riviera. On the up side, all indoors and air conditioned, bigger convention space, nifty skyboxes (underused though), more availability to quick food and drink in the hotel. On the down side, still ran out of room in some talks, couldn’t run across the road to as many restaurants and such, forced to deal with families / non convention types, many of the talks were either weak or previously done at BlackHat, they ran out of badges again (how many years before they print up an extra thousand), vendor area was cramped while the big room was underused, skyboxes were neat but most were empty all day even when it would have allowed dozens more to see a full talk, the talks couldn’t be piped to the hotel rooms like they were at Alexis and many other minor things.

All in all, I felt the cons were about average. Some good, some bad, not a whole lot really changed all said and done.

And finally, a lot of ‘thanks‘ are in order. In no particular order, sincere thanks goes out to: Mike Andrews and Foundstone for their detailed interviews with various folks involved in the security community. In return for an hour of my time talking about my involvement with OSVDB and Attrition.org, they gave me a chance to say a few things I felt important and kindly rewarded me with an excellent bag of schwag. iDefense, TippingPoint’s Zero Day Initiative and Microsoft (yes, I’m publicly thanking them!) for hosting excellent parties that allowed all sides of the industry to meet and talk. Steven and Bill of CVE as well as Jeffrey and Art from CERT.org (yes, I’m publicly thanking them!) for sitting down over beers to discuss vulnerability databases and related topics. I was a bit harsh on all of them but hopefully they know it’s because I care about the future of VDBs and want us all to provide a better service to our respective ‘customers’. William Knowles from InfoSecNews (ISN) for the offered sushi dinner I had to bail out on last minute as well as countless favors and advertising for OSVDB. Simple Nomad, Weasel and the fine folks at NMRC for a fun presentation and a steady stream of great research and information. Carole Fennelly and the rest of Hacker Court for another fun year of faux courtroom antics. Where else do you find an EFF lawyer mocking the EFF and a former DoJ lawyer defending hacker scum?! The Electronic Frontier Foundation (EFF) for stepping up and turning into the watchdog organization that we so desperately need. Pyr0 and the rest of 303 for skybox and party. Jake Kouns and Hooters for hosting the OSVDB Mangler Dinner. The Hilton Star Trek thingy for letting me finally get a replacement for the tribble I lost twenty years ago. To anyone I introduced to friends or colleagues as “older than dirt“, for giving me a little faith that a few others have stuck around. Delchi for getting us into the Krave Lounge and spinning great music there (as well as the 303 party).