Home page logo
/

fulldisclosure logo Full Disclosure mailing list archives

Re: Re: Openssl proof of concept code?
From: Joe Fox <jfox () nsec net>
Date: Wed, 14 Jan 2004 16:00:27 -0500

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 () 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

-- 
Joe Fox, CCSA
Network Security Corp
http://www.nsec.net
716.692.8183

Attachment: signature.asc
Description: This is a digitally signed message part


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]