OpenSSL mailserver didn't like the attachment, see
http://www.michaelboman.org/how-to/building-openssl-on-windows for the
previous attached file.
Best regards
Michael Boman
On Mon, Mar 15, 2010 at 6:21 AM, Michael Boman mich...@michaelboman.orgwrote:
Thanks for your input, clarifications inline:
On Fri, Mar 12, 2010 at 12:04 AM, Dave Thompson
dave.thomp...@princetonpayments.com wrote:
-dev added, I think this is actually a bug
From: owner-openssl-us...@openssl.org On Behalf Of Michael Boman
Sent: Monday, 01 March, 2010 11:40
re: crash in BIO_set_fp, on Windows, could it be faq#PROG2?
I am using OpenSSL 0.9.8l from
http://www.slproweb.com/products/Win32OpenSSL.html
I link to these libraries for debugging:
C:\OpenSSL\lib\VC\ssleay32MTd.lib
C:\OpenSSL\lib\VC\libeay32MTd.lib
And these ones for release:
C:\OpenSSL\lib\VC\ssleay32MT.lib
C:\OpenSSL\lib\VC\libeay32MT.lib
I compile the program using the /MT (Release) and /MTd (Debug)
flag
under C/C++ - Code Generation
Aside: all 4 pairs of .lib's in lib\VC (and one in lib) are
exportlibs for the one pair of DLL's, which are actually /MD
but use the applink mechanism, as mentioned in the FAQ, to get
the right CRT -- assuming the EXE correctly compiles applink.c,
and the code you referenced does.
So this should work. And using the corresponding files from
my (DLL) build of 0.9.8m it sort of does (see below), but using
the SL distro I also get a crash. Stepping in the debugger I see
code in SL that is similar but not identical. It appears to be
built with VC++08 or possibly later, in particular for MSVCR90,
while I use (elderly but still functional) VC++6.0 and MSVCRT[d],
and the exit 0xC417 occurs in MSVCR90 appparently below _setmode.
You didn't say what version of VC++ (and CRT) you are using.
I am using VC++ 2008 Express on Windows 7 (64-bit), compiling against
0.9.8m (currently; OP was 0.9.8l). Up-to-date code is available at
http://code.google.com/p/sslscan-win together with required VC++ project
and solution files.
As I mentioned above I am currently using 0.9.8m, which I have compiled
myself using the attached script (place it in OpenSSL source directory)
using the following syntax: vc_build.cmd -d -i
I am now linking to following libs for both debug and release:
C:\OpenSSL\openssl-0.9.8m\lib\libeay32.lib
C:\OpenSSL\openssl-0.9.8m\lib\ssleay32.lib
OpenSSL include files are being picked up
from C:\OpenSSL\openssl-0.9.8m\include and I am now printing
out OPENSSL_VERSION_TEXT to confirm what header files I was building
against.
I believe this is a bug:
bss_file.c file_ctrl() case for SET_FILE_PTR uses UP_fsetmode
not UP_fsetmod so it doesn't uplink when it apparently should;
instead uses direct _fileno and _setmode which faults in MSVCR90.
On (old) VC++6.0/MSVCRT _fileno is inlined and works, and _setmode
sets an error (EBADF) which is ignored, and the mode (bin/text)
set by the app at fopen is apparently left intact (and works OK).
Also looking in the same area:
bss_file.c BIO_new_file() calls *ctrl BIO_C_SET_FILE_PTR with
flags not including BIO_FP_TEXT, which sets binary even if the
call said e.g. w or wt; on Windows this gives poor results
if the output actually is text and needs \n=CRLF translation.
Similarly BIO_{read,rw,write,append}_filename do SET_FILENAME
with flags not containing TEXT. Explicitly calling BIO_ctrl
SET_FILENAME with e.g. BIO_FP_WRITE|BIO_FP_TEXT does work.
And BIO_new_fp() although prototyped as 'close_flag' actually
honors TEXT as well, as documented.
Some other things I noticed in working on this app:
Personally I would do each formatting op once to a membio or
string, and then duplicate the result to stdout and xmlOutput.
That would also avoid this problem, since then the app wouldn't
be using an fpbio for xmlOutput; everything else seems to work.
And I wouldn't indent SO deeply. And I would handle long
serials, as apps/x509.c does, since bigger than 32b are pretty
common and (often spurious) negatives shouldn't be misleading.
And officially WSAStartup should be once per process,
although since about W2k as I recall repeats are benign.
And unextended (insecure) client-initiated renegotiation is
probably -- we hope! -- going to stop working soon.
Logically I think it should work to compile the app /MD with a
new(er) compiler that uses MSVCR90 and thus doesn't need uplink,
or any supported mode(s) and static link (lib\VC\STATIC\various.lib)
against a new-enough library to be compatible (old MSVCRT is not,
it apparently doesn't have some _cookie stuff the SL build wants).
But I'm not in a position to try those out for now.
Thank you so much for the general feedback, it is much appreciated. I will
take note of the suggested improvements and work them in to the application.
Best regards
Michael Boman
--
http://michaelboman.org - Security Blog
