Linux kernel file offset pointer handling Exploit
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.
========
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.
