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" <[EMAIL PROTECTED]> 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
