Messages in this thread | | | Date | Tue, 29 Nov 2011 12:40:57 -0800 | Subject | Re: [rfc 3/3] prctl: Add PR_SET_MM codes to tune up mm_struct entires | From | Kees Cook <> |
| |
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
| |