From: Bryan Burns (bburnsjuniper.net)
Date: Fri Apr 21 2006 - 13:33:25 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

What if the vendor disclosed in every patch the maximum severity level of
any vulnerabilities fixed in the patch without disclosing specifics? Would
this be a good middle-ground solution?

For example: Joe Researcher discovers a "medium" severity issue in Foo
Corp's MechaFoo�. In the process of resolving this issue the Foo Corp
developers identify a "critical" severity issue and resolve it as well. Foo
Corp releases MechaFoo� v1.01 that contains both security fixes along with a
host of other bug fixes, and prominently in the communication to customers
is the sentence "This patch contains a fix or fixes for security issues with
a maximum severity of "critical"."

Is this a sufficient solution to simultaneously provide the poor IT guy with
information for risk assessment purposes while not providing excessive
information that might hasten exploitation?

-Bryan

On 4/20/06 11:39 PM, "Steve Manzuik" <smanzuikeeye.com> wrote:

> Interesting response Ari.
>
> Consider this scenario:
>
> Researcher finds and reports Vulnerability A. It is a remote code
> execution but exploitation of the vulnerability is difficult.
>
> Vendor during their investigation identifies code affected by
> Vulnerability A and also identifies Vulnerability B which is also a
> remote code execution but much easier to exploit. Both A and B exist in
> the same function.
>
> Vendor says nothing about Vulnerability B but patches both in their
> release and rates it Critical.
>
> Researcher releases advisory on Vulnerability A and agrees with others
> who point out the difficulty in reliable exploitation.
>
> Corporation observes that Vulnerability A is difficult to exploit and
> therefore lowers their internal risk rating and simply schedules the
> patch for the next available change window. Signature based protections
> are updated and false sense of security sets in... Beers are drank
> everywhere.
>
> Attacker (or anyone for that matter) reverse engineers the patch,
> identifies Vulnerability B and realizes that it is much more reliable to
> exploit than the publicly disclosed vulnerability.
>
> Corporation gets owned. Hung over IT guy develops an ulcer if he didn't
> have one already.
>
> Anyone who has spent anytime as the "IT guy" has learned the hard way to
> not explicitly trust the os vendor. Why do we recommend the best
> practice of setting up test beds for patches? Why do we recommend
> proper change control and change management --- because our operating
> system vendors have steered us wrong enough in the past to cause us
> considerable job related stress.
>
> I would love to see some stats from others on here on how long it takes
> you to reverse a patch (use MS as an example if you want) and identify
> the vulnerability. I do remember vaguely some numbers tossed out by
> Dave... But that was during much beers at the first PacSec. :P
>
>
> Cheers;
>
> Steve Manzuik
> (thanking some random religious symbol that he isn't an "IT guy")

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]