From: jfox at nsec.net (Joe Fox)
Subject: Re: Openssl proof of concept code?

Michael --

If that's the case, then why even mention anything?  Unless there is an
openssl exploit that you can disclose.

Mark -- 

Checkout http://www.packetstormsecurity.nl and search for openssl.  I
believe that you should be able to find some proof of concept code
there.

Joe

On Wed, 2004-01-14 at 14:29, Michael Iseyemi wrote: 
> 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@...uoianet.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

-- 
Joe Fox, CCSA
Network Security Corp
http://www.nsec.net
716.692.8183
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20040114/72dcb26b/attachment.bin

Powered by blists - more mailing lists