Re: kernel security bug #307900
Hi, On Friday 10 June 2005 04:02, Adam Majer wrote: > > > woody's kernels are vulnerable to CAN-2004-1235, a uselib() race > > condition. > > Will this be fixed for Woody? > > I thought the plan was to provide security support for Woody for > > another year? > AFAIK, there is no security support for Woody kernels for some time now. > Use kernel.org and compile your kernels for security sensitive machines. If this is true, this should be properly documented somewhere. regards, Holger pgpRtFFh6zwaN.pgp Description: PGP signature
Re: kernel security bug #307900
Olaf van der Spek wrote: > Adam Majer wrote: > >> AFAIK, there is no security support for Woody kernels for some time now. >> Use kernel.org and compile your kernels for security sensitive machines. > > > What's the reason for this lack of support? > > I think after Herbert Xu left so did security updates for Woody's kernel, http://www.mailarchives.org/list/debian-security-announce/msg/2005/00216 - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel security bug #307900
Adam Majer wrote: Olaf van der Spek wrote: woody's kernels are vulnerable to CAN-2004-1235, a uselib() race condition. Will this be fixed for Woody? I thought the plan was to provide security support for Woody for another year? AFAIK, there is no security support for Woody kernels for some time now. Use kernel.org and compile your kernels for security sensitive machines. What's the reason for this lack of support? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel security bug #307900
Olaf van der Spek wrote: > > woody's kernels are vulnerable to CAN-2004-1235, a uselib() race > condition. > > Will this be fixed for Woody? > I thought the plan was to provide security support for Woody for > another year? AFAIK, there is no security support for Woody kernels for some time now. Use kernel.org and compile your kernels for security sensitive machines. - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: kernel security bug #307900
> woody's kernels are vulnerable to CAN-2004-1235, a uselib() race condition. Will this be fixed for Woody? I thought the plan was to provide security support for Woody for another year? -- Olaf van der Spek http://xccu.sf.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel security bug #307900
On Mon, Jun 06, 2005 at 08:28:17AM +1000, Brian May wrote: > > "Steve" == Steve Langasek <[EMAIL PROTECTED]> writes: > Steve> kernel-image packages built against 2.6.8-16 are available > Steve> in sarge for the past week or so for i386, alpha, and ia64. > [...] > Steve> In light of the announcement at the beginning of May that > Steve> sarge is security-supported, I think it would be a good > Steve> idea for any DSAs issued over these holes to include > Steve> mention of the relevant kernel versions for i386 etc., so > Steve> that users who have upgraded earlier know that they need to > Steve> upgrade and reboot. > I think it would also be a good idea if the change log in the > kernel-image package could mention any DSAs fixed... > The changelog I have says: > --- cut --- > I guess I am expected to cross reference this with the changelog of > the kernel-source package. Yeah, at this point that's the process. > What is the "kernel-tree-2.6.8-16" package? Or is this an abbreviation > for "kernel-tree-2.6.8" version "2.6.8-16"? Does this imply > "kernel-source version 2.6.8-16"? $ apt-cache show kernel-tree-2.6.8 Package: kernel-tree-2.6.8 Priority: optional Section: devel Installed-Size: 56 Maintainer: Debian kernel team Architecture: all Source: kernel-source-2.6.8 Version: 2.6.8-16 Provides: kernel-tree-2.6.8-1, kernel-tree-2.6.8-10, kernel-tree-2.6.8-11, kernel-tree-2.6.8-12, kernel-tree-2.6.8-13, kernel-tree-2.6.8-14, kernel-tree-2.6.8-15, kernel-tree-2.6.8-16, kernel-tree-2.6.8-2, kernel-tree-2.6.8-3, kernel-tree-2.6.8-4, kernel-tree-2.6.8-5, kernel-tree-2.6.8-6, kernel-tree-2.6.8-7, kernel-tree-2.6.8-8, kernel-tree-2.6.8-9 Depends: kernel-patch-debian-2.6.8 (= 2.6.8-16), kernel-source-2.6.8 (= 2.6.8-1) | kernel-source-2.6.8 (= 2.6.8-10) | kernel-source-2.6.8 (= 2.6.8-11) | kernel-source-2.6.8 (= 2.6.8-12) | kernel-source-2.6.8 (= 2.6.8-13) | kernel-source-2.6.8 (= 2.6.8-14) | kernel-source-2.6.8 (= 2.6.8-15) | kernel-source-2.6.8 (= 2.6.8-16) | kernel-source-2.6.8 (= 2.6.8-2) | kernel-source-2.6.8 (= 2.6.8-3) | kernel-source-2.6.8 (= 2.6.8-4) | kernel-source-2.6.8 (= 2.6.8-5) | kernel-source-2.6.8 (= 2.6.8-6) | kernel-source-2.6.8 (= 2.6.8-7) | kernel-source-2.6.8 (= 2.6.8-8) | kernel-source-2.6.8 (= 2.6.8-9) > Again, I think it would be much quicker, easier, and less prone to > errors if the DSAs where mentioned in the relevant kernel-image-change > too. It would be prone to errors from kernel-image uploaders who aren't actually keeping track of what has been fixed in the kernel source; at least if there's an expectation that you have to look at the kernel-source, you always know where you stand. You could try cooking up some magic to automatically incorporate particular changelog snippets in kernel-image, but there's also the possibility of arch-specific security issues, so... -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: kernel security bug #307900
> "Steve" == Steve Langasek <[EMAIL PROTECTED]> writes: Steve> kernel-image packages built against 2.6.8-16 are available Steve> in sarge for the past week or so for i386, alpha, and ia64. [...] Steve> In light of the announcement at the beginning of May that Steve> sarge is security-supported, I think it would be a good Steve> idea for any DSAs issued over these holes to include Steve> mention of the relevant kernel versions for i386 etc., so Steve> that users who have upgraded earlier know that they need to Steve> upgrade and reboot. I think it would also be a good idea if the change log in the kernel-image package could mention any DSAs fixed... The changelog I have says: --- cut --- kernel-image-2.6.8-i386 (2.6.8-16) unstable; urgency=low * Fix up AMD descriptions to include CPU name. Thanks to J. Grant. (Simon Horman) * Removed "for those who want the latest ..." from header package descriptons as this is what packages from kernel-latest-2.6-i386 do. (Simon Horman) * Build against kernel-tree-2.6.8-16. (Simon Horman) * Add myself as an uploader. (Simon Horman) -- Simon Horman <[EMAIL PROTECTED]> Thu, 19 May 2005 16:52:19 +0900 kernel-image-2.6.8-i386 (2.6.8-15) unstable; urgency=high * Build against 2.6.8-15. -- Andres Salomon <[EMAIL PROTECTED]> Tue, 22 Mar 2005 12:39:59 -0500 --- cut --- This still leaves me confused if it fixed the problem or not. I guess I am expected to cross reference this with the changelog of the kernel-source package. What is the "kernel-tree-2.6.8-16" package? Or is this an abbreviation for "kernel-tree-2.6.8" version "2.6.8-16"? Does this imply "kernel-source version 2.6.8-16"? Again, I think it would be much quicker, easier, and less prone to errors if the DSAs where mentioned in the relevant kernel-image-change too. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel security bug #307900
On Sun, Jun 05, 2005 at 12:22:07PM +1000, Brian May wrote: > Whats the deal with bug #307900? > As far as I can tell from reading the bug report, the bug has not been > fixed in sarge, will not be fixed for the release, but the bug has > been closed. kernel-source-2.6.8 2.6.8-15 has been in testing for some time now. kernel-image packages built against 2.6.8-16 are available in sarge for the past week or so for i386, alpha, and ia64. kernel-image packages built against 2.6.8-15 are also available in sarge for sparc; the amd64 kernels for the i386 architecture are also built against this revision. There are further security fixes in -16, so these images should be rebuilt, but they include the fix for 307900. Fixed kernel-image packages were not available for the other architectures prior to the freeze, so will need to be handled via security.debian.org. However, AIUI the exploit that exists in the wild for this hole is i386-specific (please correct me if I'm wrong). In light of the announcement at the beginning of May that sarge is security-supported, I think it would be a good idea for any DSAs issued over these holes to include mention of the relevant kernel versions for i386 etc., so that users who have upgraded earlier know that they need to upgrade and reboot. Most of the architectures that are still shipping unfixed 2.6.8 kernels in sarge are outside the purview of the kernel team AIUI, so it may take a bit of time to get packages synced up for a DSA. > Have we come to the point where making a release is more important > then fixing known security bugs? What is known is that new security holes that affect sarge have been appearing on a roughly weekly basis, and new security holes affecting the kernel are being reported on a roughly monthly basis. You can't get to a release with no known security holes using those kinds of numbers; you can pick and choose *which* security fixes you think are important enough to wait on, but we just don't have the kind of turnaround on fixes to be able to foresee a point where we can say that no package, anywhere in sarge, has a known security hole. > Does this mean people who want secure pre-compiled kernels have to > resort to unstable until the issue is fixed? Currently, unstable is in the same state as sarge wrt kernel security. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: kernel security bug #307900
On Sun, Jun 05, 2005 at 12:22:07PM +1000, Brian May wrote: > As far as I can tell from reading the bug report, the bug has not been > fixed in sarge, will not be fixed for the release, but the bug has > been closed. > > Have we come to the point where making a release is more important > then fixing known security bugs? > > Does this mean people who want secure pre-compiled kernels have to > resort to unstable until the issue is fixed? woody's kernels are vulnerable to CAN-2004-1235, a uselib() race condition. The bug became public in January. I emailed [EMAIL PROTECTED] after I got hacked last month, but there was no reply. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
