lkml.org 
[lkml]   [2011]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [rfc 3/3] prctl: Add PR_SET_MM codes to tune up mm_struct entires
    From
    On Tue, Nov 29, 2011 at 12:37 PM, Cyrill Gorcunov <gorcunov@gmail.com> wrote:
    > On Wed, Nov 30, 2011 at 12:29:51AM +0400, Cyrill Gorcunov wrote:
    > ...
    >> >
    >> > 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.
    >
    > On the other hands these fields are set up by elf hanlder code, which
    > does mmap these areas, so we have to check that particular member
    > belongs to existing VMA and never cross user-space area, and together
    > with root-only approach would not it be enough? I'm sure missing something
    > that is why I'm asking.

    Right, if you verify that the addresses are actually inside valid
    userspace vmas, that is likely to be right, though there are probably
    other things I haven't thought of. The trouble is avoiding vdso, stack
    guard page, vsyscall, and anything else that isn't meant for the mm to
    have direct access to.

    --
    Kees Cook
    ChromeOS Security


    \
     
     \ /
      Last update: 2011-11-29 21:43    [W:4.386 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site