Home page logo
/

fulldisclosure logo Full Disclosure mailing list archives

Re: Openssl proof of concept code?
From: Michael Iseyemi <michaeliseyemi () yahoo ca>
Date: Wed, 14 Jan 2004 14:29:56 -0500 (EST)

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


  By Date           By Thread  

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