[openssl.org #356] Bug in CRLF translation in PKCS7_sign
[EMAIL PROTECTED] - Fri Nov 22 10:27:16 2002]: 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). Should be fixed no in 0.9.7-stable and 0.9.8-dev. Please check the next snapshot. Steve. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #356] Bug in CRLF translation in PKCS7_sign
In message [EMAIL PROTECTED] on Wed, 4 Dec 2002 20:24:30 +0100 (MET), Stephen Henson via RT [EMAIL PROTECTED] said: rt The existing code could be fixed to handle other cases, for example by rt dumping that BIO_gets() replacing with a BIO_read() loop and converting rt the buffer in place. Alternatively a filter BIO that can handle EOL rt conversion could be written. Hmm, BIO_f_linebuffer() seems to be something to build from. Right now, it's an output-only buffering filter, but can easily be made an input filter as well. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #356] Bug in CRLF translation in PKCS7_sign
In message [EMAIL PROTECTED] on Wed, 4 Dec 2002 20:24:30 +0100 (MET), Stephen Henson via RT [EMAIL PROTECTED] said: rt The existing code could be fixed to handle other cases, for example by rt dumping that BIO_gets() replacing with a BIO_read() loop and converting rt the buffer in place. Alternatively a filter BIO that can handle EOL rt conversion could be written. Hmm, BIO_f_linebuffer() seems to be something to build from. Right now, it's an output-only buffering filter, but can easily be made an input filter as well. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #356] Bug in CRLF translation in PKCS7_sign
No they can't. However, if CRLF are showing up in them, it means you have put it in there some way, perhaps from transfering a file in binary mode to it? Text mode vs. binary mode is tricky business... Hm. I guess what you are saying is that the function in question assumes that any non-binary input has its line-endings normalized to be LF only. It then converts all the LF-only line endings to CRLF. I think in our case we actually have some code that explicitly normalizes the line endings to CRLF _before_ passing it in. We fixed the problem in our case by changing our call to specify the BINARY flag, since we knew our line-endings were already normalized to CRLF. I guess the really confusing part of this is that the PKCS7 functions for verification seem to assume normalized CRLF line-endings in some places, but the signature creation functions seem to assume LF-only line-endings (at least that is what you seem to be saying). Anyway, I guess this is not a bug, if you assert that the input should be normalized to LF-only line-endings. I thought that the purpose of this bit of code was to normalize _either_ LF-only OR CRLF line-ending to CRLF, which it clearly does not do. BTW, if it is given CRLF, it does NOT convert them to CRCRLF in most cases, it leaves them as CRLF. Perhaps that was the source of my confusion... it handles CRLF line-endings correctly most of the time... but not if they fall on certain buffer-size boundaries. --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]
Re: [openssl.org #356] Bug in CRLF translation in PKCS7_sign
Ah, that is a good point in the case where we saw this, the source bio was a bio_s_mem, i.e. a memory bio, so it was not doing r text-mode eol translation. In other instances we do use the r mode with file bios, and I guess that might explain why we never saw it happen in those functions... although it could also be that we never had a line of text that was exactly 1022 characters long. :) In any case, I don't believe that memory bios can be set to text-mode... can they? --Peter Lincroft --- Richard Levitte via RT [EMAIL PROTECTED] wrote: A couple of questions: - which type of source BIO did you use when this happened? - if it was a text file, was it opened in binary mode? In case it was a text file opened in binary mode, do you get a better behavior if it's opened in text mode? You see, in text mode, CRLF is supposed to be converted to LF, and hopefully *before* the length of the buffer is checked... [[EMAIL PROTECTED] - Fri Nov 22 10:27:16 2002]: 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. -- Richard Levitte __ 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]
Re: [openssl.org #356] Bug in CRLF translation in PKCS7_sign
In message [EMAIL PROTECTED] on Mon, 2 Dec 2002 22:30:20 +0100 (MET), [EMAIL PROTECTED] via RT [EMAIL PROTECTED] said: rt Ah, that is a good point in the case where we saw rt this, the source bio was a bio_s_mem, i.e. a memory rt bio, so it was not doing r text-mode eol rt translation. In other instances we do use the r rt mode with file bios, and I guess that might explain rt why we never saw it happen in those functions... rt although it could also be that we never had a line of rt text that was exactly 1022 characters long. :) rt rt In any case, I don't believe that memory bios can be rt set to text-mode... can they? No they can't. However, if CRLF are showing up in them, it means you have put it in there some way, perhaps from transfering a file in binary mode to it? Text mode vs. binary mode is tricky business... -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #356] Bug in CRLF translation in PKCS7_sign
In message [EMAIL PROTECTED] on Mon, 2 Dec 2002 22:30:20 +0100 (MET), [EMAIL PROTECTED] via RT [EMAIL PROTECTED] said: rt Ah, that is a good point in the case where we saw rt this, the source bio was a bio_s_mem, i.e. a memory rt bio, so it was not doing r text-mode eol rt translation. In other instances we do use the r rt mode with file bios, and I guess that might explain rt why we never saw it happen in those functions... rt although it could also be that we never had a line of rt text that was exactly 1022 characters long. :) rt rt In any case, I don't believe that memory bios can be rt set to text-mode... can they? No they can't. However, if CRLF are showing up in them, it means you have put it in there some way, perhaps from transfering a file in binary mode to it? Text mode vs. binary mode is tricky business... -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #356] Bug in CRLF translation in PKCS7_sign
A couple of questions: - which type of source BIO did you use when this happened? - if it was a text file, was it opened in binary mode? In case it was a text file opened in binary mode, do you get a better behavior if it's opened in text mode? You see, in text mode, CRLF is supposed to be converted to LF, and hopefully *before* the length of the buffer is checked... [[EMAIL PROTECTED] - Fri Nov 22 10:27:16 2002]: 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. -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #356] Bug in CRLF translation in PKCS7_sign
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]
