Fix CRLF problem in BASE64 decode.
authorLutz Jänicke <jaenicke@openssl.org>
Mon, 15 Apr 2002 09:53:47 +0000 (09:53 +0000)
committerLutz Jänicke <jaenicke@openssl.org>
Mon, 15 Apr 2002 09:53:47 +0000 (09:53 +0000)
Submitted by:
Reviewed by:
PR:

CHANGES
crypto/evp/encode.c

diff --git a/CHANGES b/CHANGES
index 66b6ec21ae52bc8c64fc9c237426d05dcf65d8f2..fa1232df46605a6895782a3a8001ad7c1b77ee7f 100644 (file)
--- a/CHANGES
+++ b/CHANGES
@@ -1589,6 +1589,14 @@ des-cbc           3624.96k     5258.21k     5530.91k     5624.30k     5628.26k
 
  Changes between 0.9.6c and 0.9.6d  [XX xxx 2002]
 
+  *) Fix BASE64 decode (EVP_DecodeUpdate) for data with CR/LF ended lines:
+     an end-of-file condition would erronously be flagged, when the CRLF
+     was just at the end of a processed block. The bug was discovered when
+     processing data through a buffering memory BIO handing the data to a
+     BASE64-decoding BIO. Bug fund and patch submitted by Pavel Tsekov
+     <ptsekov@syntrex.com> and Nedelcho Stanev.
+     [Lutz Jaenicke]
+
   *) Implement a countermeasure against a vulnerability recently found
      in CBC ciphersuites in SSL 3.0/TLS 1.0: Send an empty fragment
      before application data chunks to avoid the use of known IVs
index 6ff9c1783cf60720ee60a29298746ec5e0427356..12c6379df1826547aac9ca27e54e3e64d6c402ee 100644 (file)
@@ -277,6 +277,13 @@ int EVP_DecodeUpdate(EVP_ENCODE_CTX *ctx, unsigned char *out, int *outl,
                        eof++;
                        }
 
+               if (v == B64_CR)
+                       {
+                       ln = 0;
+                       if (exp_nl)
+                               continue;
+                       }
+
                /* eoln */
                if (v == B64_EOLN)
                        {