BUGTRAQ ARCHIVE
[ Message Index ] [ Thread Index ] [ Reply ]
[ prev Msg by Date ] [ next Msg by Date ]
To: BugTraq
Subject: Misinformation in Security Advisories (ASN.1)
Date: Feb 16 2004 5:47PM
Author: John Compton <john_compton24 yahoo com>
Message-ID: <20040216174728.35445.qmail@web41311.mail.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/bug...04-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/bug...03-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/bug...03-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.
http://taxes.yahoo.com/filing.html___________________________________________________________________
What do you guys think ???
