Kernel security issues

elaine elaine at fwsystems.com
Thu Aug 5 06:09:21 GMT 2004


As I can't find a patch on lkml I'm assuming we're going to have to wait

snippets from the bugtraq/fd list

Synopsis:  Linux kernel file offset pointer handling
Product:   Linux kernel
Version:   2.4 up to to and including 2.4.26, 2.6 up to to and
           including 2.6.7
Vendor:    http://www.kernel.org/
URL:       http://isec.pl/vulnerabilities/isec-0016-procleaks.txt
CVE:       CAN-2004-0415
Author:    Paul Starzetz <ihaquer at isec.pl>
Date:      Aug 04, 2004

....
There  are two different versions of the file handling API inside recent
Linux kernels: the old 32 bit and the new (LFS)  64  bit  API.  We  have
identified  numerous places, where invalid conversions from 64 bit sized
file offsets to 32 bit ones as well  as  insecure  access  to  the  file
offset member variable take place.

We  have  found that most of the /proc entries (like /proc/version) leak
about one page of unitialized kernel memory  and  can  be  exploited  to
obtain sensitive data.

We  have  found  dozens  of places with suspicious or bogus code. One of
them resides in the MTRR handling code for the i386 architecture:
....

Impact:
=======

Since no special privileges are required to open the /proc/mtrr file for
reading any process may exploit the bug to read  huge  parts  of  kernel
memory.

The  kernel  memory  dump  may  include  very sensitive information like
hashed passwords from /etc/shadow or even the root passwort.

We have found in an experiment that after the root user logged in  using
ssh  (in our case it was OpenSSH using PAM), the root passwort was keept
in kernel memory. This is very suprising since sshd will  quickly  clean
(overwrite  with  zeros)  the memory portion used to store the password.
But the password may have made its way through various kernel paths like
pipes or sockets.



-- so basically the impact looks fairly bad.

I'll read lkml again in the morning, but by the description a fix is
not going to be longer on this one than most.

elaine


More information about the Lunar mailing list