[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: matrixssl

On Thu, Aug 11, 2016 at 07:00:03PM +1000, Brian May wrote:
> Ola Lundqvist <ola@inguza.com> writes:
> > This is a very large commit but from
> > https://blog.fuzzing-project.org/51-Fun-with-Bignums-Crashing-MatrixSSL-and-more.html
> > it looks like it is the following files that were updated:
> > - crypto/math/pstm.c
> > - crypto/pubkey/dh.c
> > - crypto/pubkey/rsa.c
> The rsa.c patch appears to apply fine to rsa.c (actually it looks like
> there are three identical copies of rsa.c). The patch applies to
> psRsaEncryptPriv() the function but in wheezy it patches is the
> matrixRsaEncryptPub() function - makes me wonder if it is patching the
> correct thing. After visually inspecting the old code and the new code,
> it looks like it could be correct, however stuff has changed.
> There doesn't appear to be any sign of the other files, or the
> pstm_exptmod() function - which was the focus the of the security issue.

As I wrote in dla-needed.txt the bignum handling is in
crypto/peersec/mpi.c and it seems to use the same algorithms (and lacks
the same checks in e.g. mp_exptmod) so I marked it as
vulnerable. Porting back the fixes from the current version will be
difficult though, since the code has changed a lot.

 -- Guido

> So maybe this means the wheezy version is not vulnerable to the
> pstm_exptmod() because it doesn't have this function?? I suspect the
> code might use mp_exptmod() instead, which is likely to be another
> implementation with a different (?) set of security issues.
> Also worth noting this Debian packaging appears not to support any sort
> of updates to the upstream code. The matrixssl_1.8.8.orig.tar.gz
> contains matrixssl-1-8-8-open.tgz and there doesn't appear to be any
> provided mechanism that I can see for applying patches before building.
> The debian/changelog refers to a
> debian/diff/0001-don-t-define-USE_MULTITHREADING-with-diet-libc.diff
> file, but I can't actually find it. Nor can I see anything in
> debian/rules - so I think any changes would require updating the unpack
> rule in debian/rules to somehow apply them automatically.
> -- 
> Brian May <bam@debian.org>

Reply to: