[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200807171925.GA20504@openwall.com>
Date: Fri, 7 Aug 2020 19:19:25 +0200
From: Solar Designer <solar@...nwall.com>
To: Kees Cook <keescook@...omium.org>
Cc: lkrg-users@...ts.openwall.com, Thomas Gleixner <tglx@...utronix.de>,
Borislav Petkov <bp@...e.de>
Subject: Re: lkrg: Fix build LKRG for kernel 5.8+
On Wed, Aug 05, 2020 at 01:53:39PM -0700, Kees Cook wrote:
> On Wed, Aug 05, 2020 at 08:48:00PM +0200, Solar Designer wrote:
> > We use native_write_cr4() via its wrapper __write_cr4() (in a kernel
> > header file) to restore SMEP and/or SMAP if these are unexpectedly
> > disabled yet kernel panic on this event is not enabled in LKRG
> > configuration (by default it is enabled).
>
> Is the existing bit pinning not sufficient for lkrg?
I expect it's sufficient against the specific LKRG bypass that prompted
some related hardening of LKRG 1.5 years ago, roughly when the pinning
was being introduced into the kernel:
https://www.openwall.com/lists/lkrg-users/2019/02/20/2
"On a related note, today on kernel-hardening:
Subject: [PATCH] x86/asm: Pin sensitive CR4 bits
https://www.openwall.com/lists/kernel-hardening/2019/02/20/1
As I understand, this would break the gadget this exploit uses to
disable SMEP."
However, LKRG also supports older kernels, it makes no assumptions on
how the value of CR4 might have changed unexpectedly (via this gadget or
not), and it supports a configuration where it'd restore SMEP and/or
SMAP. It'd be weird to have that configuration unsupported on 5.8+.
IIRC, back when you worked on the pinning, I estimated the probability
of CR4-writing gadgets being present in the kernel image inadvertently
(not at original instruction boundaries), and it looked significant.
So now it looks like we should either hack our way around the symbol
unexport (there are still a few easy ways to find and use an unexported
symbol, which we already use for some other symbols that we need) or
introduce our own native_write_cr4() with our own pinning similar to
upstream's (or else we'd potentially make things worse security-wise).
Requiring CONFIG_LKDTM isn't an option long-term as we can't expect
distro kernels to enable that, and we want to support distro kernels.
Well, maybe it'd be an option if native_write_cr4 is exported in the
next release again, and no major distro uses 5.8.
Anyway, I think we'll take care of this, no problem. Like I wrote, I
only CC'ed as a JFYI.
Things would become worse for us if upstream proceeds to fight modules'
access to unexported symbols more than in the nominal way it does now.
Surely there are no security reasons for that fight, but we're concerned
this might not be understood that way by all.
The recent unexport of kallsyms_lookup_name, which we worked around
alright (we still locate and use this function to lookup the rest), is a
worrisome precedent, but at least that was (correctly) not claimed to be
done for security (but for Google's needs in the Android ecosystem).
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
