2.0.36 Kernel (was:isdnutils and 2.0.36 (was: Linux 2.0.36 in slink?))
On Wed, 16 Dec 1998, Remco Blaakmeer wrote:
> On Wed, 16 Dec 1998, Enrique Zanardi wrote:
>
> > On Tue, Dec 15, 1998 at 01:21:52PM -0800, Oscar Levi wrote:
> > > It is unwise to change the kernel just before we ship. I support
> > > making it optional for the minority of people who use ISDN adaptors.
> >
> > And what about the "minority of people" that care about security holes in
> > our default 2.0.35 kernel?
>
> Those people compile their own kernels anyway. :-)
>
> How many people would be opposed to including a kernel-source package for
> the 2.0.36 kernel, leaving 2.0.35 the 'standard' kernel for slink? I don't
> think it would break anything, and compiling your own kernel really isn't
> that hard anymore.
Personally I think it is absolutly necessary to have 2.0.36 in slink:
>From Linux Weekly News:
http://lwn.net/1998/1217/security.phtml
Although the release of the 2.0.36 version
of the Linux kernel is not new, many
people are unaware of the security
improvements made available in 2.0.36.
Alan Cox posted a note with a short list of
security improvements. Notably, it is less
vulnerable to Denial-of-Service attacks
and a potentially exploitable crash related
to IP Masquerading has been repaired.
And this is Alan Cox' note:
http://lwn.net/1998/1217/2.0.36.html
Date: Thu, 10 Dec 1998 22:50:00 GMT
From: Alan Cox <alan@LXORGUK.UKUU.ORG.UK>
Subject: Linux 2.0.36: The stuff that was 'fixed quietly' [Summary]
To: BUGTRAQ@NETSPACE.ORG
Linux 2.0.36 fixed various security holes as does any stable OS update.
Some
of these may have equivalents in other systems, so this documents the
relevant ones now that every vendor should have their kernel updates long
out.
Overall:
o If you have untrusted local users using 2.0.x x<36 there are
denial
of service attacks possible. If you actively use securelevel and
append only files there is a possibility to write data over files
a user has only append access too.
o If you run masquerading there is a possible crash mended. I failed
to succeed in causing it but its fixed nevertheless and its
potentially exploitable.
The things of relevance we fixed
o mmap on append only files has to be restricted to read maps. Linux
2.0.35 did this but it was possible to use mprotect() to then
change
the mapping to Read/write. 2.0.36 closes this hole.
o readv/writev could crash. Linux uses "NULL" to indicate no method
is available for unix read/write operations. The readv/writev
calls neglected to check this. So a writev() to a device that has
no write method crashes the program and may make a mess.
o A fencepost error in the syscall return path. x86 syscall returns
are fun because many things can fault in supervisor space if the
user process did something stupid, or another thread does things
like play with the local descriptor table between the call and
return. The Linux kernel catches such faults and tidies up. There
was a small range of code that it mistakenly considered as not
part of the return path.
o When interpreting PC partition tables there are a couple of places
where you end up doing (something+1) and dividing by it. A
partition
table with 65535 listed for cylinders caused divide by zero
errors.
o An unchecked size/offset assumption in the masquerading code could
in theory lead to a crash.
I wouldnt be suprised to see the mmap and partition table ones in other
OS's
but I doubt the readv/fencepost errors have any obvious equivalence.
--
Heute ist nicht alle Tage, ich komme wieder, keine Frage!!!
Joerg
Reply to: