[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5j+xmyJ6RhtPw9rUgs7k3sZ1KKWffvyGGG--oPfu9W42ng@mail.gmail.com>
Date: Fri, 12 May 2017 12:30:02 -0700
From: Kees Cook <keescook@...omium.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Martin Schwidefsky <schwidefsky@...ibm.com>, Thomas Garnier <thgarnie@...gle.com>,
Greg KH <greg@...ah.com>, Ingo Molnar <mingo@...nel.org>, Daniel Micay <danielmicay@...il.com>,
Heiko Carstens <heiko.carstens@...ibm.com>, Dave Hansen <dave.hansen@...el.com>,
Arnd Bergmann <arnd@...db.de>, Thomas Gleixner <tglx@...utronix.de>, David Howells <dhowells@...hat.com>,
René Nyffenegger <mail@...enyffenegger.ch>,
Andrew Morton <akpm@...ux-foundation.org>,
"Paul E . McKenney" <paulmck@...ux.vnet.ibm.com>, "Eric W . Biederman" <ebiederm@...ssion.com>,
Oleg Nesterov <oleg@...hat.com>, Pavel Tikhomirov <ptikhomirov@...tuozzo.com>,
Ingo Molnar <mingo@...hat.com>, "H . Peter Anvin" <hpa@...or.com>, Andy Lutomirski <luto@...nel.org>,
Paolo Bonzini <pbonzini@...hat.com>, Rik van Riel <riel@...hat.com>,
Josh Poimboeuf <jpoimboe@...hat.com>, Borislav Petkov <bp@...en8.de>, Brian Gerst <brgerst@...il.com>,
"Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
Christian Borntraeger <borntraeger@...ibm.com>, Russell King <linux@...linux.org.uk>,
Will Deacon <will.deacon@....com>, Catalin Marinas <catalin.marinas@....com>,
Mark Rutland <mark.rutland@....com>, James Morse <james.morse@....com>,
linux-s390 <linux-s390@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>,
Linux API <linux-api@...r.kernel.org>, "the arch/x86 maintainers" <x86@...nel.org>,
"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
Kernel Hardening <kernel-hardening@...ts.openwall.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>, Al Viro <viro@...iv.linux.org.uk>
Subject: Re: Re: [PATCH v9 1/4] syscalls: Verify address
limit before returning to user-mode
On Fri, May 12, 2017 at 12:08 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Fri, May 12, 2017 at 12:01 PM, Kees Cook <keescook@...omium.org> wrote:
>> Yeah, the risk for "corrupted addr_limit" is mainly a concern for
>> archs with addr_limit on the kernel stack. If I'm reading things
>> correctly, that means, from the archs I've been paying closer
>> attention to, it's an issue for arm, mips, and powerpc:
>
> I don't understand why people are looking at addr_limit as some kind
> of special thing.
>
> If somebody is smashing the stack and corrupting thread info data, the
> game is over. addr_limit is the *least* of your problems, and it's not
> even all that likely that it will be increasing (it's much more likely
> that it would be overwritten with a smaller value).
>
> Quite frankly, this kind of idiotic discussion just makes me question
> the whole idea of the patch.
>
> Any "security" that is this specific is not real security, it's just
> masturbatory garbage.
>
> It may be worth checking that people use "set_fs()" properly. But stop
> this idiotic crap. It just makes the kernel security people look like
> the crazies.
>
> There are enough incompetent crazy security people, don't go there.
> The kinds of things it is worth protecting against are the big class
> of generic issues, not the kind of "oh, but imagine if a cosmic ray
> flips this particular word in memory" kind of crap that ignores all
> the other words of memory.
>
> Seriously, Kees. You are just making security people look bad. Stop it.
I'm clearly not explaining things well enough. I shouldn't say
"corruption", I should say "malicious manipulation". The methodology
of attacks against the stack are quite different from the other kinds
of attacks like use-after-free, heap overflow, etc. Being able to
exhaust the kernel stack (either due to deep recursion or unbounded
alloca()) means attackers can control a write to addr_limit, and then
leverage that into an actual arbitrary write via subsequent calls to
copy_to_user() pointed at kernel memory. This isn't theoretical, this
is how those attacks are performed. It may sound crazy, but it's real.
With thread_info off the stack, the whole problem goes away. It's
wonderful that this has happened for x86, arm64, and s390. There are
always going to be new methods of attack for everything, but while we
slowly address the design weakness (set_fs()), we can fix the low
hanging fruit too.
-Kees
--
Kees Cook
Pixel Security
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.
