From: Pusscat (pusscatgmail.com)
Date: Fri Apr 21 2006 - 10:10:02 CDT

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

As for time to reverse a given MS patch to find a specific vuln, it's
usually less than 2 hours from release to PoC. Most of the time, patch day
turn around can be under 24 hours for developing a PoC for every vuln
released.

This is just an average though. Sometimes (a few lately come to mind) MS has
produced terrible patches that don't give anything away, and don't really
address the actual problem, whereas other times they practically hand you
the vuln gift wrapped in their FAQ or mitigations.

On 4/21/06 2:39 AM, "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")

~ Puss

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