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
Current thread:
- Openssl proof of concept code? Lachniet, Mark (Jan 08)
- Re: Openssl proof of concept code? Bram Matthys (Syzop) (Jan 08)
- Re: Openssl proof of concept code? John Lampe (Jan 08)
- Re: Openssl proof of concept code? Michael Iseyemi (Jan 14)
- Re: Re: Openssl proof of concept code? Joe Fox (Jan 14)