Follow @Openwall on Twitter for new release announcements and other news
[<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

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.