Grsecurity problem - modifying "read-only kernel"

Type securityvulns
Reporter Securityvulns
Modified 2002-05-18T00:00:00


Affected: Grsecurity(and maybe other linux hardening patchs).

Description: Grsecurity (and maybe other linux hardening patchs) integrates a variant of the patch published in phrack p58-0x07 article 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.

An example of kernel modification with grsecurity kmem read-only patch activated and lkm supports disabled is available at the following address:

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/ Loading symbols from /usr/src/linux/ 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:~/#

Note: Grsecurity developpement 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. But this causes problems with programs like XFree86 that may need access to /dev/mem.

As a conclusion, preventing direct write to kmem and disabling lkm support doesnt mean it is impossible to modify the running kernel, so dont forget to use a good ACL policy :-)

-- Guillaume Pelat Security Expert

INTEXXIA 171 Av. Georges Clemenceau 92024 NANTERRE CEDEX - FRANCE tel: +33 1 55 69 49 10 fax:| +33 1 55 69 78 80