Web Hosting Talk : Web Hosting Main Forums : Hosting Security and Technology : Linux kernel file offset pointer handling Exploit

[Steven]

http://isec.pl/vulnerabilities/isec-0016-procleaks.txt

Details:
========

The Linux kernel offers a file handling API to the userland
applications. Basically a file can be identified by a file name and
opened through the open(2) system call which in turn returns a file
descriptor for the kernel file object.

One of the properties of the file object is something called 'file
offset' (f_pos member variable of the file object), which is advanced if
one reads or writtes to the file. It can also by changed through the
lseek(2) system call and identifies the current writing/reading position
inside the file image on the media.

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:


static ssize_t mtrr_read(struct file *file, char *buf, size_t len,
loff_t *ppos)
{
[1] if (*ppos >= ascii_buf_bytes) return 0;
[2] if (*ppos + len > ascii_buf_bytes) len = ascii_buf_bytes - *ppos;
if ( copy_to_user (buf, ascii_buffer + *ppos, len) ) return -EFAULT;
[3] *ppos += len;
return len;
} /* End Function mtrr_read */


It is quite easy to see that since copy_to_user can sleep, the second
reference to *ppos may use another value. Or in other words, code
operating on the file->f_pos variable through a pointer must be atomic
in respect to the current thread. We expect even more troubles in the
SMP case though.

[GideonX]

RHEL has updated kernels already:

https://rhn.redhat.com/errata/RHSA-2004-413.html

[barleduc]

Looks pretty serious, is there a patch for those who compiled from source?

[Steven]

No, but we have been using progeny.

[Haze]

Anyone try the centos 3 kernel yet ? Any probs ?

[Steven]

The centos kernel is fine. I just wanted to point out DO NOT USE the progeny kernel for redhat 9. Within in a hour or so the load shoots up dramatically ending up requiring a reboot. This has happened on 2 servers out of 4

[choon]

hai... http://kerneltrap.org/node/view/3578
:-/

[trustedurl.com]

Originally posted by thelinuxguy
No, but we have been using progeny.

Just fyi:


The most recent kernel security advisory (TSSA-2004:6552-01)
contains a bug that may cause some customers machines appear
to hang during the boot process while trying to load the loopback
device or experience problems using netstat. While we have a
very thorough QA process, especially for something as important
as the kernel, sometimes a bug will slip through. We have been
working with the customers who have this problem to replicate
it on our own machines and hope to have a fix shortly.

Because the percentage of customers who have this problem appears
to be small, the kernel advisory will remain active. However, we
still recognize this as a serious problem and will continue to work
on it over the weekend if necessary.

We would like to thank our customers for their patience and help
in resolving this issue and we apologize for this inconvenience.

The Progeny Support Team
support@progeny.com

[Steven]

Originally posted by idologic_dh
Just fyi:


The most recent kernel security advisory (TSSA-2004:6552-01)
contains a bug that may cause some customers machines appear
to hang during the boot process while trying to load the loopback
device or experience problems using netstat. While we have a
very thorough QA process, especially for something as important
as the kernel, sometimes a bug will slip through. We have been
working with the customers who have this problem to replicate
it on our own machines and hope to have a fix shortly.

Because the percentage of customers who have this problem appears
to be small, the kernel advisory will remain active. However, we
still recognize this as a serious problem and will continue to work
on it over the weekend if necessary.

We would like to thank our customers for their patience and help
in resolving this issue and we apologize for this inconvenience.

The Progeny Support Team
support@progeny.com

Yeap i mentioned it earlier in the post:

The centos kernel is fine. I just wanted to point out DO NOT USE the progeny kernel for redhat 9. Within in a hour or so the load shoots up dramatically ending up requiring a reboot. This has happened on 2 servers out of 4