[8690] in bugtraq

home help back first fref pref prev next nref lref last post

Linux 2.0.36: The stuff that was 'fixed quietly' [Summary]

daemon@ATHENA.MIT.EDU (Alan Cox)
Thu Dec 10 21:59:42 1998

Date: 	Thu, 10 Dec 1998 22:50:00 GMT
Reply-To: Bugtraq List <BUGTRAQ@NETSPACE.ORG>
From: Alan Cox <alan@LXORGUK.UKUU.ORG.UK>
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.


------

Vendor upgrade notes:

Red Hat Software:
http://www.redhat.com/support/docs/rhl/intel/kernel-upgrade-intel.html


No other vendor has bothered to reply to the original vendor-sec request
for comments on this message so far.

home help back first fref pref prev next nref lref last post