Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <CAJ_zFkKvd44vX+cHJdOm3gXXe0T2wJKBPG7njqBfq1QEqkgHMQ@mail.gmail.com>
Date: Thu, 14 Feb 2019 16:05:38 -0800
From: Tavis Ormandy <taviso@...gle.com>
To: oss-security@...ts.openwall.com
Subject: MatrixSSL stack buffer overflow

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.

Content of type "text/html" skipped

View attachment "patch.diff" of type "text/x-patch" (469 bytes)

Download attachment "stackbufferoverflow.pem" of type "application/x-x509-ca-cert" (2880 bytes)

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.