bugtraq - Re: 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-prev] [day] [month] [year] [list]

Message-ID: <20040114192956.98235.qmail@web20803.mail.yahoo.com>
Date: Wed, 14 Jan 2004 14:29:56 -0500 (EST)
From: Michael Iseyemi <michaeliseyemi@...oo.ca>
To: "Lachniet, Mark" <mlachniet@...uoianet.com>, cisspforum@...oogroups.com,
   bugtraq@...urityfocus.com, pen-test@...urityfocus.com,
   full-disclosure@...ts.netsys.com
Subject: Re: Openssl proof of concept code?


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