OS: Windows, but I think it is a cross-platform bug.
Version: 0.9.6g
In the following function which is called from
PKCS7_sign, if the source text contains a line of text
which is exactly a mutiple of MAX_SMLEN-2 characters
long and has a CRLF line ending, then the gets call
will return a buffer which ends with just a CR, and
then on the next call a line that contains just an LF,
which will result in two CRLF pairs being put into the
output.
A harmless bit of buggy coding is also present. The
value of len is not checked in the inner while loop.
Any line which only contains CR or LF characters will
cause len to go to 0, and the memory location
linebuf[-1] will be read. Its extremely unlikely that
the value at that location is a CR or LF, so usually
the loop terminates anyway. But, its not nice to go
out of bounds, and I imagine memory protection faults
could be triggered on some platforms.
This only affects callers who do not pass PKCS7_BINARY
in the flags parameter (our work-around was to
normalize the line endings ourselves and then pass
PKCS7_BINARY).
/* Copy text from one BIO to another making the output
CRLF at EOL */
int SMIME_crlf_copy(BIO *in, BIO *out, int flags)
{
char eol;
int len;
char linebuf[MAX_SMLEN];
if(flags & PKCS7_BINARY) {
while((len = BIO_read(in, linebuf, MAX_SMLEN)) > 0)
BIO_write(out, linebuf, len);
return 1;
}
if(flags & PKCS7_TEXT) BIO_printf(out, "Content-Type:
text/plain\r\n\r\n");
while ((len = BIO_gets(in, linebuf, MAX_SMLEN)) > 0)
{
eol = 0;
while(iscrlf(linebuf[len - 1])) {
len--;
eol = 1;
}
BIO_write(out, linebuf, len);
if(eol) BIO_write(out, "\r\n", 2);
}
return 1;
}
--Peter Lincroft
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus – Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
