Re: Security update of firefox-esr for Wheezy

[Emilio Pozuelo Monfort]

On 07/08/16 22:17, Raphael Hertzog wrote:
> On Sun, 07 Aug 2016, Guido Günther wrote:
>> I too think I would be good to support Firefox & Icedove until Wheezy
>> goes EOL. Wd could backport gcc 4.8 from Jessie with only C/C++ enabled.
> 
> And obviously, we make no change to gcc-defaults.
> 
> Shall we mark gcc-4.8 as unsupported in wheezy, explaining that its only
> purpose is to enable build of other packages?

That would make sense.

I'll see if I can take a look at this.

Cheers,
Emilio

Re: Security update of firefox-esr for Wheezy

[Ola Lundqvist]

Hi

Yes I think it is a good idea to mark it as unsupported as you describe.

// Ola

On Sun, Aug 7, 2016 at 10:17 PM, Raphael Hertzog  wrote:

> On Sun, 07 Aug 2016, Guido Günther wrote:
> > I too think I would be good to support Firefox & Icedove until Wheezy
> > goes EOL. Wd could backport gcc 4.8 from Jessie with only C/C++ enabled.
>
> And obviously, we make no change to gcc-defaults.
>
> Shall we mark gcc-4.8 as unsupported in wheezy, explaining that its only
> purpose is to enable build of other packages?
>
> Cheers,
> --
> Raphaël Hertzog ◈ Debian Developer
>
> Support Debian LTS: http://www.freexian.com/services/debian-lts.html
> Learn to master Debian: http://debian-handbook.info/get/
>
>


-- 
 --- 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: Security update of nettle

[Ola Lundqvist]

Hi Andreas

It looks like you have managed without the context. I'm sorry that I was a
little too brief.

First thank you a lot for confirming that gnutls do not use nettle in
wheezy. This is very good to know as I can safely patch nettle without
considering gnutls usage of nettle. Thanks! It saves me the burden of
patching and coordinating several uploads.

The follow up patches that are needed are to modify gnutls (as long as it
is using nettle).

This (below) is what I have understood from Niels Möller. He is the source
of my knowledge so please be in contact with him about the details.

The correction in nettle is to use mpz_powm_sec instead of mpz_powm. The
problem is that mpz_powm_sec will crash if the modulo argument is an even
number. So a check is needed to ensure that or else we have a denial of
service problem.
You can see the detailed correction here:
https://git.lysator.liu.se/nettle/nettle/commit/3fe1d6549765ecfb24f0b80b2ed086fdc818bff3

Nettle have added such checks in the *_key_prepare functions, see here:
https://git.lysator.liu.se/nettle/nettle/commit/5eb30d94f6f5f3f0cb9ba9ed24bc52b7376176b6
https://git.lysator.liu.se/nettle/nettle/commit/52b9223126b3f997c00d399166c006ae28669068
https://git.lysator.liu.se/nettle/nettle/commit/544b4047de689519ab3e6ec55b776b95b3e264a9

I think this merge commit may be of help:
https://git.lysator.liu.se/nettle/nettle/commit/b721591c051ce9e2304033dd19564f089775df17

The issue is that gnutls do not use (or do not check the return code) these
prepare functions so there is therefore nothing that prevent the service
from crashing in case an invalid signature is provided. The attack would
for example be possible on some service provider having a common web server
for multiple clients where the client can add their own certificate/key. In
such case the whole server will go down instead of just this client.

So a check is needed in gnutls to check that the modulo is not even. This
can be done either by using the prepare functions (and check the return
code) or by checking it explicitly.

Was this enough context?

// Ola

On Sun, Aug 7, 2016 at 8:04 AM, Andreas Metzler  wrote:

> On 2016-08-07 Ola Lundqvist  wrote:
> > On Sat, Aug 6, 2016 at 8:40 PM, Niels Möller 
> wrote:
> >> Ola Lundqvist  writes:
> >>> Magnus, Niels and I have been discussing the nettle update due to
> >>> https://security-tracker.debian.org/tracker/CVE-2016-6489
>
> >> Please note that some coordinatoino with gnutls may be needed, to avoid
> >> a denial-of-service problem involving invalid private keys.
>
> >>> I suggest something like this: "Protect against potential timing
> >>> attacks against exponentiation operations as described in
> >>> CVE-2016-6489 RSA code is vulnerable to cache sharing related
> >>> attacks."
>
> >> I'd suggest the more general "side-channel attacks" over "timing
> >> attacks".
>
> > I do not think coordination with gnutls is needed. I can not see that
> > gnutls depend on nettle in wheezy.
> > I can see that it can potentially do that, but I do not think it do.
>
> > There are no dependencies declared on nettle library and from unstable
> > changelog it looks like this build dependency was first added in
> gnutls28.
> > Wheezy has gnutls28.
>
> > I may be wrong however.
>
> > Or can it be so that nettle is built in statically and that a build
> > dependency is not needed as some other package has a build dependency so
> we
> > get it indirectly?
>
> > I'm including the gnutls maintainers to get their opinion.
>
>
> Hello Ola,
>
> I think I am missing a little bit context, according to the security
> tracker the issue applies to practically all versions of, from oldstable
> up to and including unstable but the discussion seems to focus on LTS.
>
> You are right regarding wheezy/oldstable. It shipped gnutls 2.12.x built
> against libgcrypt instead of nettle, there should not be a problem with
> a nettle update. 3.3.8 (using nettle) is in wheezy-backports, but that
> is not covered by LTS afaiu.
>
> I am wondering about stable/testing/sid though.
> https://security-tracker.debian.org/tracker/CVE-2016-6489 points to
> "Original patch had some unintended side effects:", e.g. breaking
> GnuTLS. There is a lot of discussion following, however I failed to get
> whether the followup patches commited to nettle git did away with the
> "unintended side effects" or whether we still need to coordinate for
> stable/testing/sid?
>
> cu Andreaas
> --
> `What a good friend you are to him, Dr. Maturin. His other friends are
> so grateful to you.'
> `I sew his ears on from time to time, sure'
>



-- 
 --- 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 

Re: Wheezy update of mupdf?

[Jonas Meurer]

Dear maintainer, dear LTS team,

Am 06.08.2016 um 15:59 schrieb Jonas Meurer:
> the Debian LTS team would like to fix the security issues which are
> currently open in the Wheezy version of mupdf:
> https://security-tracker.debian.org/tracker/CVE-2016-6525
> [...]
> 
> PS: I already started working on backporting the fix for CVE-2016-6525
> to the mupdf version in wheezy. Now I realized, that in an earlier
> conversation you expressed interest to prepare packages for
> wheezy-security yourself. Back then, this was not necessary due to
> wheezy not being affected. I can take care of fixing CVE-2016-6525 in
> wheezy or leave it up to you - whatever you prefer.

Please find the debdiff for mupdf 0.9-2+deb7u3 attached to this mail. I
backported the upstreams patch[1] to the 0.9 codebase and tested basic
functionality of the updated package.

If nobody objects, I'll upload mupdf 0.9-2+deb7u3 to wheezy-security
tomorrow and send out the DLA afterwards.

Cheers,
 jonas

[1]
http://git.ghostscript.com/?p=mupdf.git;h=39b0f07dd960f34e7e6bf230ffc3d87c41ef0f2e
diff -Nru mupdf-0.9/debian/changelog mupdf-0.9/debian/changelog
--- mupdf-0.9/debian/changelog	2014-06-04 16:46:48.0 +0200
+++ mupdf-0.9/debian/changelog	2016-08-06 16:13:17.0 +0200
@@ -1,3 +1,11 @@
+mupdf (0.9-2+deb7u3) wheezy-security; urgency=high
+
+  * Non-maintainer upload by the LTS Team.
+  * Backport fix for CVE-2016-6525: heap overflow in pdf_load_mesh_params()
+from upstream git commit 39b0f07dd960f34e7e6bf230ffc3d87c41ef0f2e.
+
+ -- Jonas Meurer   Sat, 06 Aug 2016 16:13:05 +0200
+
 mupdf (0.9-2+deb7u2) wheezy-security; urgency=high
 
   * Fix header mismatch with libjpeg-dev.
diff -Nru mupdf-0.9/debian/patches/CVE-2016-6525.patch mupdf-0.9/debian/patches/CVE-2016-6525.patch
--- mupdf-0.9/debian/patches/CVE-2016-6525.patch	1970-01-01 01:00:00.0 +0100
+++ mupdf-0.9/debian/patches/CVE-2016-6525.patch	2016-08-06 16:17:29.0 +0200
@@ -0,0 +1,43 @@
+From: Jonas Meurer 
+Date: Sat, 06 Aug 2016 13:26:23 +0200
+Subject: [PATCH] fix heap overflow in pdf_load_mesh_params() (CVE-2016-6525)
+
+pdf_load_mesh_params() reads more than FZ_MAX_COLORS values into mesh_params.
+Limiting the number of allowed values to FZ_MAX_COLORS prevents a possible
+buffer overflow.
+This patch is backported from the upstream fix by Sebastian Rasmussen in git
+commit 39b0f07dd960f34e7e6bf230ffc3d87c41ef0f2e.
+
+diff --git a/fitz/fitz.h b/fitz/fitz.h
+index dff6b8d..a847e0e 100644
+--- a/fitz/fitz.h
 b/fitz/fitz.h
+@@ -154,6 +154,15 @@ int fz_strlcat(char *dst, const char *src, int n);
+ /* Range checking atof */
+ float fz_atof(const char *s);
+ 
++/*
++	Backport standard math function fz_mini from mupdf 1.9a in
++	order to fix CVE-2016-6525 in pdf/pdf_shade.c:574.
++*/
++static inline int fz_mini(int a, int b)
++{
++	return (a < b ? a : b);
++}
++
+ /* utf-8 encoding and decoding */
+ int chartorune(int *rune, char *str);
+ int runetochar(char *str, int *rune);
+diff --git a/pdf/pdf_shade.c b/pdf/pdf_shade.c
+index 1e0bf5f..cdc8a9c 100644
+--- a/pdf/pdf_shade.c
 b/pdf/pdf_shade.c
+@@ -571,7 +571,7 @@ pdf_load_mesh_params(pdf_xref *xref, fz_obj *dict, struct mesh_params *p)
+ 	obj = fz_dict_gets(dict, "Decode");
+ 	if (fz_array_len(obj) >= 6)
+ 	{
+-		n = (fz_array_len(obj) - 4) / 2;
++		n = fz_mini(FZ_MAX_COLORS, (fz_array_len(obj) - 4) / 2);
+ 		p->x0 = fz_to_real(fz_array_get(obj, 0));
+ 		p->x1 = fz_to_real(fz_array_get(obj, 1));
+ 		p->y0 = fz_to_real(fz_array_get(obj, 2));
diff -Nru mupdf-0.9/debian/patches/series mupdf-0.9/debian/patches/series
--- mupdf-0.9/debian/patches/series	2014-06-04 16:46:48.0 +0200
+++ mupdf-0.9/debian/patches/series	2016-08-06 13:22:21.0 +0200
@@ -1,3 +1,4 @@
 CVE-2014-2013.patch
 bug621894.patch
 bug646350.patch
+CVE-2016-6525.patch


signature.asc
Description: OpenPGP digital signature

Re: Security update of firefox-esr for Wheezy

[Guido Günther]

On Fri, Aug 05, 2016 at 11:52:29PM +0200, Emilio Pozuelo Monfort wrote:
> On 04/08/16 23:02, Mike Hommey wrote:
> > On Thu, Aug 04, 2016 at 07:50:28PM +0200, Guido Günther wrote:
> >> Hi,
> >> On Thu, Aug 04, 2016 at 06:32:14PM +0900, Mike Hommey wrote:
> >>> On Thu, Aug 04, 2016 at 11:04:47AM +0200, Markus Koschany wrote:
>  Hello Mike,
> 
>  Thank you for preparing the security update of firefox-esr. I have just
>  sent a security announcement for your update in Wheezy to the
>  debian-lts-announce mailing list. If you want to take care of this next
>  time, please follow our guidelines which we have outlined at [1]. If
>  this is a burden for you, no problem, we will do our best and take care
>  of the rest. In this case we would like to ask you to send a short
>  reminder to debian-lts, so that we can prepare the announcement in a
>  timely manner.
> >>>
> >>> Heh, I hadn't realized that wasn't handled by standard DSAs, sorry about
> >>> that. That these updates go through the same security-master doesn't
> >>> help making it obvious they are different.
> >>>
> >>> Anyways, I'd rather not have more work to do, so if can send
> >>> announcements, that works for me. Or you can deal with the backport
> >>> from back to back.
> >>>
> >>> Please note that the next ESR bump (52) will require GCC 4.8, which is
> >>> not in wheezy, so I won't be building ESR45 for wheezy past 45.8,
> >>> presumably some time in April next year.
> >>
> >> The same is true for icedove. Since this is way before the end of Wheezy
> >> LTS (31st May 2018) I wonder if we should EOL Firefox/Icedove then or
> >> try to support this for longer?
> >>
> >> I have no idea what features of gcc-4.8 would be required, Mike do you
> >> know?
> > 
> > Some C++11 features it supports that GCC 4.7 doesn't.
> 
> We may want / need to backport GCC 4.8 to Wheezy then. Chromium is already
> unsupported, so it's either that, or leave Wheezy with no supported browsers. 
> We
> probably want the former.

I too think I would be good to support Firefox & Icedove until Wheezy
goes EOL. Wd could backport gcc 4.8 from Jessie with only C/C++ enabled.

Cheers,
 -- Guido

Re: Security update of nettle

[Andreas Metzler]

On 2016-08-07 Ola Lundqvist  wrote:
> On Sat, Aug 6, 2016 at 8:40 PM, Niels Möller  wrote:
>> Ola Lundqvist  writes:
>>> Magnus, Niels and I have been discussing the nettle update due to
>>> https://security-tracker.debian.org/tracker/CVE-2016-6489

>> Please note that some coordinatoino with gnutls may be needed, to avoid
>> a denial-of-service problem involving invalid private keys.

>>> I suggest something like this: "Protect against potential timing
>>> attacks against exponentiation operations as described in
>>> CVE-2016-6489 RSA code is vulnerable to cache sharing related
>>> attacks."

>> I'd suggest the more general "side-channel attacks" over "timing
>> attacks".

> I do not think coordination with gnutls is needed. I can not see that
> gnutls depend on nettle in wheezy.
> I can see that it can potentially do that, but I do not think it do.

> There are no dependencies declared on nettle library and from unstable
> changelog it looks like this build dependency was first added in gnutls28.
> Wheezy has gnutls28.

> I may be wrong however.

> Or can it be so that nettle is built in statically and that a build
> dependency is not needed as some other package has a build dependency so we
> get it indirectly?

> I'm including the gnutls maintainers to get their opinion.


Hello Ola,

I think I am missing a little bit context, according to the security
tracker the issue applies to practically all versions of, from oldstable
up to and including unstable but the discussion seems to focus on LTS.

You are right regarding wheezy/oldstable. It shipped gnutls 2.12.x built
against libgcrypt instead of nettle, there should not be a problem with
a nettle update. 3.3.8 (using nettle) is in wheezy-backports, but that
is not covered by LTS afaiu.

I am wondering about stable/testing/sid though.
https://security-tracker.debian.org/tracker/CVE-2016-6489 points to
"Original patch had some unintended side effects:", e.g. breaking
GnuTLS. There is a lot of discussion following, however I failed to get
whether the followup patches commited to nettle git did away with the
"unintended side effects" or whether we still need to coordinate for
stable/testing/sid?

cu Andreaas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'