With regard to the recent Patch Tuesday fix, there has been an issue fixed regarding NTLM Relaying, that has been around for more than eight years.

In 2000, I wrote an advisory about NTLM relaying (CVE-2000-0834). The problem turned out to be significantly larger than I originally suggested in the advisory. The attack extended to other NTLM-based authentications on other protocols and allowed general-purpose credential theft via a man-in-the-middle attack.

The SMBRelay tool was published in 2001 by Sir Dystic of Cult Of The Dead Cow, and that really took it to the next level. The protocol completely fell apart. It kicked off a number of other analyses of the NTLM protocol that finally resulted in this patch. Eight years after it’s discovery.

At least they got around to it. Thanks!

There is apparently a bit of fear going around information security circles that the next big trend in the disclosure wars is going to be “Partial Disclosure”. In the past, the vulnerability research community has embraced the concepts of “Full Disclosure” and/or “Non-Disclosure”. Once those concepts had been sufficiently played out, the general consensus was to move towards “Responsible Disclosure” whereby the security researcher responsibly discloses the discovered vulnerability to the vendor and works in a cooperative fashion in an effort to minimize the risk to the general user populous. This has worked well in the vast majority of cases that I have had the pleasure of managing the disclosure process.

Partial Disclosure - The Good

The responsible disclosure process tends to break down in rare occasions where the vendor doesn’t want to fix the issue. When this occurs, the researcher is put into a difficult position whereby full disclosure could put users’ systems at high risk of compromise. The other case where partial disclosure becomes an alternative is when the researcher has discovered a design flaw in a protocol or underlying multiple vendor component. Examples of this case include the DNS flaws published this past summer by Dan Kaminsky and the TCP denial of service condition discovered by Robert E. Lee and Jack Louis that is currently in the disclosure process. When the flaw affects a very large number of vendors and the actual problem is located within the underlying protocols that support the communications of the Internet as a whole, one possible solution is to follow a partial disclosure model where phasing the details to the general public can be used to encourage adoption and creation of patches throughout the enormous target audience.

Partial Disclosure - The Bad

What is driving the fear surrounding partial disclosure is the potential for abuse. When a major flaw is partially disclosed, a number of potential issues may occur. First and foremost, the further along the partial disclosure path we are, the more details will be released to the public, and the higher the probability that someone (either good or bad intentioned) will figure out the exploit and disclose the details. Second, when partially disclosing, the vendor’s hand is being forced into a situation that could speed up fixes, reduce testing, and cause ripple problems elsewhere within the infrastructure. It is difficult enough to dance the fine time line when doing responsible disclosure, but if we are escalated to the point of partial disclosure, additional fuel is added to the fire.

The Ugly

The real ugly part of partial disclosure is when we add to the equation the ability to spread fear, uncertainty, and doubt into the normal user community. It is generally well accepted that FUD can be used to drive additional revenue. If it is possible to increase the perceived magnitude of the “problem” that your product or service solves, it is possible to directly impact the demand for that product or service. That is the major fear imposed by the growing trend of partial disclosure. By releasing just enough information to trigger wide scale speculation into the flaw, it is possible to create buzz and garner media attention resulting in a lot of speculation and very little hard facts around the issue. The potential for abuse by the security industry at large is enormous.

The Fix

Some have suggested a group of security researchers be convened to vet the requirement of partial disclosure and to allow for independent peer review of any security research that requires the partial disclosure process. This suggestion leaves questions regarding who would stand on this group and who would be impartial enough to ensure that the right thing was always done regardless of profit potential. It also leaves open the opportunity for member researchers to utilize the information gathered during the vetting process to position themselves to profit from the data upon release. It might be wiser to rely on a higher level authority or government entity to manage this process and use the services of security researchers as required for subject matter expertise. While a group of this type wouldn’t ensure that all partial disclosure is appropriate, it would hopefully limit the potential for abuse and the ever present chance that people try to profit from the FUD that surrounds the current partial disclosure process.

By now, you probably know that details of the DNS vulnerability have leaked. Halvar Flake speculated on DailyDave and the momentum built from there, despite the fact that his guess was short on a few key details. I don’t need to rehash the full technical details here; by now, they are easy enough to find with a couple Google searches. When Slashdot picks up the story, it’s hardly a secret any more.

What’s more interesting to me, now that I’ve digested the big secret, is how this whole situation has played out in the security community.

The security community has been polarized for the past two weeks, not so much over the technical details being withheld, but about Dan’s plea that people not speculate about the vulnerability. As many pointed out, the “bad guys” won’t stop trying to figure it out just because the “good guys” keep quiet. To be honest, my own lack of public speculation wasn’t because I agreed with the philosophy; I just wasn’t smart enough to figure out the vulnerability myself.

People implied — or stated outright — that Dan just didn’t want anyone stealing his thunder. Considering the timing of the release and the subsequent BlackHat talk, it’s obvious why such accusations were made. Personally, I think it’s a little of each. I believe the coordinated patch effort was undertaken with the best of intentions, but I also think Dan relished some of the glory and media attention as well. It’s hard to blame him for that; if you were in his shoes, wouldn’t you want some recognition too?

By many accounts, dealing with the DNS vulnerability from the operational side has been an exercise in frustration. Plenty of IT people wanted to patch but couldn’t get approval without being able to justify the operational risk. “Because Dan said so” is apparently not a convincing enough argument. Some wondered why the people who were responsible for creating the problem should be blindly trusted to implement an appropriate fix?

Ultimately, vulnerability disclosure is a minefield. No matter how you choose to disclose, somebody will always disagree.

P.S. If you didn’t figure out the title of the post by now, Nate was one of the unlucky few to draw the same timeslot at BlackHat as Dan Kaminsky.

The security community is cynical. So much so, that most of the chatter that’s taken place over the past 24-36 hours has suggested that Kaminsky’s DNS vulnerability was little more than a publicity stunt and that his BlackHat presentation would be an over-hyped rehash of prior art. Granted, one has to suspend disbelief to even consider that something monumental would be discovered in DNS — that’s the protocol itself — but hell, it’s always nice to give a guy the benefit of the doubt.

Faced with nearly a month of criticism and questioning, and understanding the persuasive power of a technical peer review, Dan decided to expand the inner circle, so to speak. Rich Mogull arranged a phone call with Tom Ptacek and Dino Dai Zovi so that Dan could spill the beans and let them decide for themselves whether it was spin or substance. Turns out there was substance.

Now we sit around and wait until August 6th to cram into a ballroom with a thousand sweaty conference-goers to hear the juicy details. And Dan’s presentations are usually packed to the brim even when he’s not announcing anything.

In the meantime… how about patching those servers?

Rich Mogull’s executive overview of Dan Kaminsky’s latest DNS vulnerability fluffed a few feathers yesterday:

The good news is that due to the nature of this problem, it is extremely difficult to determine the vulnerability merely by analyzing the patches; a common technique malicious individuals use to figure out security weaknesses.

The typical response I heard was “what do you mean, it can’t be reverse engineered? I’ll just look at the diffs!”

In hindsight, after examining the BIND diffs (yes, I did it too) and discussing with colleagues, all most people saw was UDP source port randomization and a better PRNG for generating the transaction ID, the latter of which would appear to be related to Amit Klein’s cache poisoning attack from about a year ago.

What Rich was really saying is that you can reverse engineer the patch until you’re blue in the face, but that won’t reveal the specifics of the vulnerability.

Dan’s blog post this morning appeared to confirm that interpretation:

DJB was right. All those years ago, Dan J. Bernstein was right: Source Port Randomization should be standard on every name server in production use.

There is a fantastic quote that guides a lot of the work I do: Luck is the residue of design. Dan Bernstein is a notably lucky programmer, and that’s no accident. The professor lives and breathes systems engineering in a way that my hackish code aspires to one day experience. DJB got “lucky” here — he ended up defending himself against an attack he almost certainly never encountered.

Such is the mark of excellent design. Excellent design protects you against things you don’t have any information about. And so we are deploying this excellent design to provide no information.

To translate the fix strategy into a more familiar domain, imagine large chunks of Windows RPC went from Anonymous to Authenticated User only, or even all the way to Admin Only. Or wait, just remember Windows XPSP2 :) This is a sledgehammer, by design. It cuts off attack surface, without necessarily saying why. Astonishingly subtle bugs can be easily hidden, or even rendered irrelevant, by a suitably blunt fix.

Nate McFeters appears to think that Tom Ptacek has figured it out. I’m going to go out on a limb and say that Tom didn’t figure anything out yet but still wanted to write a pithy blog post. I think that if Tom had figured it out, he would have written it down privately and posted the SHA-1 hash, as is the trendy thing to do these days.

Speculation aside, the title of Tom’s blog entry, Dan Kaminsky could have made hundreds of thousands of dollars with this DNS flaw!, does make an important point — Dan didn’t sell the details to ZDI, he used his influence and reputation to coordinate a massive vendor patch effort. That’s an admirable move.

We all know it happens, but it is rarely exposed as clearly as Adam Pennenberg did in his article for Fast Company, The Black Market Code Industry. It turns out that this 0day seller was an HP employee:

According to the consultant who snared Marester, his quarry’s skills appear quite sophisticated. His wares, if they performed as advertised, could help a hacker take down machines running that particular software anywhere in the world. His real name is Steve Rigano; he’s a self-employed network consultant from Grenoble, France, who works full time at HP, where he is listed in the switchboard and maintains an hp.com email address. He told me that he saw nothing wrong with offering tools and techniques that targeted the company providing his paycheck.

A self-taught hacker, Rigano says he discovered the vulnerabilities and coded the exploits on his own time, which he says is none of HP’s business. “I have the right to sell what I want,” he says. He told me he attracted mostly Chinese and Russian buyers, but claimed he never found takers for the HP or SAP “vulns” and exploits. He said he stopped selling black-market code in January but didn’t explain why.

Most security companies I have been acquainted with frown on this type of activity, as I am sure HP has. It’s hard for them to sell security products and services when their employees are selling the very tools the company is purportedly defending against.

[Update 7/7/2008: The information in the Fast Company article is being disputed by Steve Rigano. He has notified us that he has taken legal action against Adam Pennenberg and Fast Company.]

DWR 2.0.5 addresses an XSS vulnerability that is likely to be exploitable in most 2.0.4 installations. If your web application uses DWR’s Ajax implementation, download and install this update now!

As an aside, I’ve been a fan of DWR for a while now, not only because of its ease of integration but also because it was the first Ajax framework to offer built-in CSRF protection. You could tell that Joe Walker was taking security seriously. For this particular vulnerability, I e-mailed him on a Saturday night, and within 12 hours, he had confirmed the problem, patched the code, and built a 2.0.5 release candidate. Granted, it was a tiny code change, but I’ve still never seen a response that fast. Less than a week later, the official 2.0.5 release was tested and available for download.

That’s it for now, but I’ll be referencing this example again when I get around to writing Part 2 of my Minimizing the Attack Surface post.

Yesterday, Dave Lewis over at LiquidMatrix Security Digest cried foul at Core Security for releasing too much detail about a recent DoS vulnerability they had discovered. His specific gripe was that they provided an IDA Pro excerpt that showed where the vulnerability was triggered. The excerpt is short, so I’ll even copy/paste it here:

.text:00405C1B mov  esi, [ebp+dwLen]  ; Our value from packet
...
.text:00405C20 push edi
.text:00405C21 test esi, esi          ; Check value != 0
...
.text:00405C31 push esi               ; Alloc with our length
.text:00405C32 mov  [ebp+var_4], 0
.text:00405C39 call operator new(uint); Big values return NULL
.text:00405C3E mov  ecx, esi          ; Memcpy with our length
.text:00405C40 mov  esi, [ebp+pDestionationAddr]
.text:00405C43 mov  [ebx+4], eax      ; new result is used as dest
.text:00405C46 mov  edi, eax          ; address without checks.
.text:00405C48 mov  eax, ecx
.text:00405C4A add  esp, 4
.text:00405C4D shr  ecx, 2
.text:00405C50 rep  movsd             ; AV due to invalid
.text:00405C52 mov  ecx, eax          ; destination pointer.
.text:00405C54 and  ecx, 3

Dave asserts that publishing 16 commented assembly instructions makes this disclosure irresponsible. But look at the code — it’s completely generic, just a textbook example of what it looks like when you forget to check a return value after calling operator new. Sure, Core gives you the exact offsets into the executable, but so what? If I have the binary, then it’s not going to be too hard to find the vulnerability anyway. It’s not like Core is giving away a proof-of-concept exploit that generates the malformed registration packet required to trigger the DoS. What’s more, they provide a detailed timeline going back to January 30th of this year describing exactly how the disclosure process with the vendor transpired. This looks extremely responsible to me; I just can’t understand what is “not cool” here.

There’s another interesting angle to this, completely unrelated to Core’s disclosure process. The vulnerability itself is described in the advisory as follows:

Un-authenticated client programs connecting to the service can send a malformed packet that causes a memory allocation operation (a call to new() operator) to fail returning a NULL pointer. Due to a lack of error-checking for the result of the memory allocation operation, the program later tries to use the pointer as a destination for memory copy operation, triggering an access violation error and terminating the service.

This may bring to mind some recent discussions on whether callers of memory allocation functions should check the return value prior to use. To summarize, one camp says “caller should check”, the other camp says “callee should exit on allocation failure.” This is a gross oversimplification and if you want more detailed arguments, read the other blog posts that I linked to. In this case, if the “exit on failure” approach were taken, the DoS scenario might still happen, whereas if the caller were checking, the error could be handled more gracefully. More fuel for the debate!

I was just reading an article discussing the timeframe for upcoming revisions to the PCI-DSS. Nothing quite so exciting as reading about a compliance roadmap, right? This article reminded us about PCI Section 6.6 becoming mandatory in June 2008, with additional guidance and clarification coming in May (hey, a whole month to prepare!). As a refresher, 6.6 says that web applications must be reviewed by a third party for security vulnerabilities, or a web application firewall (WAF) must be installed. Anyway, in this article, PCI-DSS General Manager Bob Russo makes the following statement:

“Personally, I’d love to see everyone go through on OWASP-based source-code review, but certainly, that’s not going to happen,” Russo said, referring to the expensive and time-consuming process of manual code reviews. “So the application firewall is probably the best thing to do, but there needs to be some clarification around what it needs to do. That clarification is coming; that’s been the biggest question.”

Really? The WAF is the “best thing to do?” Maybe he meant to say “cheapest” or “quickest,” but how is a WAF better than fixing the root cause of vulnerabilities? I don’t deny that a WAF can be valuable to a layered security approach. For example, if I need to quickly plug a hole in my web app, I can configure the WAF to block it, thereby buying time for the development team to fix the problem. Instead of having to fix the bug immediately, it can be rolled into the next release cycle, with the WAF protecting the site in the interim.

Sure, the WAF can protect against some known attacks, and if you set it up the right way, it can attempt to detect and block other, unknown attacks — that is, if it’s configured aggressively enough. Except very few companies will actually do that. Nobody wants to risk the WAF confusing a legitimate request with an attempted attack and subsequently blocking user traffic.

This is why I argued, a while back, that a WAF really should be considered a compensating control since it is more of a band-aid than a best practice solution. That would give the requirement a lot more credibility rather than giving enterprises an easy way out.

There is an heap overflow vulnerability in RealPlayer 11 build 6.0.14.74. It allows for code execution when RealPlayer opens a malicious song file.

Timeline

Dec 16, 2007: Gleg customers notified of vulnerability and given exploit code

Jan 1, 2008: Public disclosure (no details) with online demonstration

Feb 6, 2008: Vulnerability still not patched

It’s not your typical disclosure time line. In recent years we have become accustomed to a disclosure time line that goes something like this:

Typical Timeline

Dec 16, 2007: Vendor notified of vulnerability and given exploit code

Feb 6, 2008: Public disclosure with details and vendor patch available

Feb 7, 2008: Some customers patched

We don’t know when this unpatched RealPlayer vulnerability was introduced into the code. It has probably been latent for many months. Real’s customers were vulnerable as soon as they downloaded this version of RealPlayer. Certainly, Real needs to increase its efforts to reduce security vulnerabilities in its shipping products. Still, the first disclosure time line is troubling.

Gleg knew how to reproduce this problem at least a month before yet they didn’t tell the vendor, just their customers. It’s unclear what benefit Gleg’s customers get from the vendor not knowing this information unless they use this information to compromise other systems, especially with this being a client side vulnerability.

In an eWeek article Gleg founder explains:

Gleg founder Evgeny Legerov confirmed his company’s refusal to share the RealPlayer exploit details, arguing that he needs “exclusivity” for a few months to help his customers understand the level of risk they face.

I guess I don’t quite get it. Without being a Gleg customer, even from the minimum information available, I already know I need a fixed RealPlayer and until then I need to block these files at my perimeter and disable RealPlayer. I know that users with RealPlayer 11 installed will undoubtedly stumble across a malicious music file and their system will have a bot installed running with their logged in privilege level. I’m not sure what additional value I would get as a Gleg customer.

Now on the other hand Real could simply become a Gleg customer, pay for the exploit, run it in their lab and diagnose the vulnerability. Then they could fix the vulnerability and we would have a time line closer to the second one. Still I don’t see the value, even in this scenario, of more organizations than the vendor knowing about the vulnerability details and getting the exploit.

A protocol that better protects the security of our software ecosystem would be for vulnerability finders to contract directly with the vendor to find vulnerabilities. Customers of the vendor could get high level summary information that the vulnerability exists and its type so they could weigh the risks of using the product and the vendor would get the details they need to remediate the vulnerability.

The above is how Veracode’s Vendor SecurityReview service works. Customers that are concerned about the security of software they are purchasing use Veracode as a 3rd party assessment service. We will contact the vendor and have them upload their software binary executable to our portal. We analyze the software and deliver a detailed report of the security issues we find in the code. We also generate a summary report for the customer to understand the security risks of the software.

A cooperative solution is a much safer way for customers to understand the risks of the code they run. After all do you want to know about just one vulnerability or see the summary of a comprehensive assessment. A cooperative solution also promotes good security hygiene on the vendor side. We have found that once vendors know that their big customers are using Veracode’s Vendor SecurityReview service they are more likely to proactively start doing security testing within their SDLC. A vendor can’t bluff their way out of a comprehensive code assessment like they can from just a single (or a few) vulnerabilities publicly reported. If their code is full of vulnerabilities their customers will know.

UPDATE 2/09/08: It seems the RealPlayer vulnerability being used in mass website attacks as reported by SANS ISC is not the same vulnerability at the unpatched Gleg RealPlayer vulnerability. As far as we know knowledge of this vulnerability is not being used in current attacks.