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  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]
Date: Wed, 14 Jan 2004 14:29:56 -0500 (EST)
From: Michael Iseyemi <>
To: "Lachniet, Mark" <>,,,,
Subject: Re: Openssl proof of concept code?


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.


 --- "Lachniet, Mark" <>
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:
> and
>  It
> was stated that
> these flaws were found using a test suite from NISCC
> (
> 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!

Full-Disclosure - We believe in it.

Powered by blists - more mailing lists