mailing list archives
Re: OpenSSL 0.9.8h available.
From: jah <jah () zadkiel plus com>
Date: Sun, 01 Jun 2008 23:11:19 +0100
On 01/06/2008 22:17, Fyodor wrote:
Thanks for testing, Jah. Did you check if the previous version works
on that new build machine? Kris' SSL update seems to work on my
Windows XP SP2 box. But I'll release 4.65 without the upgrade to
allow for further testing. The OpenSSL security issues don't have any
code execution risks AFAICT. It looks like, at worst, a malicious SSL
server could possibly cause Windows Nmap to crash if Nmap tries
version detection against that server.
I've been fiddling with OpenSSL and did manage to get it to build linked
statically against MSVCR80 by manually changing the /MD directive to /MT
in ms\ntdll.mak right after running ms\do_ms. Passing the directive to
Configure: perl Configure VC-WIN32:/MT --prefix=C:/OpenSSL/build didn't
work; it reverted to /MD.
There is a warning in INSTALL.W32:
"One final comment about compiling applications linked to the OpenSSL
library. If you don't use the multithreaded DLL runtime library (/MD
option) your program will almost certainly crash because malloc gets
confused -- the OpenSSL DLLs are statically linked to one version, the
application must not use a different one. You might be able to work
around such problems by adding CRYPTO_malloc_init() to your program
before any calls to the OpenSSL libraries: This tells the OpenSSL
libraries to use the same malloc(), free() and realloc() as the
application. However there are many standard library functions used by
OpenSSL that call malloc() internally (e.g. fopen()), and OpenSSL
cannot change these; so in general you cannot rely on
CRYPTO_malloc_init() solving your problem, and you should consistently
use the multithreaded library."
The 0.9.8g build was also dynamically linked and also doesn't work on a
clean XP SP2 install.
I think it's likely that only those without MSVCR80 are going to have
problems, but nmap won't work at all in these cases. The question is
what to do for those people.
Given that nmap itself is linked statically (do correct me if I'm wrong)
it probably wouldn't be a problem if OpenSSL was built for Nmap on the
same machine using the same runtime.
There is one other consideration I think it prudent to mention which
relates to nse_bitlib bit.dll which also isn't statically linked.
Running a script scan on a machine without MSVCR80 results in:
SCRIPT ENGINE: error while initializing script rules:
error loading module 'bit' from file 'C:\Program
Files\Nmap\nselib-bin/bit.dll': system error 14001
which is a side-by-side config issue and creates an entry in the system
log to the effect that Microsoft.VC80.CRT could not be found.
This issue was brought-up before , but I wasn't sure how to
proceed  and never submitted a patch for the fix (I'll submit one
that replaces /MD with /MT in a separate post).
What to do?
Sent through the nmap-dev mailing list
Archived at http://SecLists.Org