Bug ID 1015243
Summary VUL-0: CVE-2016-9939: libcryptopp: Potential DoS in Crypto++ (libcryptopp) ASN.1 parser
Classification openSUSE
Product openSUSE Distribution
Version Leap 42.2
Hardware Other
OS Other
Status NEW
Severity Normal
Priority P5 - None
Component Security
Assignee security-team@suse.de
Reporter mikhail.kasimov@gmail.com
QA Contact qa-bugs@suse.de
Found By ---
Blocker ---

Reference: [1] http://seclists.org/oss-sec/2016/q4/659

[1]:
=========================================================================
Gergely Nagy and Tam�s Koczka of Tresorit report a potential DoS in
the Crypto++ ASN.1 parser. A copy of their email with the report can
be found at
https://groups.google.com/d/msg/cryptopp-users/fEQ8jWg_K8g/qOLHGIDICwAJ.

When Crypto++ library parses an ASN.1 data value, the library
allocates for the content octets based on the length octets. Later, if
there's too few or too little content octets, the library throws a
BERDecodeErr exception. The memory for the content octets will be
zeroized (even if unused), which could take a long time on a large
allocation.

Please assign a CVE for the potential issue.

Thanks in advance.
========================================================================

[2] https://groups.google.com/d/msg/cryptopp-users/fEQ8jWg_K8g/qOLHGIDICwAJ

[2]:
========================================================================
---------- Forwarded message ----------
From: Gergely Nagy <n...@tresorit.com>
Date: Mon, Dec 12, 2016 at 8:45 AM
Subject: Security issue (DoS) in Crypto++ ASN1 decoder
To: Jeffrey Walton <nolo...@gmail.com>
Cc: Tam�s Koczka <koc...@tresorit.com>

Hi!

I have found a bug in several BERDecode* functions which could be used
for a DoS attack.

The issue is similar to CVE-2016-2109 in OpenSSL which was disclosed
in https://www.openssl.org/news/secadv/20160503.txt


Basically after the ASN1 decoder reads the length, it allocates a
SecByteBlock of that size before checking that there is enough data
available.

This can cause memory exhaustion on most platforms, but it has (in my
opinion) the worst effect on 64-bit Linux systems where the allocation

will succeed for huge sizes and then a BERDecodeError exception will
be thrown that causes the destructor of the SecByteBlock to be called,

which can hang the CPU for a really long time zeroing out memory.


I have attached a patch (for the current master branch) that fixes
this behavior in both versions of BERDecodeOctetString,
BERDecodeTextString,

BERDecodeBitString and BERDecodeUnsigned. I am not 100% sure that
there are no other places in the code with the same issue.


I don't know how you want to disclose this issue, but if you want to
assign a CVE number and release a new version before publicly
disclosing it

then we won't deploy our fix until then.

We will binary patch our software which includes a statically linked
Crypto++ after 30 days if we don't get a proper response.

When you disclose the issue please refer to me as "Gergely Nagy
(Tresorit)", and say that the bug was found using "honggfuzz".


Thanks,

Gergely Nagy (Tresorit) 
========================================================================

[3]: https://github.com/weidai11/cryptopp/issues/346

Assigned CVE-2016-9939: [4] http://seclists.org/oss-sec/2016/q4/660


You are receiving this mail because: