bugtraq - Openssl proof of concept code?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <0FD9D979B9535D4890AE309799B6D1E55B9828@lansingemail.seqnt.com>
Date: Thu, 8 Jan 2004 15:46:21 -0500
From: "Lachniet, Mark" <mlachniet@...uoianet.com>
To: <cisspforum@...oogroups.com>, <bugtraq@...urityfocus.com>,
	<pen-test@...urityfocus.com>, <full-disclosure@...ts.netsys.com>
Subject: Openssl proof of concept code?

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