Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 19 Aug 2016 09:49:59 -0400 (EDT)
Subject: Re: MatrixSSL Bignum bugs

Hash: SHA256


>> several issues related to RSA and bignum operations

> If one tries to calculate a modular
> exponentiation with the base zero (0^b mod a, code) it would crash with
> an invalid free operation, potentially leading to memory corruption.

>> Testing MatrixSSL's pstm_exptmod with base zero

Use CVE-2016-6885.

> a malicious client could simply send a zero or the key's modulus here. I
> created a patch against openssl that allows to test this. Both values
> crash the MatrixSSL server. However the crash seems not to happen in
> pstm_exptmod(), it hits another bug earlier. In both cases the crash
> happens due to an invalid memory read in the function pstm_reverse(),
> which is not prepared for zero-sized inputs and will underflow the len
> variable.

>> This patch allows one to send malformed RSA encryptions during the handshake.
>> One can either send zeros or the RSA key modulus. Both trigger a bug in
>> MatrixSSL 3.8.3.

As far as we can tell, here you are reporting a crash issue that is not
identical to the "exponentiation with the base zero" issue.

Use CVE-2016-6886.

> Fortunately this was discovered before the change made it into a
> release.

>> I'm considering the below patch

>>> Committed and pushed now

There is no CVE ID for this "crashes with a floating point error"
behavior that existed in the
code as of approximately 2016-07-17 through 2016-07-31. The Nettle
documentation at doesn't
specifically recommend that people ship unreleased Nettle code. A CVE
ID isn't, in general, required for each issue noted at any arbitrary
point during development.

> I was able to identify an input value that caused a
> wrong calculation result.
> They now restrict the input to the pstm_exptmod()
> function to a set of bit sizes (512, 1024, 1536, 2048, 3072, 4096). My
> test input had a different bit size

As far as we can tell, a "wrong calculation result" is not always a
vulnerability on its own, and sometimes becomes relevant only when
there is a composite with another issue. However, the set of other
issues is not fully specified and thus we are assigning a CVE ID to
the "wrong calculation result" itself in this specific case.

Use CVE-2016-6887.

- -- 
CVE Assignment Team
M/S M300, 202 Burlington Road, Bedford, MA 01730 USA
[ A PGP key is available for encrypted communications at ]
Version: GnuPG v1


Powered by blists - more mailing lists

Your e-mail address:

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

Powered by Openwall GNU/*/Linux - Powered by OpenVZ