http://bugzilla.opensuse.org/show_bug.cgi?id=1015243 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 Date: Mon, Dec 12, 2016 at 8:45 AM Subject: Security issue (DoS) in Crypto++ ASN1 decoder To: Jeffrey Walton Cc: Tamás Koczka 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: You are on the CC list for the bug.