[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171004172818.w4zthovu7ew4qskz@dhcp22.suse.cz>
Date: Wed, 4 Oct 2017 19:28:18 +0200
From: Michal Hocko <mhocko@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Baoquan He <bhe@...hat.com>, Kees Cook <keescook@...omium.org>,
Oleg Nesterov <oleg@...hat.com>, Jiri Kosina <jkosina@...e.cz>,
Al Viro <viro@...iv.linux.org.uk>, Ingo Molnar <mingo@...e.hu>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: MAP_FIXED for ELF mappings
On Wed 04-10-17 10:15:31, Linus Torvalds wrote:
> On Wed, Oct 4, 2017 at 10:12 AM, Michal Hocko <mhocko@...nel.org> wrote:
> >
> > Yes, but we already have a new stack mapped and that was the point of
> > the referenced CVE where the binary segments got mapped over the stack
> > AFAIU.
>
> Well, if you control the binary to the point where you just make the
> ELF section map on top of the stack, what's the problem?
>
> I mean, it's not a security issue. You could just have written the
> code to do mmap() instead.
>
> So I think this is a "crazy users can do crazy things, we're not
> arbiters of taste" thing.
Well, my understanding of the CVE (fixed by a87938b2e246
("fs/binfmt_elf.c: fix bug in loading of PIE binaries")) is that the elf
and stack randomization worked against each other.
7ffbad995000-7ffbad996000 rw-p 00000000 00:00 0
7ffbad996000-7ffbad998000 r-xp 00000000 fd:00 4194375 /tmp/PIE
7ffbad999000-7ffbadb97000 rw-p 00000000 00:00 0 [stack]
7ffbadb97000-7ffbadb98000 r--p 00001000 fd:00 4194375 /tmp/PIE
7ffbadb98000-7ffbadbb9000 rw-p 00002000 fd:00 4194375 /tmp/PIE
7ffbadbba000-7ffc0d9ba000 rw-p 00000000 00:00 0 [heap] # incorrectly marked stack
So while the issue is already fixed that made me think how MAP_FIXED
silently corrupted the underlying stack and how it is inherently
dangerous and also why do we need it in the first place. I would rather
make any issues like that impossible for ever.
But as I've said I have hard time to wrap my head around the whole
load_elf_binary so I can be missing something easily here.
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists