That Vulnerability is “Theoretical”!
A few days ago, while writing a draft of a different blog, I made reference to and said “we’re well aware of the pitfalls around calling a vulnerability ‘theoretical’“! I wanted to link off to what I was referencing, a case where security researchers found a vulnerability in a big vendor’s products and were told it was “theoretical”. Of course, they in turn provided a working exploit for the vulnerability proving it wasn’t just theory. Thus, around 1995, the researchers took on the slogan “L0pht, Making the theoretical practical since 1992.” After digging, I couldn’t find a concise story of the details around that event, so I took to Twitter. Over the course of a couple hours, with input from many people, including some involved with the story, I collected the details. I told those in the conversation that if I had the information I would blog about it to better preserve that slice of history.
My bad memory had me believing the vulnerability was in Sendmail, and that Eric Allman said it to Mudge. Royce Williams dug up the Sendmail exploit i was thinking of, and the header text from Mudge suggested I was on the right track.
*NIX Sendmail (8.7.5) – Buffer Overflow – Newest sendmail exploit
:
# 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.
Next, Royce reminded me that I had actually referenced that vulnerability in a prior blog post from 2006… oops! Mark Dowd was the first to challenge me on that, saying he believed it was related to a vulnerability in Microsoft’s products, related to RAS or CHAP, and he was right about the vendor (which vuln it was specifically is still not confirmed). Next, Space Rogue, an original L0pht member chimed in saying he thought it referred to Microsoft and the NT/Lanman vulnerability, and that the 1992 part of the slogan simply referred to when L0pht was formed. DKP further confirmed this by digging into the wonderful Internet Archive, finding the slogan and quote on the L0pht’s page.
“That vulnerability is completely theoretical.” — Microsoft
L0pht, Making the theoretical practical since 1992.
From here, Weld Pond and Mudge, original members of the L0pht joined the conversation. First, Weld said it might be a RAS or CHAP vulnerability but he wasn’t certain, but that the slogan came from a response from a Microsoft spokesperson who was quoted saying “that vulnerability is theoretical“, and that resulted in the exploit being written to prove otherwise. Weld further confirmed what Space Rogue had said, that the “slogan was coined in 95 or so but made retrospective to the founding of the L0pht.”
DKP continued digging and found the quoted in Bruce Schneier’s “Secrets and Lies”, and pointed out Schneier worked with Mudge on a MS-CHAPv2 vulnerability. The paper on that vuln is from 1999 though, suggesting it wasn’t the “theoretical” vuln.
With that, the “theoretical” vulnerability is mostly uncovered. It would be great if anyone could confirm exactly which vulnerability it was that prompted the response from Microsoft. If anyone else recalls details about this, please share!
In the mean time, we also get to wonder about the Sendmail story, where this saga started, that also apparently is interesting. Space Rogue mentioned there was a separate story around that, but couldn’t remember details. Mudge jumped in confirming it was a Sendmail 8.6.9 exploit, “in response to in-person ‘discussion’ w/ [Eric] Allman at a Usenix Security in Texas. Witnesses, but no writeup.” Mudge added that “a very similar ‘quote’ happened in person with Allman quite some time prior to the MS issue. It wasn’t a throw away quote. I/we lived it 🙂”
August 14, 2017 Update:
Mudge provided more insight into another issue, also a ‘theoretical’ risk. During the Twitter thread, there were questions about L0phtcrack. Mudge says “In a nutshell – a MSFT PR article in NT magazine said l0phtcrack was a theoretical risk but not an actual one. I responded with LC rant. Soon after we coined the phrase to describe the PoCs I felt it was crucial to write and release“. DKP dug up a Wired article that better illustrates how vendors can dismiss security researchers:
A Time to Patch
http://blogs.washingtonpost.com/securityfix/2006/01/a_timeline_of_m.html
Brian Krebs has a fantastic post on his blog covering the time it takes for Microsoft to release a patch, and if they are getting any better at it. Here are a few relevant paragraphs from it, but I encourage you to read the entire article. It appears to be a well developed article that is heavily researched and quite balanced. Makes me wonder if his editors shot it down for some reason. If they did, shame on them.
A few months back while researching a Microsoft patch from way back in 2003, I began to wonder whether anyone had ever conducted a longitudinal study of Redmond’s patch process to see whether the company was indeed getting more nimble at fixing security problems.
Finding no such comprehensive research, Security Fix set about digging through the publicly available data for each patch that Microsoft issued over the past three years that earned a “critical” rating. Microsoft considers a patch “critical” if it fixes a security hole that attackers could use to break into and take control over vulnerable Windows computers.
Here’s what we found: Over the past three years, Microsoft has actually taken longer to issue critical fixes when researchers waited to disclose their research until after the company issued a patch. In 2003, Microsoft took an average of three months to issue patches for problems reported to them. In 2004, that time frame shot up to 134.5 days, a number that remained virtually unchanged in 2005.
First off, these are the kind of statistics and research that I mean when I talk about the lack of evolution of vulnerability databases. This type of information is interesting, useful, and needed in our industry. This begins to give customers a solid idea on just how responsive our vendors are, and just how long we stay at risk with unpatched vulnerabilities. This is also the type of data that any solid vulnerability database should be able to produce with a few clicks of the mouse.
This type of article can be written due to the right data being available. Specifically, a well documented and detailed time line of the life of a vulnerability. Discovery, disclosure to the vendor, vendor acknowledgement, public disclosure, and patch date are required to generate this type of information. People like Steven Christey (CVE) and Chris Wysopal (VulnWatch) have been pushing for this information to be made public, often behind the scenes in extensive mail to vendors. In the future if we finally get these types of statistics for all vendors over a longer period of time, you will need to thank them for seeing it early on and helping to make it happen.
This type of data is of particular interest to OSVDB and has been worked into our database (to a degree) from the beginning. We currently track the disclosure date, discovery date and exploit publish date for each vulnerability, as best we can. Sometimes this data is not available but we include it when it is. One of our outstanding development/bugzilla entries involving adding a couple more date fields, specifically vendor acknowledge date and vendor solution date. With these five fields, we can begin to trend this type of vendor response time with accuracy, and with a better historical perspective.
While Krebs used Microsoft as an example, are you aware that other vendors are worse than Microsoft? Some of the large Unix vendors have been slow to patch for the last twenty years! Take the recent disclosure of a bug in uustat on Sun Microsystems Solaris Operating System. iDefense recently reported the problem and included a time line of the disclosure process.
08/11/2004 Initial vendor contact
08/11/2004 Initial vendor response
01/10/2006 Coordinated public disclosure
Yes, one year and five months for Sun Microsystems to fix a standard buffer overflow in a SUID binary. The same thing that has plagued them as far back as January 1997 (maybe as far back as December 6, 1994, but details aren’t clear). It would be nice to see this type of data available for all vendors on demand, and it will be in due time. Move beyond the basic stats and consider if we apply this based on the severity of the vulnerability. Does it change the vendor’s response time (consistently)? Compare the time lines along with who discovered the vulnerability, and how it was disclosed (responsibly or no). Do those factors change the vendor’s response time?
The answers to those questions have been on our minds for a long time and are just a few of the many goals of OSVDB.
OSVDB 