Hello all, I apologize if this information has been discussed or is publicly available, but I haven't been able to find much.
Along the same lines as the message quoted below, I was hoping to get a little bit more information about what exactly the ssltest.nasl plugin does. I'm not convinced that every vendor has "come clean" about their reliance on the openssl code base (a certain SSL VPN product that I'm analyzing comes to mind). However, since the test suite that was used to find the bugs, as noted in: http://www.openssl.org/news/secadv_20031104.txt http://www.openssl.org/news/secadv_20030930.txt doesn't seem to be publicly available, I am not entirely confident that I'm analyzing things properly. If the group might indulge me: 1) Is the ssltest.nasl plugin reliant on identifying openssl via the HTTP server header? Will it still run if someone intentionally modifies the header to hide its version, etc.? 2) Does the test actually test for all three of the original bugs, CAN-2003-0545, CAN-2003-0543, and CAN-2003-0544 as well as the later bug from November CAN-2003-0851? (I get no grep hits on the latter CAN in my plugins directory) 3) Is the client cert noted in ssltest.nasl actually a copy of a client side certificate that has bad ASN.1 encoding? If yes, might it be possible to paste this into a PEM file such as might be used by stunnel in order to do manual testing? 4) Is there another, perhaps manual, way to determine the SSL version or code base of a device from a "black box" perspective? If there is no HTTP header, how might someone go about fingerprinting the service? Thank you for your time and consideration, Mark Lachniet > > On Jan 8, 2004, at 12:16 PM, Axel Thimm wrote: > >> On Mon, Jan 05, 2004 at 04:14:47PM -0700, Justin R. Northcraft wrote: >>> I have a Fedora system configured with Nessus and OpenSSL. I had >>> installed a >>> base install of fedora loaded openssl (0.9.7c) then Nessus (2.0.9). >>> There were no problems during any of the installations. >>> >>> When I run a Nessus scan against this box the Nessus demon reports a >>> vulnerability (see below). I'm posting this question because I have >>> performed the same installation procedures with RedHat 8 and 9 and the >>> vulnerability does not exist. It seams that the installation of >>> openssl may >>> not have been placed in the correct file structure???? Any help in >>> finding >>> the cause of this and correcting the vulnerability is greatly >>> appreciated. >>> >> >> Red Hat ships openssl 0.9.7a with patches for closing this security >> bugs: >> >> * Wed Sep 24 2003 Nalin Dahyabhai <[EMAIL PROTECTED]> >> >> - add security fixes for protocol parsing bugs (CAN-2003-0543, >> CAN-2003-0544) >> and heap corruption (CAN-2003-0545) > > It *seems* that they did not fix the "read the certificate the remote > host is sending me, > even if I never requested it" bug, which did not get a CAN candidate > associated > to it, that's too bad. > > > -- Renaud > > _______________________________________________ > Nessus mailing list > [EMAIL PROTECTED] > http://mail.nessus.org/mailman/listinfo/nessus > _______________________________________________ Nessus mailing list [EMAIL PROTECTED] http://mail.nessus.org/mailman/listinfo/nessus
