[Full-Disclosure] RE: [kinda-but-not-really-Full-Disclosure-so-we-feel-warm-and-fuzzy] Re: <to various comments>EEYE: Microsoft ASN.1 ...

From: Brett Moore (brett_at_softwarecreations.co.nz)
Date: 02/12/04

  • Next message: iDefense Labs: "iDEFENSE Security Advisory 02.11.04: XFree86 Font Information File Buffer Overflow II" 
    To: "Drew Copley" <dcopley@eeye.com>
Date: Thu, 12 Feb 2004 23:11:51 +1300

    Its great...

    With the MS patching been relegated to monthly, it means we only have
    to put up with this crap once a month... but man it drags on.. and on...
    and on....

    Everyone has an opinion, agreed. But its not like those same opinions
    are not shared by others.. Some would like full disclosure, because its
    interesting and inciteful... And knowing how to exploit one bug can lead
    to the discovery of similar bugs... But then we may as well start discussing
    the fact that if researchers didn't find and disclose bugs, then would the
    'bad guys' really find them... Maybe, maybe not.. But I'd bet top $ that
    there are 'bad guys' out there finding these things for a reason and not
    disclosing. Because said 'bad guys' are not part of what we call the
    'security community'...

    Because it must be realised that as soon as a patch and or advisory is
    released
    there are global teams of people working to discover and exploit said bug.
    I'd take a stab and say US, Chinese, Russian, Middle eastern and possibly
    even outerspace 'spy' agencies as well as organised crime and mafia right
    down
    to 'hacking' groups, uni students and other security enthusiasts.

    It's pretty obvious with the latest releases from ngssoftware that they
    are not providing any details... And eEye it seems is no longer providing
    step by step intructions... Thats their choice. In fact we should be
    lucky that they provide any details, or would you prefer that they kept
    quiet and MS just released patches for 'undisclosed' problems...

    Or is there a real need for a 'real-full-disclosure' list where membership
    is restricted and details are shared (if it doesn't already exist)...
    If that happened then ppl that don't like it should not subscribe, and then
    they can feel better... Ignorance is bliss (thats a phrase not something
    directed at anyone, in fact I sometimes prefer bliss).

    > Administrators don't need this crap to fix their boxes, they simply need
    Some do, some don't.. But all developers of internet facing applications,
    sure as hell better care about this stuff.

    > running. The average worm writer is not competent enough to reverse
    > engineer a ms patch to find the changed code and produce a working
    Perhaps,.. Code red was intense in the 'features' that it used and even the
    method of exploiting the bug..
    And wasn't it the peeps from x-focus that published details of the RPC Dcom
    bug, after LSD refused to release details....

    To quote a kiwi drinking at a bar 'we should just say that there are no
    more bugs, and that all computers are secure'....

    And the rapping and other humor in advisories.. So what.. Who decided that
    this industry couldn't be fun... Just because ppl are highly intelligent
    and tuned into security research, doesn't mean they are not allowed to have
    a laugh...

    >The strategy is simple, patch, patch, patch.
    Yup. Because with or without 'step by step' deatils, the timeframe is down
    to less than 60 days, if not 30.

    -----Original Message-----
    From: full-disclosure-admin@lists.netsys.com
    [mailto:full-disclosure-admin@lists.netsys.com]On Behalf Of Paul Tinsley
    Sent: Thursday, February 12, 2004 7:57 PM
    To: Drew Copley
    Cc: full-disclosure@lists.netsys.com
    Subject: Re: [Full-Disclosure] Re: Re: <to various comments>EEYE:
    Microsoft ASN.1 ...

    Drew Copley wrote:

    >Without replying to each troll, individually, I thought maybe some
    >people would like to see some answers to some notes.
    >
    >
    Most of these are from me, so I will personally respond to those that
    apply. And believe it or not, this is not a troll, I really wanted to
    see people's viewpoints on this subject. Thats the neat part about us
    not all working at the same company or striving for the same goals, we
    have different viewpoints. Asking for enumeration of those CAN be for
    purposes other than trolling, if I wanted to troll I would just reload
    the slashdot main page till a new story came out and mention something
    about hot grits and first post.

    >These are my own comments, I speak for myself.
    >
    >Question: "Why release all of the details"
    >
    >
    This statement is not an accurate paraphrase, I didn't say why release
    them all. I said why release them all on day 0 of the patch release.

    >Answer: Polls show this is what administrators what. This is one reason
    >we do this. Another reason we do this is simple, we use the details
    >ourselves. We use the details to create signatures for our vulnerability
    >assessment tool and firewall. Security administrators then download
    >these signatures and use them to check for patches or to protect systems
    >which can not yet be patched.
    >
    >
    Administrators don't need this crap to fix their boxes, they simply need
    the exploit vectors, the possible mitigation steps, and the potential
    severity of the vulnerability. No sysadmin should have time, nor care
    about the call made to localalloc, the decoder functions it effects,
    etc... The pieces that are needed to make a threat assessment and
    develop a mitigation strategy, IMHO, are all in your bulletin, and
    contained in these sections: Systems Affected, Services Affected,
    Software Affected, Description, Severity. From that it's pretty obvious
    how bad this one can be, knowing that we can't make people stop using
    Outlook in a corporate environment, or stop using Internet Explorer to
    go to several popular sites, or any of the other numerous 3rd party apps
    that are affected by this. The strategy is simple, patch, patch, patch.

    That is something that takes time in a large enterprise where you have
    to worry about the effects it will have on day to day business. You
    can't just flip a switch and deploy vendor patches the day they come
    out, I think we all know that Microsoft patches do have bugs from time
    to time and knowing how these will affect your "officially supported"
    corporate applications is important. Reducing the safe margin of time
    that one has to do that IS a problem in my eyes.

    >It does not matter if it is eEye you are talking about in this scenario,
    >or one of our competitors. This is the "behind the scenes" picture of
    >what happens when a patch is released.
    >
    Show me one competitor that releases such detail at day 0 of patch release.

    >
    >When we - or our competitors - do not have full details on a
    >vulnerability, we have to reverse engineer the patch to do so. And, we
    >all do this.
    >
    >
    I am sorry that you have to do what you get paid to do. Would it be an
    unreasonable thing to consider a gentlemans agreement between assessment
    vendors to share network behavioral fingerprints for vulns such as
    these? The finder still gets credit, the vendor still gets to help his
    clients, and next time he isn't the one to find it he still gets to help
    his clients. Seems like a decent deal to me...

    >So, people complaining about us releasing all of the details... They
    >simply are ignorant of what must be done in this process. They like to
    >scream and shout about how a worm will be coming and such, nevermind
    >that they don't even understand our advisories in the first place.
    >
    >
    >
    Don't hold yourself in such high reguard to believe that people the
    likes of me cannot comprehend your bulletins, you would be wrong.

    >And if this does not make it all incredibly clear, let's spell it out
    >for them: we can reverse engineer the patches and have to... If virus
    >writers want to, they can, too, as well.
    >
    >
    Tell me that you have seen complex worms recently? Most if not all of
    them are cobbled together from exploit code the author found on some
    leet mad phat message board and added in some visual basic or visual c
    to tie the whole thing together to get their spam gateway up and
    running. The average worm writer is not competent enough to reverse
    engineer a ms patch to find the changed code and produce a working
    exploit from it.

    [ .. snip .. ]

    >Question/Comment: "What is this thing with rapping?"
    >
    >Answer: We have had these kinds of things in our advisories since we
    >started releasing them way back when.
    >
    >Derek, at times, feels the need to bust a rhyme.
    >
    >You are not going to stop him.
    >
    >
    Don't plan to, but perception is reality, if you look like a script
    kiddy, it's going to be really really hard for a large company to write
    you a fat check. I don't know if you noticed but the day of cutsie
    titles are playful antics are a thing of the past, most people have
    gotten back to real business by now.

    >And, I have tried. Knives, ropes, pits, strangulation. He is quite wily.
    >
    [ .. snip .. ]

    _______________________________________________
    Full-Disclosure - We believe in it.
    Charter: http://lists.netsys.com/full-disclosure-charter.html

    _______________________________________________
    Full-Disclosure - We believe in it.
    Charter: http://lists.netsys.com/full-disclosure-charter.html

  • Next message: iDefense Labs: "iDEFENSE Security Advisory 02.11.04: XFree86 Font Information File Buffer Overflow II"

    Relevant Pages

    • Re: thoughts on kernel security issues
      ... having two independent patches that fix them is STILL better. ... Take it from me - I've been reviewing patches for _way_ too long. ... have a clue ("try reverting that one patch") or you can do things like ... Which is why lots of small patches usually have _different_ bug behaviour ...
      (Linux-Kernel)
    • Re: commit a802dd0e breaks console keyboard input
      ... That way we should know if it really comes from the moved init ... call or if it is some other weird bug. ... reports if the stop_machine patches would be broken. ... Yes your second patch fixes the keyboard problem, ...
      (Linux-Kernel)
    • Re: [git pull] core fixes
      ... fix stack and rcu interaction bug in ... I'm still not 100% sure that I have this patch right... ... been due to some other problem or a different bug in the new call ... other patches, then the incremental patch to fix it. ...
      (Linux-Kernel)
    • Re: Old -rt patches
      ... way and installed the -rt patch, which includes the -hrt patches, as far as I understand. ... I'm not saying that it's impossible for the bug to be in my app, but the app is small enough that I'm fairly confident there's no problem there. ...
      (Linux-Kernel)
    • 9_Recommended error codes (specifically return code 5)
      ... * "return code 2" indicates patches are already installed. ... * "return code 25" means a patches requires another patch that is not yet installed. ... With or without using the save option, the patch installation process ... Installing 114008-01... ...
      (SunManagers)