Michael -- If that's the case, then why even mention anything? Unless there is an openssl exploit that you can disclose. Mark -- Checkout http://www.packetstormsecurity.nl and search for openssl. I believe that you should be able to find some proof of concept code there. Joe On Wed, 2004-01-14 at 14:29, Michael Iseyemi wrote: > 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 -- Joe Fox, CCSA Network Security Corp http://www.nsec.net 716.692.8183
Attachment:
signature.asc
Description: This is a digitally signed message part