Full Disclosure: Re: Openssl proof of concept code?

[Michael Iseyemi <michaeliseyemi () yahoo ca>]

Mark,

There actually is a succesful demo of this exploit
that I am aware of. I'm however not at liberty to 
divulge this as it is a littlebit convoluted and also
includes integration testing and efforts between
several components of a PKI.

Thanks,
Michael  

 --- "Lachniet, Mark" <mlachniet () sequoianet com>
wrote: > Please excuse the cross-post, and please
forgive me
> if I am missing
> something that I should have found through
> conventional sources.
>
> A few months ago, there were issues with the openssl
> code base, as noted
> on bugtraq and in the following URLs:
> http://www.openssl.org/news/secadv_20031104.txt and
> http://www.openssl.org/news/secadv_20030930.txt.  It
> was stated that
> these flaws were found using a test suite from NISCC
> (www.niscc.gov.uk).
> However, this toolkit is apparently not publicly
> available (you need to
> be a SSL developer?), and I find no record of a
> proof of concept test
> for this vulnerability.  Given that a large number
> of vendors use this
> code base in their products it is no surprise that
> there are a lot of
> products that needed updates.  However, I'm not
> convinced that every
> vendor has actually "come clean" about their
> vulnerability to these
> problems.  
>
> Is anyone aware of a reasonable way for an analyst
> to definitively
> demonstrate if the vulnerabilities exist in a
> particular product?  Since
> some of the bugs deal with bad client certificates,
> some might be as
> easy as getting a copy of a "bad" client certificate
> and connecting to
> the server using a program such as stunnel, but I
> have yet to see
> anything about this.  Alternately, has anyone
> written a good program to
> remotely identify what SSL codebase is in use, other
> than looking for it
> in HTTP server headers?  Nessus' ssltest.nasl can
> allegedly distinguish
> between a openssl and MS CryptoAPI or Novell, but
> this isn't really
> enough in my opinion.  If conventional tools (i.e.
> Nessus and other
> scanners) can't really fingerprint it, how might one
> go a little further
> and determine this from a "black box" perspective? 
> I understand that
> with a good deal of development time and effort,
> this can probably be
> done, but this is probably not realistic for most
> organizations to do on
> their own.
>
> Its been a while now, and responsible vendors should
> have already issued
> patches.  Also, since there is no proof of concept,
> that I am aware of
> anyway, it seems to me that there is still some
> exposure from these bugs
> that people may not be aware of.  It would be nice
> to have a test so
> that people could better gauge their exposure.  Can
> anyone offer a
> reasonable solution to this problem?
>
> Thanks,
>
> Mark Lachniet 
______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca

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