lkml.org 
[lkml]   [2017]   [Nov]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules
    On Tue, Nov 28, 2017 at 3:23 PM, Theodore Ts'o <tytso@mit.edu> wrote:
    > On Tue, Nov 28, 2017 at 01:33:40PM -0800, Kees Cook wrote:
    >> As I've said before, this isn't a theoretical attack surface. This
    >> year alone there have been three known-exploitable flaws exposed by
    >> autoloading:
    >>
    >> The exploit for CVE-2017-2636 uses int n_hdlc = N_HDLC; ioctl(fd,
    >> TIOCSETD, &n_hdlc) [1]. This is using the existing "tty-ldisc-"
    >> prefix, and is intentionally unprivileged.
    >>
    >> The exploit for CVE-2017-6074 uses socket(PF_INET6, SOCK_DCCP,
    >> IPPROTO_IP) [2]. This is using the existing proto prefix, and is
    >> intentionally unprivileged.
    >
    > So in these two cases, if the kernel was built w/o modules, and HDLC
    > and DCCP was built-in, you'd be screwed, then?

    Sure, but that's not the common situation.

    > Is the goal here to protect people using distro kernels which build
    > the world as modules, including dodgy pieces of kernel code that are
    > bug-ridden?

    The bulk of the risk comes from distro kernels, yes. (Though "bug
    ridden" is a strong statement. There are and will be bugs, scattered
    across a wide portion of the kernel, it's just that modules tend to
    cover most of that attack surface.)

    > If so, then presumably 90% of the problem you've cited can be done by
    > creating a script which takes a look of the modules that are normally
    > in use once the machine is in production, and then deleting everything
    > else? Correct?

    This isn't always obvious nor is it easy: a kernel upgrade will
    reinstall everything, etc. This is effectively a blacklist, and we
    need an easy whitelist approach. And an admin may not want to make it
    so hard for themselves to load some special filesystem module that
    they have to hunt it down and reinstall it. Or they'll want some
    containers to be able to trigger module loading and others not to.
    They just want to know their users aren't triggering module loading
    that expands the kernel attack surface.

    > And yes, this will potentially break some users, but the security
    > folks who are advocating for the more aggressive version of this
    > change seem to be OK with breaking users, so they can do this without
    > making kernel changes. Good luck getting Red Hat and SuSE to accept
    > such a change, though....

    We should strive to make the kernel easy to protect. Expecting admins
    to jump through these hoops isn't a sensible way forward.

    -Kees

    --
    Kees Cook
    Pixel Security

    \
     
     \ /
      Last update: 2017-11-29 00:29    [W:4.649 / U:0.164 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site