Re: working for wheezy-security until wheezy-lts starts

[Ben Hutchings]

On Wed, 2016-04-13 at 21:51 +1000, Brian May wrote:
[...]
> (dvswitch)
[...]

This is known to be broken with newer libav and has not been fixed
upstream.  (I think I was able to make it build, but it then crashed at
run-time.)  Definitely a candidate for removal.

Ben.

-- 
Ben Hutchings
Larkinson's Law: All laws are basically false.


signature.asc
Description: This is a digitally signed message part

Re: working for wheezy-security until wheezy-lts starts

[Brian May]

Brian May  writes:

> So guessing the solution might be to backport the stretch version to
> wheezy?

Backporting ffmpeg could prove challenging, this is the version from
jessie-backports:

The following packages have unmet dependencies:
 sbuild-build-depends-ffmpeg-dummy : Depends: debhelper (>= 9.20141010) but it 
is not going to be installed
 Depends: dpkg-dev (>= 1.17.14) but 1.16.17 
is to be installed
 Depends: libgnutls28-dev but it is not 
installable
 Depends: libopencv-dev but it is not going 
to be installed
 Depends: libshine-dev (>= 3.0.0) but it is 
not installable
 Depends: libsoxr-dev but it is not 
installable
 Depends: libssh-gcrypt-dev but it is not 
installable
 Depends: libx265-dev but it is not 
installable
 Depends: libzmq3-dev but it is not 
installable
 Depends: cleancss but it is not installable
 Depends: node-less but it is not 
installable
E: Unable to correct problems, you have held broken packages.

Some of these packages may be packages that that I still have to fix
(maybe libopencv at a guess), there are a number of extra packages there
however.
-- 
Brian May 

Re: working for wheezy-security until wheezy-lts starts

[Brian May]

Brian May  writes:

> libpostproc-dev will be uninstallable - does this matter?

Whoops. Just noticed that libpostproc-dev is provided by the old libav,
however not provided by the new libav. I had thought it was another
source package.

So any packages that depend on it will need to be fixed not to depend on
it.
-- 
Brian May 

Re: working for wheezy-security until wheezy-lts starts

[Holger Levsen]

On Thu, Apr 21, 2016 at 11:19:18AM +1000, Brian May wrote:
> Is any binary packages going to break if we just upload the new libav
> without changing anything else? Does it matter if this causes FTBFS in
> supported packages before if/we fix them too?

yes, if you break packages like this you cannot fix them if other more
severe problems show up in those packages. 


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: working for wheezy-security until wheezy-lts starts

[Brian May]

Brian May  writes:
> The current list of packages that fail to build against the new libav is
> (the building is still ongoing):

All build logs in
https://people.debian.org/~bam/wheezy/libav/amd64/buildlogs/

Looks like a total of 85 packages failed to build and 46 packages
succeeded. So me thinks this strategy of using the Jessie version in
wheezy may not be a feasible option.
-- 
Brian May 

Re: working for wheezy-security until wheezy-lts starts

[Brian May]

Brian May  writes:

> The following packages have unmet dependencies:
>  libpostproc-dev : Depends: libavutil-dev (= 6:0.8.17-2) but 6:11.6-1~deb7u1 
> is to be installed
> E: Unable to correct problems, you have held broken packages.

Ok, so looks like we would need a new version of libpostproc-dev without
this very specific depends. This has caused a number of packages to Fail
when building.

However, there seems to be a large number of packages that would need
fixing because they fail to build with the new libav, so am now
wondering if updating to this libav is not going to be such a good idea.

The current list of packages that fail to build against the new libav is
(the building is still ongoing):

buildlogs/acoustid-fingerprinter_0.4-2:Status: attempted
buildlogs/amarok_2.6~beta1+75.g47e75df-1:Status: attempted
buildlogs/amide_1.0.1-1:Status: attempted
buildlogs/audacious-plugins_3.2.4-1:Status: attempted
buildlogs/audacity_2.0.1-1:Status: attempted
buildlogs/avbin_7-1.3:Status: attempted
buildlogs/blender_2.63a-1+deb7u1:Status: attempted
buildlogs/chromaprint_0.6-2:Status: attempted
buildlogs/dvswitch_0.8.3.6-1:Status: attempted
buildlogs/ffdiaporama_1.3-1:Status: attempted
buildlogs/ffmpegthumbnailer_2.0.7-2:Status: attempted
buildlogs/forked-daapd_0.19gcd-2.1:Status: attempted
buildlogs/freerdp_1.0.1-1.1+deb7u3:Status: attempted
buildlogs/gnash_0.8.11~git20120629-1+deb7u1:Status: attempted
buildlogs/gpac_0.5.0~dfsg0-1:Status: attempted
buildlogs/idjc_0.8.7-2:Status: attempted
buildlogs/imageshack-uploader_2.2+hg20100408.d802dea89428-5.1:Status: attempted
buildlogs/kid3_2.1-2:Status: attempted
buildlogs/kino_1.3.4-1.3:Status: attempted
buildlogs/libavg_1.7.1-1:Status: attempted
buildlogs/libphash_0.9.4-1.2:Status: attempted
buildlogs/libquicktime_2:1.2.4-3:Status: attempted
buildlogs/linphone_3.5.2-10:Status: attempted
buildlogs/lives_1.6.2~ds1-2:Status: attempted
buildlogs/lynkeos.app_1.2-6:Status: attempted
buildlogs/mlt_0.8.0-4:Status: attempted
buildlogs/mpd_0.16.7-2:Status: attempted
buildlogs/opencv_2.3.1-11+deb7u1:Status: attempted
buildlogs/performous_0.6.1-6:Status: attempted
buildlogs/picard_1.0-1:Status: attempted
buildlogs/qmmp_0.5.5-1:Status: attempted
buildlogs/qutecom_2.2.1+dfsg1-3:Status: attempted
buildlogs/spek_0.7-3:Status: attempted
buildlogs/taoframework_2.1.svn20090801-9:Status: attempted
buildlogs/tupi_0.1+git12-6:Status: attempted
buildlogs/xmms2_0.8+dfsg-4+deb7u1:Status: attempted
buildlogs/xpra_0.3.11+dfsg-1:Status: attempted

Typical reason for failure is undefined macros, by the looks of it.
-- 
Brian May 

Re: DSA for lxc CVE-2015-1335 [was Re: working for wheezy-security until wheezy-lts starts]

[Salvatore Bonaccorso]

Hi Guido,

On Mon, Mar 28, 2016 at 11:49:55AM +0200, Guido Günther wrote:
> Hi Salvatore,
> On Mon, Mar 28, 2016 at 07:32:38AM +0200, Salvatore Bonaccorso wrote:
> > Hi Guido,
> > 
> > On Sun, Mar 27, 2016 at 04:15:10PM +0200, Guido Günther wrote:
> [..snip..]
> > > O.k. to grab lxc fixing CVE-2015-1335 to dsa-needed ?
> > 
> > Honestly I tend to actually mark this as no-dsa. My argument is the
> > following: LXC in wheezy was in a really early stage, and a local
> > container admin/root inside the container can do basically anything on
> > the host.  Furthermore proper confinement methods were afaik neither
> > implemented and only came with later versions (even in Jessie I think
> > that's not yet working all correctly).
> > 
> > https://blog.bofh.it/debian/id_413
> > 
> > Does that makes sense? We thus initially only addressed that specific
> > CVE only in Jessie.
> 
> After looking into this in more detail yesterday and today I tend to
> agree. Although there is some confinement dropping privileges only a
> small set is used by default and we don't have a apparmor policy in
> place for wheezy either. 
> 
> I've marked this as no-dsa in wheezy (hope that's o.k.) but am happy to
> revisit this if others disagre#e.
> 
> (cc'ing the lts list since we provided a patch for Squeeze)

Yes that's fine. Thanks for double-checking and confirming.

Regards,
Salvatore


signature.asc
Description: PGP signature

Re: DSA for lxc CVE-2015-1335 [was Re: working for wheezy-security until wheezy-lts starts]

[Guido Günther]

Hi Salvatore,
On Mon, Mar 28, 2016 at 07:32:38AM +0200, Salvatore Bonaccorso wrote:
> Hi Guido,
> 
> On Sun, Mar 27, 2016 at 04:15:10PM +0200, Guido Günther wrote:
[..snip..]
> > O.k. to grab lxc fixing CVE-2015-1335 to dsa-needed ?
> 
> Honestly I tend to actually mark this as no-dsa. My argument is the
> following: LXC in wheezy was in a really early stage, and a local
> container admin/root inside the container can do basically anything on
> the host.  Furthermore proper confinement methods were afaik neither
> implemented and only came with later versions (even in Jessie I think
> that's not yet working all correctly).
> 
> https://blog.bofh.it/debian/id_413
> 
> Does that makes sense? We thus initially only addressed that specific
> CVE only in Jessie.

After looking into this in more detail yesterday and today I tend to
agree. Although there is some confinement dropping privileges only a
small set is used by default and we don't have a apparmor policy in
place for wheezy either. 

I've marked this as no-dsa in wheezy (hope that's o.k.) but am happy to
revisit this if others disagre#e.

(cc'ing the lts list since we provided a patch for Squeeze)

Cheers,
 -- Guido

DSA for lxc CVE-2015-1335 [was Re: working for wheezy-security until wheezy-lts starts]

[Guido Günther]

Hi,
On Tue, Mar 01, 2016 at 08:01:20PM +0100, Moritz Muehlenhoff wrote:
> On Tue, Mar 01, 2016 at 02:08:56PM +, Sébastien Delafond wrote:
> > On 2016-03-01, Mike Gabriel  wrote:
> > > @Security Team: Shall we (LTS contributors) handle wheezy-security  
> > > updates like described below until Debian wheezy LTS comes into play?
> > >
> > >o Pick a package that has open CVE issues in wheezy, e.g. from 
> > >  above list
> > >o Add the package to data/dsa-needed.txt, if not already there:
> 
> Don't add anything to dsa-needed.txt directly, but rather ask team@ first 
> whether this actually qualifies for a DSA. Packages get only added there
> after individual assessment.

O.k. to grab lxc fixing CVE-2015-1335 to dsa-needed ?

Cheers,
 -- Guido

Re: working for wheezy-security until wheezy-lts starts

[Brian May]

Antoine Beaupré  writes:

> I am not aware of any such tool. How did you do the following comparison
> - by hand?

Yes, I did.

What I imagine is having same tool that will look at an input file
(e.g. debian/changelog) and find everything that looks like a CVE, and
then compare against distribution X in
https://security-tracker.debian.org/tracker/CVE-2015-8104

Of course, might be worth waiting to see what happens to CVEs first.

>> Not fixed in backported Ubuntu precise version 4.1.6.1-0ubuntu0.12.04.10:
>> - CVE-2014-5146 (marked No DSA)
>> - CVE-2014-5149 (marked No DSA)
>> - CVE-2014-8104 (marked vulnerable; description says "Linux kernel
>> through 4.2.6" not sure if this means it is fixed or broken by 4.2.6)
>> - CVE-2014-8341 (marked No DSA)
>
> 2014-8104 is probably a typo, as it concerns OpenVPN according to the
> security tracker. You probably mean CVE-2015-8104...

Yes, that looks like a typo. Thanks for the correction.

> That is an impressive list, and it does seem like we should merge our
> efforts with Ubuntu here!

Agreed.
-- 
Brian May 

Re: working for wheezy-security until wheezy-lts starts

[Antoine Beaupré]

On 2016-03-21 19:16:24, Brian May wrote:
> Brian May  writes:
>
>>> Wonder how many of the CVEs the Ubuntu version fixes.
>>
>> Will have a look at this now.
>
> Comparing the changelog with our security tracker (by hand; not sure if
> anybody has written a tool to automate this, if not might be a good
> idea):

I am not aware of any such tool. How did you do the following comparison
- by hand?

> Not fixed in backported Ubuntu precise version 4.1.6.1-0ubuntu0.12.04.10:
> - CVE-2014-5146 (marked No DSA)
> - CVE-2014-5149 (marked No DSA)
> - CVE-2014-8104 (marked vulnerable; description says "Linux kernel
> through 4.2.6" not sure if this means it is fixed or broken by 4.2.6)
> - CVE-2014-8341 (marked No DSA)

2014-8104 is probably a typo, as it concerns OpenVPN according to the
security tracker. You probably mean CVE-2015-8104...

I'll look at what that one implies specifically.

> Fixed in backported Ubuntu precise version 4.1.6.1-0ubuntu0.12.04.10:
> - CVE-2015-2152 / XSA-119
> - CVE-2015-2752 / XSA-125
> - CVE-2015-2756 / XSA-126
> - CVE-2015-3259 / XSA-137
> - CVE-2015-5165 / XSA-140
> - CVE-2015-5307 / XSA-156
> - CVE-2015-7504 / XSA-162 (not in Debian security tracker)
> - CVE-2015-7969 / XSA-149
> - CVE-2015-7970 / XSA-150
> - CVE-2015-7971 / XSA-152
> - CVE-2015-7972 / XSA-153
> - CVE-2015-8339, CVE-2015-8340 / XSA-159
> - CVE-2015-8550 / XSA-155
> - CVE-2015-8554 / XSA-164
> - CVE-2015-8555 / XSA-165
> - TEMP-000-CE3B44 / XSA-166  
> - CVE-2016-1570 / XSA-167
> - CVE-2016-1571 / XSA-168
> - CVE-2016-2270 / XSA-154
> - CVE-2016-2271 / XSA-170

That is an impressive list, and it does seem like we should merge our
efforts with Ubuntu here!

I was thinking that maybe there should be an announcement of the release
switch, but looking at the release notes of 4.1.5 and 4.1.6, it seems
just logical to follow those directly:

http://www.xenproject.org/downloads/xen-archives/supported-xen-41-series/xen-4161.html
http://www.xenproject.org/downloads/xen-archives/supported-xen-41-series/xen-415.html

... only bugfixes and CVEs there.

-- 
I've got to design so you can put it together out of garbage cans. In
part because that's what I started from, but mostly because I don’t
trust the industrial structure—they might decide to suppress us
weirdos and try to deny us the parts we need.
   - Lee Felsenstein

Re: working for wheezy-security until wheezy-lts starts

[Brian May]

Brian May  writes:

>> Wonder how many of the CVEs the Ubuntu version fixes.
>
> Will have a look at this now.

Comparing the changelog with our security tracker (by hand; not sure if
anybody has written a tool to automate this, if not might be a good
idea):

Not fixed in backported Ubuntu precise version 4.1.6.1-0ubuntu0.12.04.10:
- CVE-2014-5146 (marked No DSA)
- CVE-2014-5149 (marked No DSA)
- CVE-2014-8104 (marked vulnerable; description says "Linux kernel
through 4.2.6" not sure if this means it is fixed or broken by 4.2.6)
- CVE-2014-8341 (marked No DSA)

Fixed in backported Ubuntu precise version 4.1.6.1-0ubuntu0.12.04.10:
- CVE-2015-2152 / XSA-119
- CVE-2015-2752 / XSA-125
- CVE-2015-2756 / XSA-126
- CVE-2015-3259 / XSA-137
- CVE-2015-5165 / XSA-140
- CVE-2015-5307 / XSA-156
- CVE-2015-7504 / XSA-162 (not in Debian security tracker)
- CVE-2015-7969 / XSA-149
- CVE-2015-7970 / XSA-150
- CVE-2015-7971 / XSA-152
- CVE-2015-7972 / XSA-153
- CVE-2015-8339, CVE-2015-8340 / XSA-159
- CVE-2015-8550 / XSA-155
- CVE-2015-8554 / XSA-164
- CVE-2015-8555 / XSA-165
- TEMP-000-CE3B44 / XSA-166  
- CVE-2016-1570 / XSA-167
- CVE-2016-1571 / XSA-168
- CVE-2016-2270 / XSA-154
- CVE-2016-2271 / XSA-170
-- 
Brian May 

Re: working for wheezy-security until wheezy-lts starts

[Brian May]

Brian May  writes:

> So one possible strategy might be to take Ubuntu's package as is and
> port it to Debian wheezy.

Have rebuilt Ubuntu's xen package for wheezy.

The results are available for testing.
https://people.debian.org/~bam/wheezy/xen/

The most significant change I had to remove the
tools-firmware-etherboot-fix-e1000.patch file because Debian wheezy
doesn't have the 8086100e.rom but it does have the e1000_82540.rom file.

 cut 
UBUNTU: Fix pxe boot with e1000 emulation

This seems to be a slight revert as the same rom name has been used before.
The main problem is that ipxe builds the e1000_82540.rom with invalid
pci id in the rom header. Which is required by the hvmloader.
The 8086100e.rom is just the same but with a name the build engine can
cope with.

Signed-off-by: Stefan Bader 
Index: xen-4.1.2/tools/firmware/etherboot/Config
===
--- xen-4.1.2.orig/tools/firmware/etherboot/Config  2012-03-06 
20:50:36.0 +0100
+++ xen-4.1.2/tools/firmware/etherboot/Config   2012-03-06 20:54:11.275153857 
+0100
@@ -1,5 +1,5 @@
 
-NICS = rtl8139 e1000_82540
+NICS = rtl8139 8086100e
 
 CFLAGS += -UPXE_DHCP_STRICT
 CFLAGS += -DPXE_DHCP_STRICT
 cut 

> Wonder how many of the CVEs the Ubuntu version fixes.

Will have a look at this now.
-- 
Brian May 

Re: working for wheezy-security until wheezy-lts starts

[Brian May]

Moritz Muehlenhoff  writes:

> It was pointed out on IRC that Ubuntu precise has a Xen 4.1 package, so
> you might want to compare fixes with their package.

Thanks for this. I will check this out later when I have more time.

Just a very quick glance for now:

Debian wheezy has 4.1.4, Ubuntu precise has 4.1.6; no idea if this
matters. Am speculating that 4.1.6 might have security updates.

So one possible strategy might be to take Ubuntu's package as is and
port it to Debian wheezy.

Wonder how many of the CVEs the Ubuntu version fixes.
-- 
Brian May 

Re: working for wheezy-security until wheezy-lts starts

[Moritz Muehlenhoff]

On Wed, Mar 16, 2016 at 02:27:15PM +1100, Brian May wrote:
> Guido Günther  writes:>
> 
> > Sid has Xen 4.6 and looking at the CVEs that affect sid the patches
> > don't seem to be applied so the tracker looks correct, there's plenty of
> > work left.
> >
> > Are you going to look at the Wheezy packages?
> 
> Looking now.

It was pointed out on IRC that Ubuntu precise has a Xen 4.1 package, so
you might want to compare fixes with their package.

Cheers,
Moritz

Re: working for wheezy-security until wheezy-lts starts

[Guido Günther]

On Wed, Mar 16, 2016 at 02:27:15PM +1100, Brian May wrote:
> Guido Günther  writes:>
> 
> > Sid has Xen 4.6 and looking at the CVEs that affect sid the patches
> > don't seem to be applied so the tracker looks correct, there's plenty of
> > work left.
> >
> > Are you going to look at the Wheezy packages?
> 
> Looking now.
> 
> Just looking at CVE-2015-2756 - this appears to be a vulnerability in
> qemu - not xen - and squeeze and wheezy are not affected.
> 
> https://security-tracker.debian.org/tracker/CVE-2015-2756

The patches provided with the xsa seem to apply to the embedded qemu
copy of xen 4.1.4 but I did not check if a HVM guest can exploit this.

Cheers,
 -- Guido

Re: working for wheezy-security until wheezy-lts starts

[Brian May]

Have attached patches for two security issues in the wheezy version.

CVE-2015-2752.diff
CVE-2015-8104+CVE-2015-5307.patch

Not tested in anyway, except they apply ok.

Am currently looking at CVE-2015-7969; I am beginning to think wheezy is
not vulnerable. Still need to double check this.

Out of time now, will continue looking at this later.
-- 
Brian May 
>From 16794c97e99228ca551ff09fa696d00f39ceee82 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Wed, 19 Nov 2014 12:57:11 -0500
Subject: Limit XEN_DOMCTL_memory_mapping hypercall to only process up to 64
 GFNs (or less)

Said hypercall for large BARs can take quite a while. As such
we can require that the hypercall MUST break up the request
in smaller values.

Another approach is to add preemption to it - whether we do the
preemption using hypercall_create_continuation or returning
EAGAIN to userspace (and have it re-invocate the call) - either
way the issue we cannot easily solve is that in 'map_mmio_regions'
if we encounter an error we MUST call 'unmap_mmio_regions' for the
whole BAR region.

Since the preemption would re-use input fields such as nr_mfns,
first_gfn, first_mfn - we would lose the original values -
and only undo what was done in the current round (i.e. ignoring
anything that was done prior to earlier preemptions).

Unless we re-used the return value as 'EAGAIN|nr_mfns_done<<10' but
that puts a limit (since the return value is a long) on the amount
of nr_mfns that can provided.

This patch sidesteps this problem by:
 - Setting an hard limit of nr_mfns having to be 64 or less.
 - Toolstack adjusts correspondingly to the nr_mfn limit.
 - If the there is an error when adding the toolstack will call the
   remove operation to remove the whole region.

The need to break this hypercall down is for large BARs can take
more than the guest (initial domain usually) time-slice. This has
the negative result in that the guest is locked out for a long
duration and is unable to act on any pending events.

We also augment the code to return zero if nr_mfns instead
of trying to the hypercall.

This is XSA-125 / CVE-2015-2752.

Suggested-by: Jan Beulich 
Acked-by: Jan Beulich 
Signed-off-by: Konrad Rzeszutek Wilk 
Acked-by: Ian Campbell 
(cherry picked from commit 518ae14973a44228fd7158c3d70270df6ed90033)

Patch-Name: CVE-2015-2752.diff
---
 tools/libxc/xc_domain.c | 55 -
 xen/arch/x86/domctl.c   |  5 +
 xen/include/public/domctl.h |  1 +
 3 files changed, 56 insertions(+), 5 deletions(-)

--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1322,6 +1322,13 @@
   PT_IRQ_TYPE_ISA, 0, 0, 0, machine_irq));
 }
 
+#ifndef min
+#define min(X, Y) ({ \
+const typeof (X) _x = (X);   \
+const typeof (Y) _y = (Y);   \
+(void) (&_x == &_y); \
+(_x < _y) ? _x : _y; })
+#endif
 int xc_domain_memory_mapping(
 xc_interface *xch,
 uint32_t domid,
@@ -1331,17 +1338,55 @@
 uint32_t add_mapping)
 {
 DECLARE_DOMCTL;
+int ret = 0, err;
+unsigned long done = 0, nr, max_batch_sz;
+
+if ( !nr_mfns )
+return 0;
 
 domctl.cmd = XEN_DOMCTL_memory_mapping;
 domctl.domain = domid;
-domctl.u.memory_mapping.first_gfn = first_gfn;
-domctl.u.memory_mapping.first_mfn = first_mfn;
-domctl.u.memory_mapping.nr_mfns = nr_mfns;
 domctl.u.memory_mapping.add_mapping = add_mapping;
+max_batch_sz = nr_mfns;
+do
+{
+nr = min(nr_mfns - done, max_batch_sz);
+domctl.u.memory_mapping.nr_mfns = nr;
+domctl.u.memory_mapping.first_gfn = first_gfn + done;
+domctl.u.memory_mapping.first_mfn = first_mfn + done;
+err = do_domctl(xch, );
+if ( err && errno == E2BIG )
+{
+if ( max_batch_sz <= 1 )
+break;
+max_batch_sz >>= 1;
+continue;
+}
+/* Save the first error... */
+if ( !ret )
+ret = err;
+/* .. and ignore the rest of them when removing. */
+if ( err && add_mapping != DPCI_REMOVE_MAPPING )
+break;
 
-return do_domctl(xch, );
-}
+done += nr;
+} while ( done < nr_mfns );
+
+/*
+ * Undo what we have done unless unmapping, by unmapping the entire region.
+ * Errors here are ignored.
+ */
+if ( ret && add_mapping != DPCI_REMOVE_MAPPING )
+xc_domain_memory_mapping(xch, domid, first_gfn, first_mfn, nr_mfns,
+ DPCI_REMOVE_MAPPING);
 
+/* We might get E2BIG so many times that we never advance. */
+if ( !done && !ret )
+ret = -1;
+
+return ret;
+}
+#undef min
 int xc_domain_ioport_mapping(
 xc_interface *xch,
 uint32_t domid,
--- 

Re: working for wheezy-security until wheezy-lts starts

[Brian May]

Guido Günther  writes:>

> Sid has Xen 4.6 and looking at the CVEs that affect sid the patches
> don't seem to be applied so the tracker looks correct, there's plenty of
> work left.
>
> Are you going to look at the Wheezy packages?

Looking now.

Just looking at CVE-2015-2756 - this appears to be a vulnerability in
qemu - not xen - and squeeze and wheezy are not affected.

https://security-tracker.debian.org/tracker/CVE-2015-2756

Looking at xen in jessie, there is no changelog entry mentioning
CVE-2015-2756; although it is marked as fixed.

The closest I can find is https://bugs.debian.org/781620 and this
doesn't mention how CVE-2015-2756 was fixed.

The only reason xen appears to be mentioned is because it can use a
vulnerable version of qemu; It doesn't appear to have the vulnerable
code itself.

See: http://xenbits.xen.org/xsa/advisory-126.html

So I am wondering if I can just mark xen in squeeze and wheezy as not
being affected by CVE-2015-2756 too?
-- 
Brian May 

Re: working for wheezy-security until wheezy-lts starts

[Moritz Mühlenhoff]

On Sun, Mar 13, 2016 at 12:52:09PM +0100, Guido Günther wrote:
> Looking at
> 
> 
> http://metadata.ftp-master.debian.org/changelogs/main/x/xen/xen_4.1.4-3+deb7u9_changelog
> 
> and the source package the current practice is to pull in the individual 
> patches.

Ack.

> I wonder if somebody can give some hints how current Xen updates are
> being tested? Since running xen in KVM is works in some KVM/Xen
> combinations but not others (and doesn't allow for HVM testing). Do we
> have some test suite? If not I'd set out to build one if we want to
> support this in LTS.

They're being tested on live systems, there's a few volunteers who're
running this. I can dig out the contact addresses once the package
for wheezy is ready.

Cheers,
Moritz

Re: working for wheezy-security until wheezy-lts starts

[Guido Günther]

Hi Brian,
On Sun, Mar 13, 2016 at 11:13:31AM +1100, Brian May wrote:
> Moritz Mühlenhoff  writes:
> 
> > 1. We're already one wheezy update behind for xen (since some of
> > the changes were invasive and complex). It would be great if
> > someone from the Freexian sponsor pool would work on a wheezy
> > update for Xen. It's probably a solid day of work, though, but
> > it will also clarify whether it's feasible to continue to support
> > in Xen in Wheezy LTS (while 4.1 being EOLed by upstream for
> > quite a while now).
> 
> So what needs to happen here? Not sure what is meant by "We're already
> one wheezy update behind for xen".
> 
> I see wheezy has version 4.1.4-3+deb7u8 - do we need to attempt to
> update this to version 4.1.6.1 - the latest 4.1.* version?

Looking at


http://metadata.ftp-master.debian.org/changelogs/main/x/xen/xen_4.1.4-3+deb7u9_changelog

and the source package the current practice is to pull in the individual 
patches.

> 
> If so I imagine this would require:
> 
> - identifying which CVEs are fixed in 4.1.6.1
> - updating xen package
> - updating the kernel packages (if this is required??? Not sure if the
>   kernel code is considered part of the xen release or not anymore)

The hypervisor (dom0) is built from Xen sources:

https://packages.debian.org/wheezy/xen-hypervisor-4.1-i386

while the PV guests use the "regular" linux kernel

https://packages.debian.org/wheezy/xen-linux-system-3.2.0-4-amd64

so I read this that the linux kernel only needs to be updated if guest parts
are affected.

> and/or do we attempt to backport the security patches from some newer
> release?
> 
> I also note that there are a large number of unfixed vulnerabilities for
> all versions including sid.
> 
> https://security-tracker.debian.org/tracker/source-package/xen

Sid has Xen 4.6 and looking at the CVEs that affect sid the patches
don't seem to be applied so the tracker looks correct, there's plenty of
work left.

Are you going to look at the Wheezy packages?

I wonder if somebody can give some hints how current Xen updates are
being tested? Since running xen in KVM is works in some KVM/Xen
combinations but not others (and doesn't allow for HVM testing). Do we
have some test suite? If not I'd set out to build one if we want to
support this in LTS.

Cheers,
 -- Guido

Re: working for wheezy-security until wheezy-lts starts

[Markus Koschany]

Am 13.03.2016 um 04:32 schrieb Brian May:
> Brian May  writes:
> 
>>> 2. Spend some time on investigating what it takes to backport
>>> libav from jessie to wheezy. 11.x is still supported by
>>> libav upstream and we could share triage work for jessie/wheezy
>>> going forwards. 0.8 has simply too much missing.
>>> There will be a few applications which are going to break due to
>>> API changes, possibly exclude some exotic ones from wheezy LTS
>>> support and backport some fixes for important apps from jessie.
>>> (Most of the changes are fairly straightforward, e.g. they renamed
>>> lots of internal constants).
> 
> Am I suppose to mark anywhere that I am now working on libav???

Hi Brian,

you could add your name to one of the existing TODO items at
https://wiki.debian.org/LTS/TODO or create new ones as you see fit.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Re: working for wheezy-security until wheezy-lts starts

[Brian May]

Brian May  writes:

>> 2. Spend some time on investigating what it takes to backport
>> libav from jessie to wheezy. 11.x is still supported by
>> libav upstream and we could share triage work for jessie/wheezy
>> going forwards. 0.8 has simply too much missing.
>> There will be a few applications which are going to break due to
>> API changes, possibly exclude some exotic ones from wheezy LTS
>> support and backport some fixes for important apps from jessie.
>> (Most of the changes are fairly straightforward, e.g. they renamed
>> lots of internal constants).

Am I suppose to mark anywhere that I am now working on libav???

Looks like this will be the first thing I need to "fix":

The following packages have unmet dependencies:
 sbuild-build-depends-libav-dummy : Depends: libfreetype6-dev (>= 2.5.1) but 
2.4.9-1.1+deb7u1 is to be installed
Depends: libgnutls28-dev but it is not 
installable
Depends: libopus-dev (>= 1.0.1) but it is 
not going to be installed

Will see if I can get it to build with what is available in wheezy.
-- 
Brian May 

Re: working for wheezy-security until wheezy-lts starts

[Brian May]

Moritz Mühlenhoff  writes:

> 1. We're already one wheezy update behind for xen (since some of
> the changes were invasive and complex). It would be great if
> someone from the Freexian sponsor pool would work on a wheezy
> update for Xen. It's probably a solid day of work, though, but
> it will also clarify whether it's feasible to continue to support
> in Xen in Wheezy LTS (while 4.1 being EOLed by upstream for
> quite a while now).

So what needs to happen here? Not sure what is meant by "We're already
one wheezy update behind for xen".

I see wheezy has version 4.1.4-3+deb7u8 - do we need to attempt to
update this to version 4.1.6.1 - the latest 4.1.* version?

If so I imagine this would require:

- identifying which CVEs are fixed in 4.1.6.1
- updating xen package
- updating the kernel packages (if this is required??? Not sure if the
  kernel code is considered part of the xen release or not anymore)

and/or do we attempt to backport the security patches from some newer
release?

I also note that there are a large number of unfixed vulnerabilities for
all versions including sid.

https://security-tracker.debian.org/tracker/source-package/xen


> 2. Spend some time on investigating what it takes to backport
> libav from jessie to wheezy. 11.x is still supported by
> libav upstream and we could share triage work for jessie/wheezy
> going forwards. 0.8 has simply too much missing.
> There will be a few applications which are going to break due to
> API changes, possibly exclude some exotic ones from wheezy LTS
> support and backport some fixes for important apps from jessie.
> (Most of the changes are fairly straightforward, e.g. they renamed
> lots of internal constants).

Looks like the SONAME has changed. Presumably this means anything
depending on libav will need to be rebuilt?

How do we handle any packages that might be broken and cannot (feasibly)
be fixed?

As there are multiple packages involved, is it possible to stage them
somewhere and get all packages moved in one atomic operation or do we
have to do them one at a time? The later could be potentially risky and
break things if both versions end up being included in the one
application, especially if versioned symbols not used (I haven't
checked).
-- 
Brian May 

Re: working for wheezy-security until wheezy-lts starts

[Moritz Muehlenhoff]

On Tue, Mar 01, 2016 at 02:08:56PM +, Sébastien Delafond wrote:
> On 2016-03-01, Mike Gabriel  wrote:
> > @Security Team: Shall we (LTS contributors) handle wheezy-security  
> > updates like described below until Debian wheezy LTS comes into play?
> >
> >o Pick a package that has open CVE issues in wheezy, e.g. from 
> >  above list
> >o Add the package to data/dsa-needed.txt, if not already there:

Don't add anything to dsa-needed.txt directly, but rather ask team@ first 
whether this actually qualifies for a DSA. Packages get only added there
after individual assessment.

Cheers,
Moritz

Re: working for wheezy-security until wheezy-lts starts

[Sébastien Delafond]

On 2016-03-01, Mike Gabriel  wrote:
> @Security Team: Shall we (LTS contributors) handle wheezy-security  
> updates like described below until Debian wheezy LTS comes into play?
>
>o Pick a package that has open CVE issues in wheezy, e.g. from 
>  above list
>o Add the package to data/dsa-needed.txt, if not already there:
>  - packages with issues to be solved in wheezy only, should be
>suffixed with "/oldstable" (i.e., gosa/oldstable)
>  - packages with issues in jessie and wheezy, should probably
>just be added by the package name (without suffix), right?
>
> From then on, the workflow can be the same workflow as used for
> normal security updates (as already described earlier in this
> thread):
>
>o Fix the issue in the package (grab the current package from  
>   oldstable's archive).
>o Test your fixes.
>o Provide a .debdiff to
>  t...@security.debian.org and to the
>  Debian bug, if any related bug exists.
>
>o Wait for feedback from the release team on how to proceed.
>
>o As a courtesy, you could check the same package in jessie and
>  see if the fix for oldstable is easily forward-portable. Thus,
>  maybe providing a jessie-security .debdiff for the package can
>  be an option.
>
> The removal of the entry placed into data/dsa-needed.txt should then
> be handled by the Security Team, once the fixed package version has
> been uploaded.  More Feedback?  Mike

Looking good to me; we can refine the process incrementally, if need
be.

Thanks a lot for the help,

--Seb

Re: working for wheezy-security until wheezy-lts starts

[Mike Gabriel]

On  Di 01 Mär 2016 08:44:08 CET, Guido Günther wrote:


On Tue, Mar 01, 2016 at 07:15:28AM +, Mike Gabriel wrote:
[..snip..]

>>Issues that are unfixed in wheezy but fixed in squeeze:
>>* aptdaemon-> CVE-2015-1323
>>* cakephp  -> TEMP-000-698CF7
>>* dhcpcd   -> CVE-2012-6698 CVE-2012-6699 CVE-2012-6700
>>* eglibc   -> CVE-2014-9761
>>* extplorer-> CVE-2015-0896
>>* fuseiso  -> TEMP-0779047-8CABD5 TEMP-0779047-E29D8E
>>* gosa -> CVE-2014-9760 CVE-2015-8771
>>* gtk+2.0  -> CVE-2013-7447
>>* icu  -> CVE-2015-2632
>>* imagemagick  -> TEMP-0773834-5EB6CF
>>* imlib2   -> CVE-2014-9762 CVE-2014-9763 CVE-2014-9764
>>* inspircd -> CVE-2015-8702
>>* libebml  -> CVE-2015-8790 CVE-2015-8791
>>* libidn   -> CVE-2015-2059 TEMP-000-54045E
>>* libmatroska  -> CVE-2015-8792
>>* libsndfile   -> CVE-2014-9756 CVE-2015-7805
>>* libstruts1.2-java-> CVE-2015-0899
>>* libtorrent-rasterbar -> CVE-2015-5685
>>* mono -> CVE-2009-0689
>>* nss  -> CVE-2015-7181 CVE-2015-7182 CVE-2016-1938
>>* optipng  -> CVE-2015-7801
>>* phpmyadmin   -> CVE-2016-2039 CVE-2016-2041
>>* pixman   -> CVE-2014-9766
>>* python-tornado   -> CVE-2014-9720
>>* roundcube-> CVE-2015-8770
>>* srtp -> CVE-2015-6360
>>* tomcat6  -> CVE-2013-4286 CVE-2013-4322 CVE-2014-0033
>>CVE-2014-0075 CVE-2014-0096 CVE-2014-0099 CVE-2014-0119 CVE-2014-0227
>>CVE-2014-0230 CVE-2014-7810 CVE-2015-5174 CVE-2015-5345 CVE-2015-5351
>>CVE-2016-0706 CVE-2016-0714 CVE-2016-0763
>
>I'm focusing on these picking older ones over newer ones to not stomp
>onto the security teams toes.

Do you announce anywhere, that you will start working on a specific package?
Wouldn't it make sense to put all the packages listed below into
data/dsa-needed.txt (with approval from the Security Team) and then put our
names behind those package names?


In order to avoid double work I added these to dsa-needed.txt and put my
name on the line.

Cheers,
 -- Guido


Ack.

@Security Team: Shall we (LTS contributors) handle wheezy-security  
updates like described below until Debian wheezy LTS comes into play?


  o Pick a package that has open CVE issues in wheezy, e.g. from above list
  o Add the package to data/dsa-needed.txt, if not already there:
- packages with issues to be solved in wheezy only, should be suffixed
  with "/oldstable" (i.e., gosa/oldstable)
- packages with issues in jessie and wheezy, should probably just be added
  by the package name (without suffix), right?

From then on, the workflow can be the same workflow as used for  
normal security updates (as already described earlier in this thread):


  o Fix the issue in the package (grab the current package from  
oldstable's archive).

  o Test your fixes.
  o Provide a .debdiff to t...@security.debian.org and to the Debian bug,
if any related bug exists.
  o Wait for feedback from the release team on how to proceed.
  o As a courtesy, you could check the same package in jessie and see if
the fix for oldstable is easily forward-portable. Thus, maybe providing a
jessie-security .debdiff for the package can be an option.

The removal of the entry placed into data/dsa-needed.txt should then  
be handled by the Security Team, once the fixed package version has  
been uploaded.


More Feedback?
Mike
--

mike gabriel aka sunweaver (Debian Developer)
fon: +49 (1520) 1976 148

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



pgpBSc_26ZXaG.pgp
Description: Digitale PGP-Signatur

Re: working for wheezy-security until wheezy-lts starts

[Guido Günther]

On Tue, Mar 01, 2016 at 07:15:28AM +, Mike Gabriel wrote:
[..snip..]
> >>Issues that are unfixed in wheezy but fixed in squeeze:
> >>* aptdaemon-> CVE-2015-1323
> >>* cakephp  -> TEMP-000-698CF7
> >>* dhcpcd   -> CVE-2012-6698 CVE-2012-6699 CVE-2012-6700
> >>* eglibc   -> CVE-2014-9761
> >>* extplorer-> CVE-2015-0896
> >>* fuseiso  -> TEMP-0779047-8CABD5 TEMP-0779047-E29D8E
> >>* gosa -> CVE-2014-9760 CVE-2015-8771
> >>* gtk+2.0  -> CVE-2013-7447
> >>* icu  -> CVE-2015-2632
> >>* imagemagick  -> TEMP-0773834-5EB6CF
> >>* imlib2   -> CVE-2014-9762 CVE-2014-9763 CVE-2014-9764
> >>* inspircd -> CVE-2015-8702
> >>* libebml  -> CVE-2015-8790 CVE-2015-8791
> >>* libidn   -> CVE-2015-2059 TEMP-000-54045E
> >>* libmatroska  -> CVE-2015-8792
> >>* libsndfile   -> CVE-2014-9756 CVE-2015-7805
> >>* libstruts1.2-java-> CVE-2015-0899
> >>* libtorrent-rasterbar -> CVE-2015-5685
> >>* mono -> CVE-2009-0689
> >>* nss  -> CVE-2015-7181 CVE-2015-7182 CVE-2016-1938
> >>* optipng  -> CVE-2015-7801
> >>* phpmyadmin   -> CVE-2016-2039 CVE-2016-2041
> >>* pixman   -> CVE-2014-9766
> >>* python-tornado   -> CVE-2014-9720
> >>* roundcube-> CVE-2015-8770
> >>* srtp -> CVE-2015-6360
> >>* tomcat6  -> CVE-2013-4286 CVE-2013-4322 CVE-2014-0033
> >>CVE-2014-0075 CVE-2014-0096 CVE-2014-0099 CVE-2014-0119 CVE-2014-0227
> >>CVE-2014-0230 CVE-2014-7810 CVE-2015-5174 CVE-2015-5345 CVE-2015-5351
> >>CVE-2016-0706 CVE-2016-0714 CVE-2016-0763
> >
> >I'm focusing on these picking older ones over newer ones to not stomp
> >onto the security teams toes.
> 
> Do you announce anywhere, that you will start working on a specific package?
> Wouldn't it make sense to put all the packages listed below into
> data/dsa-needed.txt (with approval from the Security Team) and then put our
> names behind those package names?

In order to avoid double work I added these to dsa-needed.txt and put my
name on the line.

Cheers,
 -- Guido

Re: working for wheezy-security until wheezy-lts starts

[Mike Gabriel]

Hi Guido,

On  Mo 29 Feb 2016 21:54:11 CET, Guido Günther wrote:


  * prepare a fixed package
  * test the package
  * send a .debdiff to t...@security.debian.org
  * wait for feedback and ideally permission to upload to wheezy-security


That's what I'm doing at the moment (sending the debdiff to the bug
report in case there is one as well) for issues that are unfixed (not
no-dsa, see below).


Ok.



[..snip..]


Issues that are unfixed in wheezy but fixed in squeeze:
* aptdaemon-> CVE-2015-1323
* cakephp  -> TEMP-000-698CF7
* dhcpcd   -> CVE-2012-6698 CVE-2012-6699 CVE-2012-6700
* eglibc   -> CVE-2014-9761
* extplorer-> CVE-2015-0896
* fuseiso  -> TEMP-0779047-8CABD5 TEMP-0779047-E29D8E
* gosa -> CVE-2014-9760 CVE-2015-8771
* gtk+2.0  -> CVE-2013-7447
* icu  -> CVE-2015-2632
* imagemagick  -> TEMP-0773834-5EB6CF
* imlib2   -> CVE-2014-9762 CVE-2014-9763 CVE-2014-9764
* inspircd -> CVE-2015-8702
* libebml  -> CVE-2015-8790 CVE-2015-8791
* libidn   -> CVE-2015-2059 TEMP-000-54045E
* libmatroska  -> CVE-2015-8792
* libsndfile   -> CVE-2014-9756 CVE-2015-7805
* libstruts1.2-java-> CVE-2015-0899
* libtorrent-rasterbar -> CVE-2015-5685
* mono -> CVE-2009-0689
* nss  -> CVE-2015-7181 CVE-2015-7182 CVE-2016-1938
* optipng  -> CVE-2015-7801
* phpmyadmin   -> CVE-2016-2039 CVE-2016-2041
* pixman   -> CVE-2014-9766
* python-tornado   -> CVE-2014-9720
* roundcube-> CVE-2015-8770
* srtp -> CVE-2015-6360
* tomcat6  -> CVE-2013-4286 CVE-2013-4322 CVE-2014-0033
CVE-2014-0075 CVE-2014-0096 CVE-2014-0099 CVE-2014-0119 CVE-2014-0227
CVE-2014-0230 CVE-2014-7810 CVE-2015-5174 CVE-2015-5345 CVE-2015-5351
CVE-2016-0706 CVE-2016-0714 CVE-2016-0763


I'm focusing on these picking older ones over newer ones to not stomp
onto the security teams toes.


Do you announce anywhere, that you will start working on a specific  
package? Wouldn't it make sense to put all the packages listed below  
into data/dsa-needed.txt (with approval from the Security Team) and  
then put our names behind those package names?


@Security Team: Please guide the LTS contributors to a good way of  
supporting you. Would it make sense to add above packages to  
data/dsa-needed.txt so that then LTS contributors can grab packages  
from the dsa-needed.txt file and work on fixing the listed issues?




Issues that are no-dsa in wheezy but fixed in squeeze:
* augeas   -> CVE-2012-0786 CVE-2012-0787
* binutils -> TEMP-000-A2945B
* busybox  -> TEMP-0803097-A74121
* chrony   -> CVE-2016-1567
* dbconfig-common  -> TEMP-0805638-5AC56F
* dwarfutils   -> CVE-2015-8750
* foomatic-filters -> TEMP-000-ACBC4C
* imagemagick  -> CVE-2014-8354 CVE-2014-8355 CVE-2014-8562
CVE-2014-8716 TEMP-0806441-76CD60 TEMP-0806441-CB092C
* libemail-address-perl -> TEMP-000-F41FA7
* libfcgi-perl -> CVE-2012-6687
* librsvg  -> CVE-2015-7557
* libsndfile   -> CVE-2014-9496
* libunwind-> CVE-2015-3239
* openslp-dfsg -> CVE-2012-4428
* openssh  -> CVE-2015-5352 CVE-2015-5600
* php5 -> CVE-2011-0420 CVE-2011-1657
* postgresql-8.4   -> CVE-2015-3165 CVE-2015-3166 CVE-2015-3167
CVE-2015-5288
* python-scipy -> CVE-2013-4251
* python2.6-> CVE-2011-4940 CVE-2013-4238 CVE-2014-1912
* qt4-x11  -> CVE-2015-0295 CVE-2015-1858 CVE-2015-1859
CVE-2015-1860
* remind   -> CVE-2015-5957
* ruby1.8  -> CVE-2009-5147
* ruby1.9.1-> CVE-2009-5147
* t1utils  -> CVE-2015-3905
* texlive-extra-> CVE-2012-2120
* tomcat6  -> CVE-2013-4590
* vorbis-tools -> CVE-2014-9638 CVE-2014-9639 CVE-2014-9640
CVE-2015-6749
"""


I think these would be adressed via stable point release updates in
wheezy/jessie rather than going via the security team.


Yeah, if at all. I just listed them for completeness sake.

Mike

--

mike gabriel aka sunweaver (Debian Developer)
fon: +49 (1520) 1976 148

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



pgpilfX2MIOoU.pgp
Description: Digitale PGP-Signatur

Re: working for wheezy-security until wheezy-lts starts

[Guido Günther]

Hi,
On Mon, Feb 29, 2016 at 03:25:46PM +, Mike Gabriel wrote:
> For this, we can run bin/lts-needs-forward-port.py from the secure-testing
> repo and see what issues we fixed in squeeze and port those fixes to the
> package version in wheezy-security. Package updates must be coordinated with
> the Debian Security Team, not within the LTS team, though:
> 
>   * prepare a fixed package
>   * test the package
>   * send a .debdiff to t...@security.debian.org
>   * wait for feedback and ideally permission to upload to wheezy-security

That's what I'm doing at the moment (sending the debdiff to the bug
report in case there is one as well) for issues that are unfixed (not
no-dsa, see below).

[..snip..]

> Issues that are unfixed in wheezy but fixed in squeeze:
> * aptdaemon-> CVE-2015-1323
> * cakephp  -> TEMP-000-698CF7
> * dhcpcd   -> CVE-2012-6698 CVE-2012-6699 CVE-2012-6700
> * eglibc   -> CVE-2014-9761
> * extplorer-> CVE-2015-0896
> * fuseiso  -> TEMP-0779047-8CABD5 TEMP-0779047-E29D8E
> * gosa -> CVE-2014-9760 CVE-2015-8771
> * gtk+2.0  -> CVE-2013-7447
> * icu  -> CVE-2015-2632
> * imagemagick  -> TEMP-0773834-5EB6CF
> * imlib2   -> CVE-2014-9762 CVE-2014-9763 CVE-2014-9764
> * inspircd -> CVE-2015-8702
> * libebml  -> CVE-2015-8790 CVE-2015-8791
> * libidn   -> CVE-2015-2059 TEMP-000-54045E
> * libmatroska  -> CVE-2015-8792
> * libsndfile   -> CVE-2014-9756 CVE-2015-7805
> * libstruts1.2-java-> CVE-2015-0899
> * libtorrent-rasterbar -> CVE-2015-5685
> * mono -> CVE-2009-0689
> * nss  -> CVE-2015-7181 CVE-2015-7182 CVE-2016-1938
> * optipng  -> CVE-2015-7801
> * phpmyadmin   -> CVE-2016-2039 CVE-2016-2041
> * pixman   -> CVE-2014-9766
> * python-tornado   -> CVE-2014-9720
> * roundcube-> CVE-2015-8770
> * srtp -> CVE-2015-6360
> * tomcat6  -> CVE-2013-4286 CVE-2013-4322 CVE-2014-0033
> CVE-2014-0075 CVE-2014-0096 CVE-2014-0099 CVE-2014-0119 CVE-2014-0227
> CVE-2014-0230 CVE-2014-7810 CVE-2015-5174 CVE-2015-5345 CVE-2015-5351
> CVE-2016-0706 CVE-2016-0714 CVE-2016-0763

I'm focusing on these picking older ones over newer ones to not stomp
onto the security teams toes.

> 
> Issues that are no-dsa in wheezy but fixed in squeeze:
> * augeas   -> CVE-2012-0786 CVE-2012-0787
> * binutils -> TEMP-000-A2945B
> * busybox  -> TEMP-0803097-A74121
> * chrony   -> CVE-2016-1567
> * dbconfig-common  -> TEMP-0805638-5AC56F
> * dwarfutils   -> CVE-2015-8750
> * foomatic-filters -> TEMP-000-ACBC4C
> * imagemagick  -> CVE-2014-8354 CVE-2014-8355 CVE-2014-8562
> CVE-2014-8716 TEMP-0806441-76CD60 TEMP-0806441-CB092C
> * libemail-address-perl -> TEMP-000-F41FA7
> * libfcgi-perl -> CVE-2012-6687
> * librsvg  -> CVE-2015-7557
> * libsndfile   -> CVE-2014-9496
> * libunwind-> CVE-2015-3239
> * openslp-dfsg -> CVE-2012-4428
> * openssh  -> CVE-2015-5352 CVE-2015-5600
> * php5 -> CVE-2011-0420 CVE-2011-1657
> * postgresql-8.4   -> CVE-2015-3165 CVE-2015-3166 CVE-2015-3167
> CVE-2015-5288
> * python-scipy -> CVE-2013-4251
> * python2.6-> CVE-2011-4940 CVE-2013-4238 CVE-2014-1912
> * qt4-x11  -> CVE-2015-0295 CVE-2015-1858 CVE-2015-1859
> CVE-2015-1860
> * remind   -> CVE-2015-5957
> * ruby1.8  -> CVE-2009-5147
> * ruby1.9.1-> CVE-2009-5147
> * t1utils  -> CVE-2015-3905
> * texlive-extra-> CVE-2012-2120
> * tomcat6  -> CVE-2013-4590
> * vorbis-tools -> CVE-2014-9638 CVE-2014-9639 CVE-2014-9640
> CVE-2015-6749
> """

I think these would be adressed via stable point release updates in
wheezy/jessie rather than going via the security team.

Cheers,
 -- Guido