Hi,
I think it would be a good idea to get a DTSA (Debian Testing Security
Advisory) issued for 2.4.27 and 2.6.8.
2.4.27-11 is already in testing, but the number of security bugs fixed in
this version is significant: there are 9 CAN numbers for 2.4.27-11[1]; and 4
other security patches that do not have CVE entries[2]. It seems that it
would be a good idea to do an advisory to alert people that these security
holes have been fixed and that they need to upgrade and reboot if they
haven''t already
2.6.8 is scheduled to be removed from sid, and consequentially in testing as
well, however it may be good to do an advisory to alert those who are
running 2.6.8 to upgrade to linux-2.6 (2.6.12) as the kernel they are
running is not being supported (and the transition is not super obvious) and
the number of security holes for the version in testing (2.6.8-16) adds up
to a whopping 13 CAN numbers[3] and 21 other security patches[4].
Neither of these advisories is a typical DTSA, as we normally we only do
advisories for things that are blocked from reaching testing by some other
issue, but I think that it would be good to do these two advisories because
of the sheer number of security holes fixed as well as the necessary upgrade
path that people need to take if they wish to maintain the integrity of
their machines.
I have begun the work to prepare this advisory for release, we basically
need 2.6.8 to leave the archvie and the 2.6.12 packages to enter testing
before the 2.6.8 DTSA can be released. The DTSA would just list the normal
testing repositories for the upgrade (rather than the secure-testing
repositories).
Micah
1. CAN-2005-2458, CAN-2005-2459, CAN-2005-1767, CAN-2005-2456,
CAN-2005-1768, CAN-2005-0756 CAN-2005-0757, CAN-2005-1762, CAN-2005-1768
2. 184_arch-x86_64-ia32-ptrace32-oops.diff,
174_net-ipv4-netfilter-nat-mem.diff, 178_fs_ext2_ext3_xattr-sharing.diff,
179_net-ipv4-netfilter-ip_recent-last_pkts.diff
3. CAN-2005-1763, CAN-2005-1762, CAN-2005-0756, CAN-2005-1265, CAN-2005-0757,
CAN-2005-1765, CAN-2005-1761, CAN-2005-2456, CAN-2005-2548, CAN-2004-2302,
CAN-2005-1767, CAN-2005-2458, CAN-2005-2459
4. mckinley_icache.dpatch, arch-x86_64-kernel-smp-boot-race.dpatch,
arch-x86_64-mm-ioremap-page-lookup.dpatch,
fs-exec-ptrace-core-exec-race.dpatch, fs-exec-ptrace-deadlock.dpatch,
fs-exec-posix-timers-leak-1.dpatch, fs-exec-posix-timers-leak-2.dpatch,
fs-hfs-oops-and-leak.dpatch, net-bridge-netfilter-etables-smp-race.dpatch,
net-bridge-forwarding-poison-2.dpatch, net-rose-ndigis-verify.dpatch,
sound-usb-usbaudio-unplug-oops.dpatch, net-ipv4-ipvs-conn_tab-race.dpatch,
arch-ia64-ptrace-getregs-putregs.dpatch, ppc32-time_offset-misuse.dpatch,
netfilter-NAT-memory-corruption.dpatch,
netfilter-ip_conntrack_untracked-refcount.dpatch,
sys_get_thread_area-leak.dpatch, fs_ext2_ext3_xattr-sharing.dpatch,
net-ipv4-netfilter-ip_recent-last_pkts.dpatch,
arch-x86_64-mm-ioremap-page-lookup-fix.dpatch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20050908/14807a7c/attachment.pgp
On Thu, Sep 08, 2005 at 09:17:25PM -0500, Micah Anderson wrote:> Hi, > > I think it would be a good idea to get a DTSA (Debian Testing Security > Advisory) issued for 2.4.27 and 2.6.8. > > 2.4.27-11 is already in testing, but the number of security bugs fixed in > this version is significant: there are 9 CAN numbers for 2.4.27-11[1]; and 4 > other security patches that do not have CVE entries[2]. It seems that it > would be a good idea to do an advisory to alert people that these security > holes have been fixed and that they need to upgrade and reboot if they > haven''t already > > 2.6.8 is scheduled to be removed from sid, and consequentially in testing as > well, however it may be good to do an advisory to alert those who are > running 2.6.8 to upgrade to linux-2.6 (2.6.12) as the kernel they are > running is not being supported (and the transition is not super obvious) and > the number of security holes for the version in testing (2.6.8-16) adds up > to a whopping 13 CAN numbers[3] and 21 other security patches[4]. > > Neither of these advisories is a typical DTSA, as we normally we only do > advisories for things that are blocked from reaching testing by some other > issue, but I think that it would be good to do these two advisories because > of the sheer number of security holes fixed as well as the necessary upgrade > path that people need to take if they wish to maintain the integrity of > their machines. > > I have begun the work to prepare this advisory for release, we basically > need 2.6.8 to leave the archvie and the 2.6.12 packages to enter testing > before the 2.6.8 DTSA can be released. The DTSA would just list the normal > testing repositories for the upgrade (rather than the secure-testing > repositories). > > > Micah > > 1. CAN-2005-2458, CAN-2005-2459, CAN-2005-1767, CAN-2005-2456, > CAN-2005-1768, CAN-2005-0756 CAN-2005-0757, CAN-2005-1762, CAN-2005-1768 > > 2. 184_arch-x86_64-ia32-ptrace32-oops.diff, > 174_net-ipv4-netfilter-nat-mem.diff, 178_fs_ext2_ext3_xattr-sharing.diff, > 179_net-ipv4-netfilter-ip_recent-last_pkts.diff > > 3. CAN-2005-1763, CAN-2005-1762, CAN-2005-0756, CAN-2005-1265, CAN-2005-0757, > CAN-2005-1765, CAN-2005-1761, CAN-2005-2456, CAN-2005-2548, CAN-2004-2302, > CAN-2005-1767, CAN-2005-2458, CAN-2005-2459 > > 4. mckinley_icache.dpatch, arch-x86_64-kernel-smp-boot-race.dpatch, > arch-x86_64-mm-ioremap-page-lookup.dpatch, > fs-exec-ptrace-core-exec-race.dpatch, fs-exec-ptrace-deadlock.dpatch, > fs-exec-posix-timers-leak-1.dpatch, fs-exec-posix-timers-leak-2.dpatch, > fs-hfs-oops-and-leak.dpatch, net-bridge-netfilter-etables-smp-race.dpatch, > net-bridge-forwarding-poison-2.dpatch, net-rose-ndigis-verify.dpatch, > sound-usb-usbaudio-unplug-oops.dpatch, net-ipv4-ipvs-conn_tab-race.dpatch, > arch-ia64-ptrace-getregs-putregs.dpatch, ppc32-time_offset-misuse.dpatch, > netfilter-NAT-memory-corruption.dpatch, > netfilter-ip_conntrack_untracked-refcount.dpatch, > sys_get_thread_area-leak.dpatch, fs_ext2_ext3_xattr-sharing.dpatch, > net-ipv4-netfilter-ip_recent-last_pkts.dpatch, > arch-x86_64-mm-ioremap-page-lookup-fix.dpatchThat seems fine to me, at a glance. Though there have been some aditional bugs fixed in SVN. I have added the relevant patches to all trees that were effected, though as only 2.4.27 and 2.6.12 are reevant to this discussion. It might be a good time to spin 2.4.27-12 and get that into unstable. And linux-2.6 2.6.12-6, which was released earleier this week, should be up to date. I''ve also added team@security.debian.org, as I would like to keep them in the loop with regards to security activity. -- Horms
Moritz Muehlenhoff schrieb am Friday, den 09. September 2005:> Micah Anderson wrote: > > Neither of these advisories is a typical DTSA, as we normally we only do > > advisories for things that are blocked from reaching testing by some other > > issue, but I think that it would be good to do these two advisories because > > of the sheer number of security holes fixed as well as the necessary upgrade > > path that people need to take if they wish to maintain the integrity of > > their machines. > > Good idea, but I''d suggest to make a clean-sweep run over all kernel > issues before. Some entries definitely need updating, (wrt to 2.4/2.6You mean cross reference all the entries in CAN/list to make sure there isn''t anything missing or still has a TODO label?> mapping and IIRC Horms has some mails pending as well, he told me some days > ago.I''ll check with horms about any additional pending fixes.> Also several more issues should receive a CVE mapping.What do you refer to here? I was thinking that the issues that do not have CVE numbers should possibily be submitted so that they do, although I''m not sure how long that will take and if it is worth holding up an advisory.> Wrt keeping a complete history we should also move the entries based on > older kernel-source packages to linux-2.6, as this will be the new > permanent source package for 2.6 kernels.I''m not following you here -- do you mean change all the entries in CAN/list that are for kernel-source-#.#.# to be linux-2.6? If so, why? Thanks! Micah
Micah Anderson wrote:> I think it would be a good idea to get a DTSA (Debian Testing Security > Advisory) issued for 2.4.27 and 2.6.8. > > Neither of these advisories is a typical DTSA, as we normally we only do > advisories for things that are blocked from reaching testing by some other > issue, but I think that it would be good to do these two advisories because > of the sheer number of security holes fixed as well as the necessary upgrade > path that people need to take if they wish to maintain the integrity of > their machines.Good idea, but I''d suggest to make a clean-sweep run over all kernel issues before. Some entries definitely need updating, (wrt to 2.4/2.6 mapping and IIRC Horms has some mails pending as well, he told me some days ago. Also several more issues should receive a CVE mapping. Wrt keeping a complete history we should also move the entries based on older kernel-source packages to linux-2.6, as this will be the new permanent source package for 2.6 kernels. Cheers, Moritz
Horms schrieb am Friday, den 09. September 2005:> On Thu, Sep 08, 2005 at 09:17:25PM -0500, Micah Anderson wrote: > > Hi, > > > > I think it would be a good idea to get a DTSA (Debian Testing Security > > Advisory) issued for 2.4.27 and 2.6.8. > > That seems fine to me, at a glance. Though there have been some > aditional bugs fixed in SVN. I have added the relevant patches to all > trees that were effected, though as only 2.4.27 and 2.6.12 are reevant > to this discussion. It might be a good time to spin 2.4.27-12 and get > that into unstable. And linux-2.6 2.6.12-6, which was released earleier > this week, should be up to date.If there are new security issues in SVN, definately spin out a new 2.4.27-12, but this brings up a question -- We haven''t being doing DTSAs for every security hole that is fixed in unstable and naturally migrates to testing, at this point we are only doing them for those packages which can''t enter testing on their own because they are blocked by something. The reason I was suggesting doing one for 2.4.27-11 was because there are a significant number of holes fixed in that release compared to previous, but since it migrates fine from unstable to testing, perhaps we shouldn''t do a DTSA on it at all? Notifying testing users of security holes in all packages that enter testing from unstable is useful, but it may be too much of a burden on the team to issue advisories on them all. Do we want to be doing DTSAs for every new kernel version that comes out with security holes? If we do, we need to make a policy decision. Either we: 1. make it our policy to always do DTSAs for kernel security issues regardless if they enter testing naturally or not; or 2. make it our policy to do a DTSA for all packages that fix a significant number[1] of security issues because the significance of the threat is large enough to draw attention to the fix. Thoughts? Issuing an advisory for 2.6.8 still seems to make sense to me, since the transition to 2.6.12 is not so obvious. Micah 1. The definition of "significant number" is up to the team or the person willing to write the DTSA
Micah Anderson wrote:> > Micah Anderson wrote: > > > Neither of these advisories is a typical DTSA, as we normally we only do > > > advisories for things that are blocked from reaching testing by some other > > > issue, but I think that it would be good to do these two advisories because > > > of the sheer number of security holes fixed as well as the necessary upgrade > > > path that people need to take if they wish to maintain the integrity of > > > their machines. > > > > Good idea, but I''d suggest to make a clean-sweep run over all kernel > > issues before. Some entries definitely need updating, (wrt to 2.4/2.6 > > You mean cross reference all the entries in CAN/list to make sure there > isn''t anything missing or still has a TODO label?This as well, but there are also some entries, which are only marked vulnerable as 2.4, which also apply to 2.6, e.g. CAN-2005-2800 and 2801. And vice versa possibly as well. We should double check them with the debian kernel SVN.> > Also several more issues should receive a CVE mapping. > > What do you refer to here?CAN-2005-XXXX [Four potentially DoS exploitable deadlocks and leaks in kernel 2.6] - linux-2.6 2.6.12-6 (low) CAN-2005-XXXX [DoS by removal of default ACLs in ext2/ext3]> I was thinking that the issues that do not have CVE numbers should possibily > be submitted so that they do, although I''m not sure how long that will take > and if it is worth holding up an advisory.Half a day, I can request the rest of the missing ones tomorrow.> > Wrt keeping a complete history we should also move the entries based on > > older kernel-source packages to linux-2.6, as this will be the new > > permanent source package for 2.6 kernels. > > I''m not following you here -- do you mean change all the entries in CAN/list > that are for kernel-source-#.#.# to be linux-2.6?Yes.> If so, why?To preserve a complete history of security issues for the kernels. linux-2.6 will be the new permanent source package and if someone wants to check the state of a vulnerability for he shouldn''t be referred to a kernel-source package that is no longer in the archive, but instead have the information from which point in time it is fixed in linux-2.6. (Practically 2.6.12-1 for almost all vulnerabilities). Cheers, Moritz
On Fri, Sep 09, 2005 at 08:30:39AM -0500, Micah Anderson wrote:> Horms schrieb am Friday, den 09. September 2005: > > > On Thu, Sep 08, 2005 at 09:17:25PM -0500, Micah Anderson wrote: > > > Hi, > > > > > > I think it would be a good idea to get a DTSA (Debian Testing Security > > > Advisory) issued for 2.4.27 and 2.6.8. > > > > That seems fine to me, at a glance. Though there have been some > > aditional bugs fixed in SVN. I have added the relevant patches to all > > trees that were effected, though as only 2.4.27 and 2.6.12 are reevant > > to this discussion. It might be a good time to spin 2.4.27-12 and get > > that into unstable. And linux-2.6 2.6.12-6, which was released earleier > > this week, should be up to date. > > If there are new security issues in SVN, definately spin out a new > 2.4.27-12, but this brings up a question -- > > We haven''t being doing DTSAs for every security hole that is fixed in > unstable and naturally migrates to testing, at this point we are only doing > them for those packages which can''t enter testing on their own because they > are blocked by something. > > The reason I was suggesting doing one for 2.4.27-11 was because there are a > significant number of holes fixed in that release compared to previous, but > since it migrates fine from unstable to testing, perhaps we shouldn''t do a > DTSA on it at all? Notifying testing users of security holes in all packages > that enter testing from unstable is useful, but it may be too much of a > burden on the team to issue advisories on them all. > > Do we want to be doing DTSAs for every new kernel version that comes out > with security holes? If we do, we need to make a policy decision. Either we: > 1. make it our policy to always do DTSAs for kernel security issues > regardless if they enter testing naturally or not; or 2. make it our policy to > do a DTSA for all packages that fix a significant number[1] of security > issues because the significance of the threat is large enough to draw > attention to the fix. > > Thoughts?I''m not sure, but almost every, if not every, kernel release will have security fixes given the current rate that they are being found and fixed - more than one a week, perhaps more than one a day. -- Horms
On Fri, Sep 09, 2005 at 02:49:18PM +0200, Moritz Muehlenhoff wrote:> Micah Anderson wrote: > > I think it would be a good idea to get a DTSA (Debian Testing Security > > Advisory) issued for 2.4.27 and 2.6.8. > > > > Neither of these advisories is a typical DTSA, as we normally we only do > > advisories for things that are blocked from reaching testing by some other > > issue, but I think that it would be good to do these two advisories because > > of the sheer number of security holes fixed as well as the necessary upgrade > > path that people need to take if they wish to maintain the integrity of > > their machines. > > Good idea, but I''d suggest to make a clean-sweep run over all kernel > issues before. Some entries definitely need updating, (wrt to 2.4/2.6 > mapping and IIRC Horms has some mails pending as well, he told me some days > ago. Also several more issues should receive a CVE mapping. > > Wrt keeping a complete history we should also move the entries based on > older kernel-source packages to linux-2.6, as this will be the new > permanent source package for 2.6 kernels.I also notice that 2.6.13.1 has now been released. This likely contains fixes relevant for us. Though I''m not sure which if any apply to our 2.4.27, 2.6.8 or 2.6.12. Nor, which ones are security problems. I''ll look through it on Monday, unless someone gets there before me. I usually get the broken out patches from here, though 2.6.13.1 doesn''t seem to be there, I''m not sure if that is a tempoary problem or not. http://www.kernel.org/git/?p=linux/kernel/git/chrisw/stable-queue.git;a=tree -- Horms
Horms wrote:> I also notice that 2.6.13.1 has now been released. This likely contains > fixes relevant for us.It does, I''ve already filed a bug for it. (327416) Moritz
On Fri, Sep 09, 2005 at 08:05:58AM -0500, Micah Anderson wrote:> Moritz Muehlenhoff schrieb am Friday, den 09. September 2005: > > > Micah Anderson wrote: > > > Neither of these advisories is a typical DTSA, as we normally we only do > > > advisories for things that are blocked from reaching testing by some other > > > issue, but I think that it would be good to do these two advisories because > > > of the sheer number of security holes fixed as well as the necessary upgrade > > > path that people need to take if they wish to maintain the integrity of > > > their machines. > > > > Good idea, but I''d suggest to make a clean-sweep run over all kernel > > issues before. Some entries definitely need updating, (wrt to 2.4/2.6 > > You mean cross reference all the entries in CAN/list to make sure there > isn''t anything missing or still has a TODO label? > > > mapping and IIRC Horms has some mails pending as well, he told me some days > > ago. > > I''ll check with horms about any additional pending fixes.Other than 2.6.13.1, I do not have anything pending. But I could well have missed stuff. Actually, thats extremely likely. So please feel free to post missing patches. -- Horms