[prev in list] [next in list] [prev in thread] [next in thread]
List: oss-security
Subject: [oss-security] MatrixSSL stack buffer overflow
From: Tavis Ormandy <taviso () google ! com>
Date: 2019-02-15 0:05:38
Message-ID: CAJ_zFkKvd44vX+cHJdOm3gXXe0T2wJKBPG7njqBfq1QEqkgHMQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hello, while auditing some code using the MatrixSSL library (currently sold
as the Inside Secure TLS Toolkit, previously also called GUARD TLS
Toolkit), I happened to notice that a public X.509 certificate testcase
for CVE-2014-1569 caused a stack buffer overflow.
I did not create the testcase <https://github.com/FiloSottile/BERserk>, it
was produced by Filippo Valsorda <https://twitter.com/FiloSottile> to
accompany an advisory published by McAfee
<https://www.mcafee.com/enterprise/en-us/threat-center/advanced-threat-research/crypto-software.html>.
At the time, they had rebranded as Intel Security, but have since rebranded
back to McAfee).
Intel listed MatrixSSL as affected by various ASN.1 parsing
vulnerabilities, but didn't provide any testcases, so I guess the
vulnerabilities were never fixed. As this testcase and advisory are already
public, I see no need for any embargo here.
I cleaned up the testcase a bit, to make a better demonstration. You can
test it with the certValidate tool that comes with MatrixSSL.
$ gdb -q --args matrixssl/matrixssl/test/certValidate
stackbufferoverflow.pem
Reading symbols from matrixssl/matrixssl/test/certValidate...done.
(gdb) r
Starting program: matrixssl/matrixssl/test/certValidate
stackbufferoverflow.pem
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Loaded chain file stackbufferoverflow.pem
[0]:berserk.filippo.io
[1]:(null)
WARN subject not provided, SUBJ validation will be skipped
Program received signal SIGSEGV, Segmentation fault.
0x00005555555c5164 in pubRsaDecryptSignedElementExt
(gdb) bt
#0 0x00005555555c5164 in pubRsaDecryptSignedElementExt
#1 0x4141414141414141 in ?? ()
#2 0x0000000000000000 in ?? ()
(I had to bruteforce the encrypted data to get the 0x414141.. output, but
you can do so one byte at a time)
I believe any client or server that validates certificates will be affected
by this, and as MatrixSSL is usually used in embedded devices where
mitigations are usually not quite as thorough as modern distributions,
exploitation might not be difficult.
The bug is that pubRsaDecryptSignedElementExt() uses a fixed size stack
buffer, but then doesn't check if the key size exceeds it. The attached
patch should solve it.
Tavis.
[Attachment #5 (text/html)]
<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div \
dir="ltr">Hello, while auditing some code using the MatrixSSL library (currently sold as the \
Inside Secure TLS Toolkit, previously also called GUARD TLS Toolkit), I happened to notice that \
a public X.509 certificate testcase for CVE-2014-1569 caused a stack buffer \
overflow.</div><div dir="ltr"><br></div><div>I did not create the <a \
href="https://github.com/FiloSottile/BERserk">testcase</a>, it was produced by <a \
href="https://twitter.com/FiloSottile">Filippo Valsorda</a> to accompany an advisory published \
by <a href="https://www.mcafee.com/enterprise/en-us/threat-center/advanced-threat-research/crypto-software.html">McAfee</a>. \
At the time, they had rebranded as Intel Security, but have since rebranded back to \
McAfee).</div><div dir="ltr"><br></div><div dir="ltr">Intel listed MatrixSSL as affected by \
various ASN.1 parsing vulnerabilities, but didn't provide any testcases, so I guess the \
vulnerabilities were never fixed. As this testcase and advisory are already public, I see no \
need for any embargo here.<br></div><div dir="ltr"><br></div><div>I cleaned up the testcase a \
bit, to make a better demonstration. You can test it with the certValidate tool that comes with \
MatrixSSL.</div><div><font face="monospace, monospace"><br></font></div><div><div><font \
face="monospace, monospace">$ gdb -q --args matrixssl/matrixssl/test/certValidate \
stackbufferoverflow.pem</font></div><div><font face="monospace, monospace">Reading symbols from \
matrixssl/matrixssl/test/certValidate...done.</font></div><div><font face="monospace, \
monospace">(gdb) r</font></div><div><font face="monospace, monospace">Starting program: \
matrixssl/matrixssl/test/certValidate stackbufferoverflow.pem</font></div><div><font \
face="monospace, monospace">[Thread debugging using libthread_db \
enabled]</font></div><div><font face="monospace, monospace">Using host libthread_db library \
"/lib/x86_64-linux-gnu/libthread_db.so.1".</font></div><div><font face="monospace, \
monospace"> Loaded chain file stackbufferoverflow.pem</font></div><div><font face="monospace, \
monospace"> [0]:<a \
href="http://berserk.filippo.io">berserk.filippo.io</a></font></div><div><font face="monospace, \
monospace"> [1]:(null)</font></div><div><font face="monospace, monospace">WARN \
subject not provided, SUBJ validation will be skipped</font></div><div><font face="monospace, \
monospace"><br></font></div><div><font face="monospace, monospace">Program received signal \
SIGSEGV, Segmentation fault.</font></div><div><font face="monospace, \
monospace">0x00005555555c5164 in pubRsaDecryptSignedElementExt<br></font></div><div><div><font \
face="monospace, monospace">(gdb) bt</font></div></div><div><font face="monospace, \
monospace">#0 0x00005555555c5164 in \
pubRsaDecryptSignedElementExt<br></font></div></div><div><div><font face="monospace, \
monospace">#1 0x4141414141414141 in ?? ()</font></div><div><font face="monospace, \
monospace">#2 0x0000000000000000 in ?? ()</font></div></div><div><br></div><div>(I had to \
bruteforce the encrypted data to get the 0x414141.. output, but you can do so one byte at a \
time)</div><div><br></div><div>I believe any client or server that validates certificates will \
be affected by this, and as MatrixSSL is usually used in embedded devices where mitigations are \
usually not quite as thorough as modern distributions, exploitation might not be \
difficult.</div><div><br></div>The bug is that pubRsaDecryptSignedElementExt() uses a fixed \
size stack buffer, but then doesn't check if the key size exceeds it. The attached patch \
should solve it.</div><div dir="ltr"><br></div><div dir="ltr"><br></div><div \
dir="ltr"><div>Tavis. </div><div><br></div></div></div></div></div></div></div>
--000000000000bc73160581e389d1--
["patch.diff" (text/x-patch)]
diff --git a/crypto/pubkey/rsa_pub.c b/crypto/pubkey/rsa_pub.c
index f1d57e0..fa36e42 100644
--- a/crypto/pubkey/rsa_pub.c
+++ b/crypto/pubkey/rsa_pub.c
@@ -63,6 +63,12 @@ int32_t psRsaDecryptPubExt(psPool_t *pool,
return PS_ARG_FAIL;
}
+ if (*outlen < key->size)
+ {
+ psTraceCrypto("Error on bad outlen parameter to psRsaDecryptPub\n");
+ return PS_ARG_FAIL;
+ }
+
ptLen = inlen;
/* Raw, in-place RSA decryption. */
["stackbufferoverflow.pem" (application/x-x509-ca-cert)]
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic