RE: [Full-Disclosure] Re: Full Disclosure != Exploit Release

Date: 01/30/03

  • Next message: Jouko Pynnonen: "Re: [Full-Disclosure] Apache Jakarta Tomcat 3 URL parsing vulnerability"
    Date: Thu, 30 Jan 2003 11:31:36 -0000

    > -----Original Message-----
    > From: Blue Boar []
    > Sent: 29 January 2003 21:20
    > To: Paul Schmehl
    > Cc:
    > Subject: Re: [Full-Disclosure] Re: Full Disclosure != Exploit Release
    > Paul Schmehl wrote:
    > > I've read this mantra over and over again in these
    > discussions, and a
    > > question occurs to me. Can anyone provide a *documented*
    > case where a
    > > vendor refused to produce a patch **having been properly
    > notified of a
    > > vulnerability** until exploit code was released?
    > It might not meet your exact criteria, but here's one I recall:
    > On Win9x, if you share out a printer, it creates a printer$
    > share which
    > points to your system directory (read-only, of course.) The
    > purpose is so
    > that other Win9x boxes can auto-download drivers when they
    > connect to the
    > share. It was pointed out to Microsoft that there is
    > potentially all kinds
    > of interesting info that can be had by an attacker.
    > Microsoft decided it
    > wasn't important to fix.
    > A bit after this was under public discussion, I attended the first
    > NTBugtraq conference/party thingy. A couple of the Microsoft
    > security guys
    > were there, and we got to discussing it. I asked if they
    > planned to fix
    > it, they said no. They said there's nothing exploitable. I
    > pointed out
    > that I could go through the system directory and determine
    > things like
    > exact patch levels, software installed, etc... They said they
    > didn't think
    > it was important enough. The fix would have been to create another
    > directory for printer drivers, and share that out instead.
    > The MS security guys basically said that if someone could
    > demonstrate a
    > significant problem, they'd take another look at it. In
    > other words, show
    > them an exploit, or they wouldn't fix it. Everyone knew it
    > was risky, and
    > just waiting for someone to come up with an interesting use
    > for the hole.
    > It was never patched (AFAIK), and that was several years ago.
    > BB

    On a related note, at the Infosec show 2000 in London I asked the Microsoft
    representative in a public forum on security whether they would be fixing a
    specific bug. The question was whether they would fix the Lan Manager hash
    for encryption on Windows 95 and 98 machines that make it easy to crack
    passwords. The response was astonishing. He said that this was 16bit code,
    and they wouldn't be fixing it as they are concentrating on supporting 32bit

    Lots of businesses use Windows 95 and 98 machines without being aware how
    utterly insecure they are. When a vendor is publicly asked about fixing a
    known bug and the response is that we know about the bug but aren't fixing
    it (even though the affected product is still supposedly supported), what is
    a user supposed to do?

    Exploit code has its place in waking vendors up to issues. In the above case
    , you can buy a password cracker that makes use of this bug.

    John Airey, BSc (Jt Hons), CNA, RHCE
    Internet systems support officer, ITCSD, Royal National Institute of the
    Bakewell Road, Peterborough PE2 6XU,
    Tel.: +44 (0) 1733 375299 Fax: +44 (0) 1733 370848

    Nearly everything we believe is second hand. For example, less than 500
    people have seen the Earth from space, yet the majority of people believe it
    is round (OK pedants, an oblate sphere).


    NOTICE: The information contained in this email and any attachments is
    confidential and may be legally privileged. If you are not the
    intended recipient you are hereby notified that you must not use,
    disclose, distribute, copy, print or rely on this email's content. If
    you are not the intended recipient, please notify the sender
    immediately and then delete the email and any attachments from your

    RNIB has made strenuous efforts to ensure that emails and any
    attachments generated by its staff are free from viruses. However, it
    cannot accept any responsibility for any viruses which are
    transmitted. We therefore recommend you scan all attachments.

    Please note that the statements and views expressed in this email
    and any attachments are those of the author and do not necessarily
    represent those of RNIB.

    RNIB Registered Charity Number: 226227

    Full-Disclosure - We believe in it.