Misinformation in Security Advisories (ASN.1)

[John Compton <john_compton24 () yahoo com>]

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