[Full-Disclosure] 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