linux-kernel - Re: [rfc 3/3] prctl: Add PR_SET_MM codes to tune up mm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGXu5j+_Lz3ZpemFFO-XNbsk0d+Zp4JLiHH6XTQCkQaO3PGg_g@mail.gmail.com>
Date:	Tue, 29 Nov 2011 12:37:58 -0800
From:	Kees Cook <keescook@...omium.org>
To:	Cyrill Gorcunov <gorcunov@...il.com>
Cc:	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Tejun Heo <tj@...nel.org>, Andrew Vagin <avagin@...nvz.org>,
	Serge Hallyn <serge.hallyn@...onical.com>,
	Pavel Emelyanov <xemul@...allels.com>,
	Vasiliy Kulikov <segoon@...nwall.com>
Subject: Re: [rfc 3/3] prctl: Add PR_SET_MM codes to tune up mm_struct entires

On Tue, Nov 29, 2011 at 12:29 PM, Cyrill Gorcunov <gorcunov@...il.com> wrote:
> On Tue, Nov 29, 2011 at 12:19:38PM -0800, Kees Cook wrote:
>> On Tue, Nov 29, 2011 at 11:12:55PM +0400, Cyrill Gorcunov wrote:
>> > At restore time we need a mechanism to restore those values
>> > back and for this sake PR_SET_MM prctl code is introduced.
>>
>> arg3 needs to be significantly more carefully validated. find_vma() doesn't
>> say that vm_start <= addr, only that vm_end > addr. This effectively
>> bypasses all the vma checks (mmap_min_addr, max process size, etc), with
>> some pretty crazy side-effects, I think.
>
> Yes, I know it needs some more testing, but apart from vma bounds (yup,
> good point with find_vma, I'll fix) I thought about what else should be
> checked? I think VMA prototype should be checked to fit "code", "data"
> templates, ie code should be at least readable and execytable, but what
> about data and stack and brk, should stack be executable? That is the
> point where I've got a bit confused and though putting RFC out might be
> a good idea to collect opinions.

In the most basic sense, it shouldn't be possible to create an mm
state that can't be reached through the normal ELF loader, calls to
mmap(), mprotect(), stack growth, etc. I think it might be worth
examining those paths to see how they're being bounds-checked. (And
note the especially scary handling of the hidden stack guard page.)

-Kees

-- 
Kees Cook
ChromeOS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/