Re: Announcement: Solaris loadable kernel module backdoor

From: Keith Owens (kaosat_private)
Date: Wed Dec 22 1999 - 16:36:22 PST

  • Next message: Benjamin Congdon: "Re: [w00giving '99 #11] IMail's password encryption scheme"

    On Tue, 21 Dec 1999 14:33:50 -0800,
    pedwardat_private wrote:
    >At boot, compile the list of modules that are 'known good' (for the sake
    >of argument, it's the /lib/modules/x.y.z), then write the list, with
    >MD5 checksums, to a write once /proc interface to kmod.
    >
    >kmod would check the MD5 sum before loading the requested module, if it didn't
    >match the in-kernel list, don't allow it.
    
    kmod does not load modules.  It starts a kernel thread and invokes
    modprobe.  modprobe runs /etc/modules.conf and the the dependency chain
    then loads anywhere between zero and n modules.  All of this work is in
    user space and it is all outside kernel control.
    
    >For the really paranoid, at compile time you could tar up all the modules and
    >create the MD5 sum of that, store it in the kernel at some spot, and modify
    >the module utils to read tarfiles.  If the MD5 sum of the tarfile doesn't
    >match the compiled in list, you can't load the module.
    
    At which point crackers just trojan the modprobe and insmod binaries.
    A chain is only as secure as its weakest link.
    
    >Any other ideas on preventing untrusted modules from being loaded or replaced
    >and loaded as an existing 'trusted' module?
    
    As long as any OS allows root to run user space utilities to modify the
    OS, the weak link is the lack of kernel support for checking that *all*
    binaries run by a privileged user are secure.  There is no point
    building checks into modutils when any cracker running as root can run
    their own binary or LD_PRELOAD an existing binary.
    
    The day that you can boot a Linux kernel and stop root from changing
    anything and stop them using tricks like LD_PRELOAD, that is the day
    you can start trusting your user space utilities.  And when you have a
    system like that, modutils will be changed to verify modules before
    loading.  Of course by then it is probably irrelevant, a system which
    is that secure will not let anyone create rogue modules in the first
    place because they cannot update the filesystem.
    
    Adding a check to modutils without securing root's environment only
    raises the bar 0.5 cm.  Any half competent cracker will switch to
    trojan modutil binaries and bypass the check.  IMHO, building checksum
    support into modutils is fake security.
    
    Keith Owens, modutils maintainer.
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:23:07 PDT