LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Andy Lutomirski <luto@amacapital.net>
To: Kees Cook <keescook@chromium.org>
Cc: Andy Lutomirski <luto@kernel.org>,
	"H. J. Lu" <hjl.tools@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Yu-cheng Yu <yu-cheng.yu@intel.com>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-doc@vger.kernel.org, Linux-MM <linux-mm@kvack.org>,
	linux-arch <linux-arch@vger.kernel.org>, X86 ML <x86@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
	"Shanbhogue, Vedvyas" <vedvyas.shanbhogue@intel.com>,
	"Ravi V. Shankar" <ravi.v.shankar@intel.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Jonathan Corbet <corbet@lwn.net>, Oleg Nesterov <oleg@redhat.com>,
	Arnd Bergmann <arnd@arndb.de>,
	mike.kravetz@oracle.com, Florian Weimer <fweimer@redhat.com>
Subject: Re: [PATCH 06/10] x86/cet: Add arch_prctl functions for shadow stack
Date: Tue, 19 Jun 2018 07:50:43 -0700	[thread overview]
Message-ID: <569B4719-6283-4575-A16E-D0A78D280F4E@amacapital.net> (raw)
In-Reply-To: <CAGXu5jK0gospOXRpN6zYiQPXOZeE=YpVAz2qu4Zc3-32v85+EQ@mail.gmail.com>



> On Jun 18, 2018, at 5:52 PM, Kees Cook <keescook@chromium.org> wrote:
> 
>> On Mon, Jun 18, 2018 at 3:03 PM, Andy Lutomirski <luto@kernel.org> wrote:
>>> On Tue, Jun 12, 2018 at 12:34 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>>> 
>>>> On Tue, Jun 12, 2018 at 11:59 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
>>>>> On Tue, 12 Jun 2018, H.J. Lu wrote:
>>>>>> On Tue, Jun 12, 2018 at 9:34 AM, Andy Lutomirski <luto@kernel.org> wrote:
>>>>>>> On Tue, Jun 12, 2018 at 9:05 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>>>>> On Tue, Jun 12, 2018 at 9:01 AM, Andy Lutomirski <luto@kernel.org> wrote:
>>>>>>>>> On Tue, Jun 12, 2018 at 4:43 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>>>>>>> On Tue, Jun 12, 2018 at 3:03 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
>>>>>>>>>> That works for stuff which loads all libraries at start time, but what
>>>>>>>>>> happens if the program uses dlopen() later on? If CET is force locked and
>>>>>>>>>> the library is not CET enabled, it will fail.
>>>>>>>>> 
>>>>>>>>> That is to prevent disabling CET by dlopening a legacy shared library.
>>>>>>>>> 
>>>>>>>>>> I don't see the point of trying to support CET by magic. It adds complexity
>>>>>>>>>> and you'll never be able to handle all corner cases correctly. dlopen() is
>>>>>>>>>> not even a corner case.
>>>>>>>>> 
>>>>>>>>> That is a price we pay for security.  To enable CET, especially shadow
>>>>>>>>> shack, the program and all of shared libraries it uses should be CET
>>>>>>>>> enabled.  Most of programs can be enabled with CET by compiling them
>>>>>>>>> with -fcf-protection.
>>>>>>>> 
>>>>>>>> If you charge too high a price for security, people may turn it off.
>>>>>>>> I think we're going to need a mode where a program says "I want to use
>>>>>>>> the CET, but turn it off if I dlopen an unsupported library".  There
>>>>>>>> are programs that load binary-only plugins.
>>>>>>> 
>>>>>>> You can do
>>>>>>> 
>>>>>>> # export GLIBC_TUNABLES=glibc.tune.hwcaps=-SHSTK
>>>>>>> 
>>>>>>> which turns off shadow stack.
>>>>>>> 
>>>>>> 
>>>>>> Which exactly illustrates my point.  By making your security story too
>>>>>> absolute, you'll force people to turn it off when they don't need to.
>>>>>> If I'm using a fully CET-ified distro and I'm using a CET-aware
>>>>>> program that loads binary plugins, and I may or may not have an old
>>>>>> (binary-only, perhaps) plugin that doesn't support CET, then the
>>>>>> behavior I want is for CET to be on until I dlopen() a program that
>>>>>> doesn't support it.  Unless there's some ABI reason why that can't be
>>>>>> done, but I don't think there is.
>>>>> 
>>>>> We can make it opt-in via GLIBC_TUNABLES.  But by default, the legacy
>>>>> shared object is disallowed when CET is enabled.
>>>> 
>>>> That's a bad idea. Stuff has launchers which people might not be able to
>>>> change. So they will simply turn of CET completely or it makes them hack
>>>> horrible crap into init, e.g. the above export.
>>>> 
>>>> Give them sane kernel options:
>>>> 
>>>>     cet = off, relaxed, forced
>>>> 
>>>> where relaxed allows to run binary plugins. Then let dlopen() call into the
>>>> kernel with the filepath of the library to check for CET and that will tell
>>>> you whether its ok or or not and do the necessary magic in the kernel when
>>>> CET has to be disabled due to a !CET library/application.
>>>> 
>>>> That's also making the whole thing independent of magic glibc environment
>>>> options and allows it to be used all over the place in the same way.
>>> 
>>> This is very similar to our ARCH_CET_EXEC proposal which controls how
>>> CET should be enforced.   But Andy thinks it is a bad idea.
>> 
>> I do think it's a bad idea to have a new piece of state that survives
>> across exec().  It's going to have nasty usability problems and nasty
>> security problems.
>> 
>> We may need a mode by which glibc can turn CET *back off* even after a
>> program had it on if it dlopens() an old binary.  Or maybe there won't
>> be demand.  I can certainly understand why the CET_LOCK feature is
>> there, although I think we need a way to override it using something
>> like ptrace().  I'm not convinced that CET_LOCK is really needed, but
>> someone who understand the thread model should chime in.
>> 
>> Kees, do you know anyone who has a good enough understanding of
>> usermode exploits and how they'll interact with CET?
> 
> Adding Florian to CC, but if something gets CET enabled, it really
> shouldn't have a way to turn it off. If there's a way to turn it off,
> all the ROP research will suddenly turn to exactly one gadget before
> doing the rest of the ROP: turning off CET. Right now ROP is: use
> stack-pivot gadget, do everything else. Allowed CET to turn off will
> just add one step: use CET-off gadget, use stack-pivot gadget, do
> everything else. :P

Fair enough 

> 
> Following Linus's request for "slow introduction" of new security
> features, likely the best approach is to default to "relaxed" (with a
> warning about down-grades), and allow distros/end-users to pick
> "forced" if they know their libraries are all CET-enabled.

I still don’t get what “relaxed” is for.  I think the right design is:

Processes start with CET on or off depending on the ELF note, but they start with CET unlocked no matter what. They can freely switch CET on and off (subject to being clever enough not to crash if they turn it on and then return right off the end of the shadow stack) until they call ARCH_CET_LOCK.

Ptrace gets new APIs to turn CET on and off and to lock and unlock it.  If an attacker finds a “ptrace me and turn off CET” gadget, then they might as well just do “ptrace me and write shell code” instead. It’s basically the same gadget. Keep in mind that the actual sequence of syscalls to do this is incredibly complicated.

It’s unclear to me that forcing CET on belongs in the kernel at all.  By the time an attacker can find a non-CET ELF binary and can exec it in a context where it does their bidding, the attacker is far beyond what CET can even try to help. At this point we’re talking about an attacker who can effectively invoke system(3) with arbitrary parameters, and attackers with *that* power don’t need ROP and the like.

There is a new feature I’d like to see, though: add an ELF note to bless a binary as being an ELF interpreter. And add an LSM callback to validate an ELF interpreter.  Let’s minimize the shenanigans that people who control containers can get up to. (Obviously the ELF note part would need to be opt-in.)

  parent reply	other threads:[~2018-06-19 14:50 UTC|newest]

Thread overview: 98+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-07 14:37 [PATCH 00/10] Control Flow Enforcement - Part (3) Yu-cheng Yu
2018-06-07 14:37 ` [PATCH 01/10] x86/cet: User-mode shadow stack support Yu-cheng Yu
2018-06-07 16:37   ` Andy Lutomirski
2018-06-07 17:46     ` Yu-cheng Yu
2018-06-07 17:55       ` Dave Hansen
2018-06-07 18:23       ` Andy Lutomirski
2018-06-12 11:56   ` Balbir Singh
2018-06-12 15:03     ` Yu-cheng Yu
2018-06-07 14:37 ` [PATCH 02/10] x86/cet: Introduce WRUSS instruction Yu-cheng Yu
2018-06-07 16:40   ` Andy Lutomirski
2018-06-07 16:51     ` Yu-cheng Yu
2018-06-07 18:41     ` Peter Zijlstra
2018-06-07 20:31       ` Yu-cheng Yu
2018-06-11  8:17     ` Peter Zijlstra
2018-06-11 15:02       ` Yu-cheng Yu
2018-06-14  1:30   ` Balbir Singh
2018-06-14 14:43     ` Yu-cheng Yu
2018-06-07 14:38 ` [PATCH 03/10] x86/cet: Signal handling for shadow stack Yu-cheng Yu
2018-06-07 18:30   ` Andy Lutomirski
2018-06-07 18:58     ` Florian Weimer
2018-06-07 19:51       ` Yu-cheng Yu
2018-06-07 20:07     ` Cyrill Gorcunov
2018-06-07 20:57       ` Andy Lutomirski
2018-06-08 12:07         ` Cyrill Gorcunov
2018-06-07 20:12     ` Yu-cheng Yu
2018-06-07 20:17       ` Dave Hansen
2018-06-07 14:38 ` [PATCH 04/10] x86/cet: Handle thread " Yu-cheng Yu
2018-06-07 18:21   ` Andy Lutomirski
2018-06-07 19:47     ` Florian Weimer
2018-06-07 20:53       ` Andy Lutomirski
2018-06-08 14:53         ` Florian Weimer
2018-06-08 15:01           ` Andy Lutomirski
2018-06-08 15:50             ` Yu-cheng Yu
2018-06-07 14:38 ` [PATCH 05/10] x86/cet: ELF header parsing of Control Flow Enforcement Yu-cheng Yu
2018-06-07 18:38   ` Andy Lutomirski
2018-06-07 20:40     ` Yu-cheng Yu
2018-06-07 14:38 ` [PATCH 06/10] x86/cet: Add arch_prctl functions for shadow stack Yu-cheng Yu
2018-06-07 18:48   ` Andy Lutomirski
2018-06-07 20:30     ` Yu-cheng Yu
2018-06-07 21:01       ` Andy Lutomirski
2018-06-07 22:02         ` H.J. Lu
2018-06-07 23:01           ` Andy Lutomirski
2018-06-08  4:09             ` H.J. Lu
2018-06-08  4:38               ` Andy Lutomirski
2018-06-08 12:24                 ` H.J. Lu
2018-06-08 14:57                   ` Andy Lutomirski
2018-06-08 15:52                     ` Cyrill Gorcunov
2018-06-08  4:22           ` H.J. Lu
2018-06-08  4:35             ` Andy Lutomirski
2018-06-08 12:17               ` H.J. Lu
2018-06-12 10:03           ` Thomas Gleixner
2018-06-12 11:43             ` H.J. Lu
2018-06-12 16:01               ` Andy Lutomirski
2018-06-12 16:05                 ` H.J. Lu
2018-06-12 16:34                   ` Andy Lutomirski
2018-06-12 16:51                     ` H.J. Lu
2018-06-12 18:59                       ` Thomas Gleixner
2018-06-12 19:34                         ` H.J. Lu
2018-06-18 22:03                           ` Andy Lutomirski
2018-06-19  0:52                             ` Kees Cook
2018-06-19  6:40                               ` Florian Weimer
2018-06-19 14:50                               ` Andy Lutomirski [this message]
2018-06-19 16:44                                 ` Kees Cook
2018-06-19 16:59                                   ` Yu-cheng Yu
2018-06-19 17:07                                     ` Kees Cook
2018-06-19 17:20                                       ` Andy Lutomirski
2018-06-19 20:12                                         ` Kees Cook
2018-06-19 20:47                                           ` Andy Lutomirski
2018-06-19 22:38                                             ` Yu-cheng Yu
2018-06-20  0:50                                               ` Andy Lutomirski
2018-06-21 23:07                                                 ` Yu-cheng Yu
2018-06-07 14:38 ` [PATCH 07/10] mm: Prevent mprotect from changing " Yu-cheng Yu
2018-06-07 14:38 ` [PATCH 08/10] mm: Prevent mremap of " Yu-cheng Yu
2018-06-07 18:48   ` Andy Lutomirski
2018-06-07 20:18     ` Yu-cheng Yu
2018-06-07 14:38 ` [PATCH 09/10] mm: Prevent madvise from changing " Yu-cheng Yu
2018-06-07 20:54   ` Andy Lutomirski
2018-06-07 21:09   ` Nadav Amit
2018-06-07 21:18     ` Yu-cheng Yu
2018-06-07 14:38 ` [PATCH 10/10] mm: Prevent munmap and remap_file_pages of " Yu-cheng Yu
2018-06-07 18:50   ` Andy Lutomirski
2018-06-07 20:15     ` Yu-cheng Yu
2018-06-12 10:56 ` [PATCH 00/10] Control Flow Enforcement - Part (3) Balbir Singh
2018-06-12 15:03   ` Yu-cheng Yu
2018-06-12 16:00     ` Andy Lutomirski
2018-06-12 16:21       ` Yu-cheng Yu
2018-06-12 16:31         ` Andy Lutomirski
2018-06-12 17:24           ` Yu-cheng Yu
2018-06-12 20:15             ` Yu-cheng Yu
2018-06-14  1:07     ` Balbir Singh
2018-06-14 14:56       ` Yu-cheng Yu
2018-06-17  3:16         ` Balbir Singh
2018-06-18 21:44           ` Andy Lutomirski
2018-06-19  8:52             ` Balbir Singh
2018-06-26  2:46 ` Jann Horn
2018-06-26 14:56   ` Yu-cheng Yu
2018-06-26  5:26 ` Andy Lutomirski
2018-06-26 14:56   ` Yu-cheng Yu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=569B4719-6283-4575-A16E-D0A78D280F4E@amacapital.net \
    --to=luto@amacapital.net \
    --cc=arnd@arndb.de \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=fweimer@redhat.com \
    --cc=hjl.tools@gmail.com \
    --cc=hpa@zytor.com \
    --cc=keescook@chromium.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=mike.kravetz@oracle.com \
    --cc=mingo@redhat.com \
    --cc=oleg@redhat.com \
    --cc=ravi.v.shankar@intel.com \
    --cc=tglx@linutronix.de \
    --cc=vedvyas.shanbhogue@intel.com \
    --cc=x86@kernel.org \
    --cc=yu-cheng.yu@intel.com \
    --subject='Re: [PATCH 06/10] x86/cet: Add arch_prctl functions for shadow stack' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).