Message-ID: <00a201c2c7e9$77b197b0$0100000a@yrpxb5>
From: yossarian at planet.nl (yossarian)
Subject: Fw: Full Disclosure != Exploit Release - No disclosure No Fix

OK - challenge taken

Few from my archives (all a bit older, haven't organised for a few years,
form the time I was editor of a security e-zine)

 October 2001: Bank Of America Online banking software - homebuilt, but
their
 IT dept. is bigger than most software companies:
 https://onlineid.bankofamerica.com/cgi-bin/sso.login.controller local
 caching of user credentials - reported in june, not fixed in October

 October 1999: InoculateIT Agent for Exchange Server
CA was notified in oct 1999 of a way of bypassing attachments scan by
modified SMTP header. In Oct 2000 the finder went public, since it was not
fixed by then.

 October 2000: Novell denies that Netware 5 running native IP displaying
servers, user accounts etc. over port 524 (NCP)  is a security issue. BTW -
On 427 (SLP) you can get all NDS tree info without authentication.

May 2000: Lotus Notes R5 clients  (>R5.0.6)- manipulated digital signature.
The client does not notify if S/MIME messages have been tampered with. Still
not fixed and no formal advisory by October. Lotus had been informed in
various ways, several times.

Does this prove anything? Of course I cannot prove that vender were notified
* properly*, since there is no common definition. The proposed IETF standard
was not adopted. I do remember cases where vendors had no wish to accept
vulnerability notification from not-registered users, or lost the
notification (and were brave enough to admit it). On some software
evaluation projects, I used the info on the vendors handling of security
issues as a thing to take into account before buying the software. I can
tell you that some salespersons out there were not pleased with me. Or some
companies that had already bought certain software..

But the cases above are *documented*.

If I dig deeper, I will find them from most major companies. And many, many
small ones. In nearly every issue of the e-zine,
which ran for 3 years (it was in dutch, and it is not online somewhere) I
had cases of issues where manufacturer did nothing or denied the issue.
Maybe setting up a list with how well sw-vendors handle holes and fixing
might lessen the need to release exploit code.

Why do I get the feeling that we are running around in circles on these
lists? Discussion just don't get settled, and the more experienced people
get tired, and just lurk or leave. Maybe the answer is in the poll
securityjobs ran in 2000, which showed that people working in the IT
security business on average worked in the IT for less than 4 years, and in
security for less than one?

 > > On Wed, 2003-01-29 at 06:13, David Howe wrote:
> >
> > > That is of course your choice. Vendors in particular were prone to
deny
> > > a vunerability existed unless exploit code were published to prove it.
> >
> > 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?
> >
> > Definitions:
> >
> > "properly notified" means that the vendor received written notification
> > at a functional address (either email or snail mail) *and* responded
> > (bot or human) so that the sender knows the message was received.
> >
> > "documented" means that there is proof both of proper notification *and*
> > that a patch was not released in a timely manner
> >
> > "timely" means within two weeks of the notification
> >
> > "vendor" means any company that produces publicly available software -
> > open source or commercial
> >
> > Caveats:
> >
> > You cannot use a case where exploit code was released at the same time
> > the vulnerability announcement was made *or* within two weeks of the
> > announcement (see "timely")
> >
> > I'm not saying this doesn't occur.  Just that it has the smell of urban
> > legend and justification for actions taken.
> >
> > --
> > Paul Schmehl (pauls@...allas.edu)
> > Adjunct Information Security Officer
> > The University of Texas at Dallas
> > http://www.utdallas.edu/~pauls/
> > AVIEN Founding Member
> >
> > _______________________________________________
> > Full-Disclosure - We believe in it.
> > Charter: http://lists.netsys.com/full-disclosure-charter.html
>

Powered by blists - more mailing lists