Re: Nettle and CVE-2018-16869

2019-01-19 Thread Ola Lundqvist
Hi again

I can now tell that I have put nettle on the list of packages to fix. The
reason is that gnutls28 package update depends on nettle being fixed and
since it has been considered important enough to fix it is worth fixing
this. I have added quite a few notes now into the security tracker.

Best regards

// Ola

On Thu, 10 Jan 2019 at 07:45, Ola Lundqvist  wrote:

> Hi Brian
>
> Thank you. I think we almost always issue a DLA if it is a security issue.
> The only known exception, to my knowledge, is when we update packages in
> order to build something else, like compiler and such that do it itself not
> contain any security update.
>
> I'll look a little further into this but I also think this is rather minor.
>
> Thank you for your advice
>
> // Ola
>
> On Thu, 10 Jan 2019 at 06:58, Brian May  wrote:
>
>> Ola Lundqvist  writes:
>>
>> > Thank you for the feedback. Well we can do interface changes as long as
>> > they are backwards compatible. The package is backwards compatible. The
>> > problem here is that the fix is in a new function that no software will
>> use
>> > and hence the fix is useless unless we also change all software using
>> > nettle.
>> >
>> > How do we handle this kind of problem?
>>
>> First question: Is it worth fixing this problem? It sounds like it might
>> be a relatively minor issue.
>>
>> If we were to proceed, I would imagine we need to update the library
>> first and then update the applications.
>>
>> Does updating the library in the archive require a DLA? It would add a
>> security update, but user's won't see it until updating the
>> applications.
>>
>> > Should all software using the insecure function be mapped to the same
>> CVE,
>> > or should there in fact be different CVEs for each package that is
>> insecure?
>>
>> In the past I think I have been steered towards one CVE per application,
>> however not sure if that advice applies for this specific case.
>> --
>> Brian May 
>>
>
>
> --
>  --- Inguza Technology AB --- MSc in Information Technology 
> /  o...@inguza.comFolkebogatan 26\
> |  o...@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  /
>  ---
>
>

-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@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  /
 ---


Re: Nettle and CVE-2018-16869

2019-01-09 Thread Ola Lundqvist
Hi Brian

Thank you. I think we almost always issue a DLA if it is a security issue.
The only known exception, to my knowledge, is when we update packages in
order to build something else, like compiler and such that do it itself not
contain any security update.

I'll look a little further into this but I also think this is rather minor.

Thank you for your advice

// Ola

On Thu, 10 Jan 2019 at 06:58, Brian May  wrote:

> Ola Lundqvist  writes:
>
> > Thank you for the feedback. Well we can do interface changes as long as
> > they are backwards compatible. The package is backwards compatible. The
> > problem here is that the fix is in a new function that no software will
> use
> > and hence the fix is useless unless we also change all software using
> > nettle.
> >
> > How do we handle this kind of problem?
>
> First question: Is it worth fixing this problem? It sounds like it might
> be a relatively minor issue.
>
> If we were to proceed, I would imagine we need to update the library
> first and then update the applications.
>
> Does updating the library in the archive require a DLA? It would add a
> security update, but user's won't see it until updating the
> applications.
>
> > Should all software using the insecure function be mapped to the same
> CVE,
> > or should there in fact be different CVEs for each package that is
> insecure?
>
> In the past I think I have been steered towards one CVE per application,
> however not sure if that advice applies for this specific case.
> --
> Brian May 
>


-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@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  /
 ---


Re: Nettle and CVE-2018-16869

2019-01-09 Thread Brian May
Ola Lundqvist  writes:

> Thank you for the feedback. Well we can do interface changes as long as
> they are backwards compatible. The package is backwards compatible. The
> problem here is that the fix is in a new function that no software will use
> and hence the fix is useless unless we also change all software using
> nettle.
>
> How do we handle this kind of problem?

First question: Is it worth fixing this problem? It sounds like it might
be a relatively minor issue.

If we were to proceed, I would imagine we need to update the library
first and then update the applications.

Does updating the library in the archive require a DLA? It would add a
security update, but user's won't see it until updating the
applications.

> Should all software using the insecure function be mapped to the same CVE,
> or should there in fact be different CVEs for each package that is insecure?

In the past I think I have been steered towards one CVE per application,
however not sure if that advice applies for this specific case.
-- 
Brian May 



Re: Nettle and CVE-2018-16869

2019-01-09 Thread Ola Lundqvist
Hi Brian

Thank you for the feedback. Well we can do interface changes as long as
they are backwards compatible. The package is backwards compatible. The
problem here is that the fix is in a new function that no software will use
and hence the fix is useless unless we also change all software using
nettle.

How do we handle this kind of problem?

Should all software using the insecure function be mapped to the same CVE,
or should there in fact be different CVEs for each package that is insecure?

Cheers

// Ola

On Wed, 9 Jan 2019 at 22:35, Brian May  wrote:

> Ola Lundqvist  writes:
>
> > It is described as the Bleichenbacher-style attack. When I read the
> > changelog diffing the source I find that this is fixed by introducing a
> new
> > function and that new function is recommended by packages that use
> nettle.
> > Due to that I do not find it suitable to change neither jessie (and not
> > stretch either) since the application software using nettle must be
> changed
> > too. This applies to buster and sid too by the way, but there it is at
> > least possible that some software will be updated before the release.
> >
> > It could still be good to update using the patch, but there is a
> potential
> > 60% performance penalty as well so maybe it is not worth it.
> >
> > If nobody complains I will therefore mark this CVE as "ignored".
> >
> > Any opinions?
>
> I was looking into this yesterday, and coming up with similar
> conclusions. I don't think we can really include any API changes in a
> LTS release, even if they are required to fix security issues (???).
>
> From
> https://lists.lysator.liu.se/pipermail/nettle-bugs/2018/007363.html:
>
> "For Nettle, the RSA code, which I wrote some 15 years ago, have seen an
> overhawl. Not only making the handling of PKCS#1 on decryption
> side-channel silent (the vulnerabilities that could be exploited by the
> methods of the above paper), but also ensuring that we use side-channel
> silent functions for the needed bignum arithmetic.
>
> "This has been a lot of work, and most of it not done by me, but by Simo
> Sorce, at Red Hat Inc. Without this help, it would have been difficult
> to get a good release out on time.
>
> "Testing of the release candidate is highly appreciated. I intend to make
> and announce the non-candidate release soon, possibly as early as
> tomorrow morning (i.e., December 1, in European timezone). A GnuTLS
> release, depending on the new rsa_sec_decrypt function in Nettle-3.4.1,
> is also being made about now.
>
> "My understanding is that there's no need to panic. The attack directly
> affects RSA decryption, not signatures. And it requires some resources
> to be pulled off. As far as I understand, a successful attack lets the
> attacker decrypt or sign a targeted message, e.g., compromising the TLS
> "premaster secret", corresponding session keys, and any transmitted
> passwords or login cookies sent in a single TLS session, but it does not
> expose the private key itself.
>
> "However, if you operate a TLS server, you should consider if you can
> completely disable key exchange based on RSA decryption. If you need to
> keep it for backwards compatibility, it is *strongly* encouraged to use
> a separate RSA key for this purpose, *not* reused or authorized for any
> other purpose."
> --
> Brian May 
>


-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@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  /
 ---


Re: Nettle and CVE-2018-16869

2019-01-09 Thread Brian May
Ola Lundqvist  writes:

> It is described as the Bleichenbacher-style attack. When I read the
> changelog diffing the source I find that this is fixed by introducing a new
> function and that new function is recommended by packages that use nettle.
> Due to that I do not find it suitable to change neither jessie (and not
> stretch either) since the application software using nettle must be changed
> too. This applies to buster and sid too by the way, but there it is at
> least possible that some software will be updated before the release.
>
> It could still be good to update using the patch, but there is a potential
> 60% performance penalty as well so maybe it is not worth it.
>
> If nobody complains I will therefore mark this CVE as "ignored".
>
> Any opinions?

I was looking into this yesterday, and coming up with similar
conclusions. I don't think we can really include any API changes in a
LTS release, even if they are required to fix security issues (???).

From
https://lists.lysator.liu.se/pipermail/nettle-bugs/2018/007363.html:

"For Nettle, the RSA code, which I wrote some 15 years ago, have seen an
overhawl. Not only making the handling of PKCS#1 on decryption
side-channel silent (the vulnerabilities that could be exploited by the
methods of the above paper), but also ensuring that we use side-channel
silent functions for the needed bignum arithmetic.

"This has been a lot of work, and most of it not done by me, but by Simo
Sorce, at Red Hat Inc. Without this help, it would have been difficult
to get a good release out on time.

"Testing of the release candidate is highly appreciated. I intend to make
and announce the non-candidate release soon, possibly as early as
tomorrow morning (i.e., December 1, in European timezone). A GnuTLS
release, depending on the new rsa_sec_decrypt function in Nettle-3.4.1,
is also being made about now.

"My understanding is that there's no need to panic. The attack directly
affects RSA decryption, not signatures. And it requires some resources
to be pulled off. As far as I understand, a successful attack lets the
attacker decrypt or sign a targeted message, e.g., compromising the TLS
"premaster secret", corresponding session keys, and any transmitted
passwords or login cookies sent in a single TLS session, but it does not
expose the private key itself.

"However, if you operate a TLS server, you should consider if you can
completely disable key exchange based on RSA decryption. If you need to
keep it for backwards compatibility, it is *strongly* encouraged to use
a separate RSA key for this purpose, *not* reused or authorized for any
other purpose."
-- 
Brian May