Misinformation in Security Advisories (ASN.1)

[John Compton]

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/archiv...4-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/archiv...3-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/archiv...3-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

[Simon Brady]

On Mon, 16 Feb 2004, John Compton wrote:

> 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.

With all due respect, doesn't your argument for this claim boil down to "I
can't see a way to exploit it therefore it can't be exploitable?". This is
hardly a compelling case for sysadmins not to patch, particularly when
we're hearing other self-proclaimed experts contradicting your claim.

Maybe you're right, but I would be professionally negligent to leave my
employer's systems unpatched based on the case you've presented. My job is
to minimise risk to our operations and maximise confidence in the
integrity of our systems: I'm not about to wait to be compromised so I can
say "oh look, it was exploitable after all - I guess patching is justified
now".

Like it or not, our line of work is all about dealing with uncertainty and
making tough calls based on insufficient evidence. I too would like to see
a single, clearly authoritative advisory on any given security issue, but
that doesn't seem likely out here in the real world.

--
Simon Brady mailto:simon.brady@otago.ac.nz
ITS Technical Services
University of Otago, Dunedin, New Zealand

[evol@ruiner.halo.nu]

> 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.
This problem has been solved in several other sectors of buisness. If
you're relying on contractual statements to be valid in court you should
rely on an attorney. You will feel more secure if your attorney has a
good track record, and is respected by peers of both the attorney and
corporations such as yourself. You can't be 100% sure that everything's
going to hold up until you go to trial. The same is true with software
vulnerabilities. Any researcher who's worth his salt has been up against
software that has an error condition whose parameters are not straight
forwardly exploitable yet has found a way to exploit it. I am aware of
two or three organizations that are in the top of the game with respect to
this type of information and if I could speak openly about such
organizations a lot of the information I have would suprise you. Not all
top 5 security corporations are what their websites/client lists would
make them out to be.

> You are likely not going to see any more than the DoS
You just had to use the term likely which softens the impact of this
sentence. Rightly so too. You have not thoroughly investigated all of
the attack vectors and the memory layout of each process, and the
internals of the functions in question, etc. When it gets down to it,
proving something isn't exploitable can be quite like mathematically
proving an operating system is secure. As I said previously, there are
some vendors who you can trust with their opinion to a sound level and
some who are snake oil.

Regards,
Evol

[Ivan Arce]

In the recent and not-so-recent past I've seen claims of
non-exploitability of several discovered vulnerabilities
without actual facts to support them. A recent private email
discussion of this matter as well as the public post to this list
motivated me to reply with some thoughts on the issue.

While I understand the attempt to mitigate the spread of
fear, uncertainity and doubt about newly disclosed vulnerabilities
and the cost of massive deployment of patches across
an organization's network I also believe that as security
practitioners it is our job and our responsability to excercise
extreme caution before making blunt statements about the
exploitability of any given vulnerability. History has
demostrated that bugs thought not to be exploitable turned
demostrably so after a period of time ranging from a few
hours to a few months. This applies to all past and current
popular operating systems, including Windows, Linux, Solaris,
the BSD variants (including OpenBSD) and all other UNIX flavors.

It is easier to demostrate that a vulnerability is exploitable
than to demostrate the opposite. For the former the first
proof of concept exploit code will suffice. For the later
an in-depth analysis and public scrutiny of results is necessary,
as well as complete awarness of the state of the art in exploit
writing techniques and *even then*, there will be no hard proof
that a given bug can not be exploited...ever.

It is my intent to steer away from the full/partial/none disclosure
discussion often seen in this and other lists and not to debate the
benefits and drawbacks of publishing proof of concept code but I would
simply point out that in the absense of PoC either you:

1. Assume that a complex vulnerability is exploitable ONLY if
you see proof of concept code and therefore when in doubt always
ask or wait for PoC to be publicly available, or
2. Trust the analysis and report of a third party (vulnerability
researcher, vendor, reporter, collegue, friend, barman or
favourite pet). In the end this is a matter of where do you
place your trust.

You can't have it both ways.

A third option would be to actually do the complete research yourself
and come to verifyable and reviewable conclusions before emitting
opinion. Mind you, this is *also* costly and time consuming, sometimes
even more than just deploying patches, depending you organization's
infrastructure and willingness to assume risk.
As obvious as it is, many people seem to forget that vulnerability
research and exploit writing in a professional manner is not free,
someone is actually paying for it.

Personally, I tend to think that ALL vulnerabilities are exploitable
unless sufficient proof of the opposite has been given and carefully
scrutinized. I find this more in-line with my bias towards
adopting practices similar to what I learned about modern science during
my years at school. Even then, I will STILL have doubt about my judgement,
call me paranoid if you wish or call me humble, I do think of the
posibility of someone smarter than me finding a way to exploit a
vulnerability that I could not exploit myself.
I would rather err on the safe side than provoke a disturbingly false
sense of security on the people tha value my opinion.

With regards to the specifics of the ASN.1 vulnerability and the
statements on eEye's advisory, I have no reason to believe that
claims of exploitability are false, let alone purposely false or part
of a deliberate missinformation campaign.

> 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?
>

As I said, in the end, when no actual proof either way is
available, it becomes a matter of who do you trust most.
Apparently some of your customers choose to trust publicly
disclosed information and the analysis of eEye or at least
facing doubt decided to take the safe option, more expensive than
sitting on the bug and doing nothing but definately less expensive
than having to fix things iff and when the next worm/virus/etc hit them.

> 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

Erhm, note also that you are attributing intent to the
alleged missinformation in eEye's advisory. I sincerely
hope you understand the implications of such statement.

I have no affiliation whatsoever with eEye but I must admit
that I am biased in this debate: I work for a company that
has been doing vulnerability research and exploit development as
part of its core business for several years and I am privvy to
the vuln. researcher end of this discussion.

-ivan

---
To strive, to seek, to find, and not to yield.
- Alfred, Lord Tennyson Ulysses,1842

Ivan Arce
CTO
CORE SECURITY TECHNOLOGIES

46 Farnsworth Street
Boston, MA 02210
Ph: 617-399-6980
Fax: 617-399-6987
ivan.arce@coresecurity.com
www.coresecurity.com

PGP Fingerprint: C7A8 ED85 8D7B 9ADC 6836 B25D 207B E78E 2AD1 F65A

[Steven M. Christey]

Based on our experiences in CVE, many advisories frequently have (a)
incomplete, (b) inaccurate, or (c) inconsistent information.

To use the eEye / ASN.1 issue as a *single* example of many that I run
across:

- eEye published 2 advisories that each said there were "multiple"
integer overflows

- Microsoft advisory MS04-007 says that there is "a" security
vulnerability, which could be interpreted as saying there is one
bug

- Microsoft's advisory also calls it a "buffer overflow" and there
is no mention of "integer overflow."

One might reasonably ask:

- did Microsoft fix all 4 (or more) bugs? Or, since they fixed a
"buffer overflow," did they fix something completely different?

(an email to Microsoft confirmed that in fact the 4+ bugs were
fixed in MS04-007; but now you must decide if you trust *my*
claim).


In this case, since we had a well-regarded party (eEye) release
vulnerability information on the same day as a Microsoft advisory that
credited them, we might be able to "reasonably assume" that both
parties are talking about the same issue/issues. One might resolve
the discrepancy terminology by recognizing that terminology in
vulnerability research is a moving target. Currently, it lacks the
extra precision that is required to properly distinguish between
closely related bug types. For example, I think the term "buffer
overflow" these days is applied to somewhere between 5 and 10 "bug
types" or attack vectors; it's not just "classic buffer overflow"
anymore. "Directory traversal" is another example of an
overloaded/imprecise term.

Regarding the assessment of the "exploitability" of an issue, as
discussed by Ivan Arce: an approach that is chosen by some vendors is
"if it's a buffer overflow, then we treat it as if it's exploitable."

A final note on buffer overflows and security advisories. I've seen a
number of advisories that *claim* a buffer overflow because the
researcher could send a long input to cause a process to be crashed.
But a null dereference also causes a crash. Some non-zero number of
claimed overflows may really be null dereferences or other such
problems, especially as programmers learn to identify "invalid input"
but forget to properly handle the resulting error condition.

- Steve