Message-ID: <20040216164223.52416.qmail@web41306.mail.yahoo.com>
Date: Mon, 16 Feb 2004 08:42:23 -0800 (PST)
From: John Compton <john_compton24@...oo.com>
To: bugtraq@...urityfocus.com, full-disclosure@...ts.netsys.com
Subject: Misinformation in Security Advisories (ASN.1)

It seems that misinformation is included in security advisories far too often, and for many different reasons. I'd like to point out a couple examples, and promote discussion as to how this misinformation affects the security community and the non-experts who rely on this information to be valid.
 
First of all, there is good news for those of you out there who are worried about the new ASN.1 vulnerability in Microsoft operating systems. It is NOT exploitable to run arbitrary code in anything approaching a real-world scenario. 
 
You are likely not going to see any more than the DoS exploit that has already come out. For those of you interested in the technical explanation of why, it is included below (it's honestly beyond my complete understanding). Most of the security researchers I've spoken to agree with this assessment and the information below.
 
However, this impact of this misinformation is that many corporations out there spent tens of thousands of dollars (or more) in resources and manpower last week to get this issue fixed enterprise-wide.
 
I work for a start-up security-intelligence vendor, and we warned our customers that this bug was only exploitable as a denial of service, yet many of them were not willing to take the risk that the next Blaster might appear over the weekend, despite our in-depth explanation of why this bug is not exploitable. Why wouldn't they believe us?
 
http://archives.neohapsis.com/archives/bugtraq/2004-02/0293.html
 
In that post to Bugtraq, dated February 10th, Mr. Maiffret claims that Eeye has developed a functional exploit that they used to compromise an IPSec-protected network. Setting aside his claims of "Client side, server side, world wide", he goes on to claim that users are all affected and that they shouldn't even think twice but simply install the patch.
 
For some of our clients, installing the patch means deploying it enterprise-wide across tens of thousands of machines. It means deploying it in test environments before rolling it out on production servers. It doesn't mean just clicking on "Windowsupdate.microsoft.com" or that icon in the system tray. 
 
I think that Mr. Maiffret's inaccurate statements are costly to others. If large enterprises knew that this bug could only be exploited as a denial of service condition, their approach would be considerably different, and their associated costs significantly lower.
 
Sometimes misinformation in security advisories is unintentional, however in this case it appears to be intentionally misleading and I think it's time that someone spoke openly about it. I'm trying to promote discussion about misinformation in our industry, and it's not my intention to directly attack Eeye, however they have done this in the past.
A less blatant example of misinformation in a security advisory, yet one reminiscent of ASN.1, would be:
 
http://archives.neohapsis.com/archives/bugtraq/2003-03/0282.html
 
This bug, as some of you may remember, affected the SunRPC xdr data translation, and could be considered a serious risk to some networks if it allowed remote code execution. Eeye certainly seemed to think that it was:
 
"Severity: 
High (Remote Code Execution/Denial of Service) "
 
When Sinan Eren questioned the exploitability of this issue, there was no response from Eeye:
 
http://archives.neohapsis.com/archives/bugtraq/2003-03/0288.html
 
However, there was still a Cert advisory, and multiple vendor-released advisories, which all stated that this issue might be used to execute arbitrary code. Again, we told our customers about the limited exposure they faced from this issue back in March of last year, yet many of them chose to ignore our advice and agree with the industry consensus of exploitability.
 
For a company that does so much quality vulnerability research and employs many talented people, it's very disappointing to see what honestly can't be characterized as anything but deliberate misinformation. 
 
I'd like to ask someone from Eeye to respond to these claims, but honestly they're not the only security researchers guilty of this.
 
I'd be interested to hear opinions from other perspectives, as I do not do security research nor roll out protection for security bugs for a living.
 
Regards,
John
 
Supporting technical information about ASN.1 vulnerability:
 
The ASN.1 vulnerabilities discovered by Eeye (there were several very similar ones) resulted in a memcpy of 4GB less a few bytes (0xFFFFFFFX) bytes to the process heap. This will quickly corrupt the entire heap and hit a guard page or unpaged address and cause an unhandled exception. When this unhandled exception occurs, application and then OS exception handlers will be called in order to attempt to deal with the protection fault. 
 
These exception handlers, in virtually every Microsoft application, do NOT use the heap since it is not guaranteed to be in a consistent state. This rules out the possibility of simply causing an exception and having the exception handlers traverse the heap and cause an arbitrary memory overwrite leading to code execution.
 
Another possibility for remote code execution would be to trigger a context-switch mid-memcpy which would halt the memory copy operation before it hits an unpaged address. This, if possible, might leave the heap in a corrupted state but allow another thread to access/traverse the heap before the exception occurs. However, Microsoft compilers optimize the memcpy() function call to the REPNE MOVSD instruction. This makes it extremely unlikely, if not statistically impossible, to get a context switch at the right time before an unpaged address is accessed. Once again, this cannot be used to exploit this bug.
 
Another possibility is vectored exception handling, which stores pointers to exception handlers on the process heap. If these exception handlers existed, it would be very viable to corrupt them and have them called when the exception occurred (ala SEH on the stack). However, vectored exception handling was only introduced in Windows XP, and no Microsoft applications use them by default.
 
The final, and equally unlikely possibility, is that an exception occurs but before the exception handler is called another thread accesses the heap. However, the system exception handlers are given higher thread priorities in order to quickly handle a condition that requires immediate attention. As such, the application will always exit before another thread has a chance to access the corrupted heap.
 
The result, quite honestly, is a non-exploitable condition. This issue is limited in scope to a denial of service vulnerability.

(thanks to a friend for this info)


---------------------------------
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online
Content of type "text/html" skipped

Powered by blists - more mailing lists