Message-ID: <403139EF.5040204@coresecurity.com>
Date: Mon, 16 Feb 2004 18:45:19 -0300
From: Ivan Arce <ivan.arce@...esecurity.com>
To: bugtraq@...urityfocus.com
Cc: john_compton24@...oo.com
Subject: Re: Misinformation in Security Advisories (ASN.1)


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@...esecurity.com
www.coresecurity.com

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

Powered by blists - more mailing lists