lkml.org 
[lkml]   [2013]   [Oct]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH v2 0/9] procfs: protect /proc/<pid>/* files with file->f_cred
    From
    On Wed, Oct 2, 2013 at 11:48 AM, Djalal Harouni <tixxdz@opendz.org> wrote:
    > On Wed, Oct 02, 2013 at 11:35:45AM -0700, Kees Cook wrote:
    >> On Wed, Oct 2, 2013 at 11:22 AM, Djalal Harouni <tixxdz@opendz.org> wrote:
    >> > On Wed, Oct 02, 2013 at 10:48:55AM -0700, Kees Cook wrote:
    >> >> On Wed, Oct 2, 2013 at 9:51 AM, Andy Lutomirski <luto@amacapital.net> wrote:
    >> >> > On Wed, Oct 2, 2013 at 3:37 PM, Djalal Harouni <tixxdz@opendz.org> wrote:
    >> >> >> On Tue, Oct 01, 2013 at 06:40:41PM -0700, Andy Lutomirski wrote:
    >> >> >>> On 10/01/2013 01:26 PM, Djalal Harouni wrote:
    >> >> >>> > /proc/<pid>/* entries varies at runtime, appropriate permission checks
    >> >> >>> > need to happen during each system call.
    >> >> >>> >
    >> >> >>> > Currently some of these sensitive entries are protected by performing
    >> >> >>> > the ptrace_may_access() check. However even with that the /proc file
    >> >> >>> > descriptors can be passed to a more privileged process
    >> >> >>> > (e.g. a suid-exec) which will pass the classic ptrace_may_access()
    >> >> >>> > check. In general the ->open() call will be issued by an unprivileged
    >> >> >>> > process while the ->read(),->write() calls by a more privileged one.
    >> >> >>> >
    >> >> >>> > Example of these files are:
    >> >> >>> > /proc/*/syscall, /proc/*/stack etc.
    >> >> >>> >
    >> >> >>> > And any open(/proc/self/*) then suid-exec to read()/write() /proc/self/*
    >> >> >>> >
    >> >> >>> >
    >> >> >>> > These files are protected during read() by the ptrace_may_access(),
    >> >> >>> > however the file descriptor can be passed to a suid-exec which can be
    >> >> >>> > used to read data and bypass ASLR. Of course this was discussed several
    >> >> >>> > times on LKML.
    >> >> >>>
    >> >> >>> Can you elaborate on what it is that you're fixing? That is, can you
    >> >> >>> give a concrete example of what process opens what file and passes the
    >> >> >>> fd to what process?
    >> >> >> Yes, the references were already given in this email:
    >> >> >> https://lkml.org/lkml/2013/8/31/209
    >> >> >>
    >> >> >> This has been discussed several times on lkml:
    >> >> >> https://lkml.org/lkml/2013/8/28/544
    >> >> >>
    >> >> >> https://lkml.org/lkml/2013/8/28/564 (check Kees's references)
    >> >> >>
    >> >> >>
    >> >> >>> I'm having trouble following your description.
    >> >> >> Process open a /proc file and pass the fd to a more privilaged process
    >> >> >> that will pass the ptrace_may_access() check, while the original process
    >> >> >> that opened that file should fail at the ptrace_may_access()
    >> >> >
    >> >> > So we're talking about two kinds of attacks, right?
    >> >>
    >> >> Correct.
    >> >>
    >> >> > Type 1: Unprivileged process does something like open("/proc/1/maps",
    >> >> > O_RDONLY) and then passes the resulting fd to something privileged.
    >> >>
    >> >> ... and then leaks contents back to unprivileged process.
    >> >>
    >> >> > Type 2: Unprivileged process does something like
    >> >> > open("/proc/self/maps", O_RDONLY) and then forks. The parent calls
    >> >> > execve on something privileged.
    >> >>
    >> >> ... and then parent snoops on file contents for the privileged child.
    >> >>
    >> >> (Type 2 is solved currently, IIUC. Type 1 could be reduced in scope by
    >> >> changing these file modes back to 0400.)
    >> > Kees for 0400 on /proc/*/maps, it was reported that it could break glibc
    >>
    >> I didn't mean maps should be 0400. The maps file is already handled
    >> differently (pinning mm at open time). I didn't think it was one of
    >> the problematic files.
    > Kees currently all these files can be used to leak data, except for
    > /proc/*/{mem,environ}
    >
    > These are the only one that pin the mm at open time. But I'm not sure
    > that this solution will work for /proc/*/maps since they need vma info
    > which will be perhaps freed if task execv, Need to check it.

    Ah, yes, you're totally right. I had misremembered.

    -Kees

    --
    Kees Cook
    Chrome OS Security


    \
     
     \ /
      Last update: 2013-10-02 22:01    [W:4.485 / U:1.292 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site