Re: matrixssl
Hi
You seem to come to the same conclusion as I do.
The implementation of pstm_exptmod and mp_exptmod is considerably different.
They most likely have different set of vulnerabilities.
So let us take a look at what applications that may use matrixssl. The
reverse dependencies are: ipsvd and twoftpd. These are the only ones
that is in the reverse dependency change.
One way to check whether the two functions have similar properties is
to write a small test program, but the question is whether it is worth
the effort.
Twoftpd seem to be used by about 50 people according to popcon. Ipsvd
is a little more common with about 150 submitters.
Considering that we can not judge whether the vulnerability is there
(without considerable effort) and that the usage seems to be very low
even among the whole community I do not think it is worth the effort
fixing it. One way is to leave it to the maintainer to provide a
working debdiff.
In any case I'd consider this a low priority issue to fix.
Best regards
// Ola
On Thu, Aug 11, 2016 at 11:00 AM, Brian May <bam@debian.org> 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.
>
> 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>
--
--- Inguza Technology AB --- MSc in Information Technology ----
/ ola@inguza.com Folkebogatan 26 \
| opal@debian.org 654 68 KARLSTAD |
| http://inguza.com/ Mobile: +46 (0)70-332 1551 |
\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /
---------------------------------------------------------------
Reply to: