Re: RE: Microsoft silently fixes security vulnerabilities

[Bryan Burns <bburns () juniper net>]

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" <smanzuik () eeye 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")