Sanity check PVK file fields.

PVK files with abnormally large length or salt fields can cause an
integer overflow which can result in an OOB read and heap corruption.
However this is an rarely used format and private key files do not
normally come from untrusted sources the security implications not
significant.

Fix by limiting PVK length field to 100K and salt to 10K: these should be
more than enough to cover any files encountered in practice.

Issue reported by Guido Vranken.

Reviewed-by: Rich Salz <rsalz@openssl.org>

diff --git a/crypto/pem/pvkfmt.c b/crypto/pem/pvkfmt.c
index 2cd79036a67ac63adc08a7bcd37539cca1d51220..117d2b794d277263ddd0277712cd8fe7a9e02f40 100644 (file)
--- a/crypto/pem/pvkfmt.c
+++ b/crypto/pem/pvkfmt.c
@@ -119,6 +119,10 @@ static int read_lebn(const unsigned char **in, unsigned int nbyte, BIGNUM **r)
 # define MS_PVKMAGIC             0xb0b5f11eL
 /* Salt length for PVK files */
 # define PVK_SALTLEN             0x10
+/* Maximum length in PVK header */
+# define PVK_MAX_KEYLEN          102400
+/* Maximum salt length */
+# define PVK_MAX_SALTLEN         10240
 
 static EVP_PKEY *b2i_rsa(const unsigned char **in,
                          unsigned int bitlen, int ispub);
@@ -608,6 +612,9 @@ static int do_PVK_header(const unsigned char **in, unsigned int length,
     *psaltlen = read_ledword(&p);
     *pkeylen = read_ledword(&p);
 
+    if (*pkeylen > PVK_MAX_KEYLEN || *psaltlen > PVK_MAX_SALTLEN)
+        return 0;
+
     if (is_encrypted && !*psaltlen) {
         PEMerr(PEM_F_DO_PVK_HEADER, PEM_R_INCONSISTENT_HEADER);
         return 0;