From: Kees Cook <keescook@chromium.org> To: Andy Lutomirski <luto@amacapital.net> Cc: Djalal Harouni <tixxdz@opendz.org>, "Eric W. Biederman" <ebiederm@xmission.com>, Al Viro <viro@zeniv.linux.org.uk>, Andrew Morton <akpm@linux-foundation.org>, Linus Torvalds <torvalds@linux-foundation.org>, Ingo Molnar <mingo@kernel.org>, "Serge E. Hallyn" <serge.hallyn@ubuntu.com>, Cyrill Gorcunov <gorcunov@openvz.org>, David Rientjes <rientjes@google.com>, LKML <linux-kernel@vger.kernel.org>, Linux FS Devel <linux-fsdevel@vger.kernel.org>, "kernel-hardening@lists.openwall.com" <kernel-hardening@lists.openwall.com>, Djalal Harouni <tixxdz@gmail.com> Subject: Re: [PATCH v2 0/9] procfs: protect /proc/<pid>/* files with file->f_cred Date: Wed, 2 Oct 2013 10:48:55 -0700 [thread overview] Message-ID: <CAGXu5j+APTTSKh_xvgpzV3wNYseQxafbKqQ3NyvUe50aGOOBGg@mail.gmail.com> (raw) In-Reply-To: <CALCETrUcg4o5QeGMP1rRAzJSfjwS=qD3DsDWV3=fPJQOA3xkKw@mail.gmail.com> 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.) > Can we really not get away with fixing type 1 by preventing these > files from being opened in the first place and type 2 by revoking all > of these fds when a privilege-changing exec happens? Type 1 can be done via exec as well. Instead of using a priv exec to read an arbitrary process, read it could read its own. I think revoking the fd would be great. Does that mechanism exist? -Kees -- Kees Cook Chrome OS Security
WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org> To: Andy Lutomirski <luto@amacapital.net> Cc: Djalal Harouni <tixxdz@opendz.org>, "Eric W. Biederman" <ebiederm@xmission.com>, Al Viro <viro@zeniv.linux.org.uk>, Andrew Morton <akpm@linux-foundation.org>, Linus Torvalds <torvalds@linux-foundation.org>, Ingo Molnar <mingo@kernel.org>, "Serge E. Hallyn" <serge.hallyn@ubuntu.com>, Cyrill Gorcunov <gorcunov@openvz.org>, David Rientjes <rientjes@google.com>, LKML <linux-kernel@vger.kernel.org>, Linux FS Devel <linux-fsdevel@vger.kernel.org>, "kernel-hardening@lists.openwall.com" <kernel-hardening@lists.openwall.com>, Djalal Harouni <tixxdz@gmail.com> Subject: [kernel-hardening] Re: [PATCH v2 0/9] procfs: protect /proc/<pid>/* files with file->f_cred Date: Wed, 2 Oct 2013 10:48:55 -0700 [thread overview] Message-ID: <CAGXu5j+APTTSKh_xvgpzV3wNYseQxafbKqQ3NyvUe50aGOOBGg@mail.gmail.com> (raw) In-Reply-To: <CALCETrUcg4o5QeGMP1rRAzJSfjwS=qD3DsDWV3=fPJQOA3xkKw@mail.gmail.com> 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.) > Can we really not get away with fixing type 1 by preventing these > files from being opened in the first place and type 2 by revoking all > of these fds when a privilege-changing exec happens? Type 1 can be done via exec as well. Instead of using a priv exec to read an arbitrary process, read it could read its own. I think revoking the fd would be great. Does that mechanism exist? -Kees -- Kees Cook Chrome OS Security
next prev parent reply other threads:[~2013-10-02 17:48 UTC|newest] Thread overview: 179+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-10-01 20:26 [PATCH v2 0/9] procfs: protect /proc/<pid>/* files with file->f_cred Djalal Harouni 2013-10-01 20:26 ` [kernel-hardening] " Djalal Harouni 2013-10-01 20:26 ` [PATCH v2 1/9] procfs: add proc_same_open_cred() to check if the cred have changed Djalal Harouni 2013-10-01 20:26 ` [kernel-hardening] " Djalal Harouni 2013-10-01 20:26 ` [PATCH v2 2/9] procfs: add proc_allow_access() to check if file's opener may access task Djalal Harouni 2013-10-01 20:26 ` [kernel-hardening] " Djalal Harouni 2013-10-02 1:36 ` Andy Lutomirski 2013-10-02 1:36 ` [kernel-hardening] " Andy Lutomirski 2013-10-02 14:55 ` Djalal Harouni 2013-10-02 14:55 ` [kernel-hardening] " Djalal Harouni 2013-10-02 16:44 ` Andy Lutomirski 2013-10-02 16:44 ` [kernel-hardening] " Andy Lutomirski 2013-10-03 14:36 ` Djalal Harouni 2013-10-03 14:36 ` [kernel-hardening] " Djalal Harouni 2013-10-03 15:12 ` Andy Lutomirski 2013-10-03 15:12 ` [kernel-hardening] " Andy Lutomirski 2013-10-03 15:12 ` Andy Lutomirski 2013-10-03 19:29 ` Djalal Harouni 2013-10-03 19:29 ` [kernel-hardening] " Djalal Harouni 2013-10-03 19:29 ` Djalal Harouni 2013-10-03 19:37 ` Andy Lutomirski 2013-10-03 19:37 ` [kernel-hardening] " Andy Lutomirski 2013-10-03 19:37 ` Andy Lutomirski 2013-10-03 20:13 ` Djalal Harouni 2013-10-03 20:13 ` [kernel-hardening] " Djalal Harouni 2013-10-03 20:13 ` Djalal Harouni 2013-10-03 21:09 ` Andy Lutomirski 2013-10-03 21:09 ` [kernel-hardening] " Andy Lutomirski 2013-10-03 21:09 ` Andy Lutomirski 2013-10-04 8:59 ` Djalal Harouni 2013-10-04 8:59 ` [kernel-hardening] " Djalal Harouni 2013-10-04 8:59 ` Djalal Harouni 2013-10-04 15:40 ` Andy Lutomirski 2013-10-04 15:40 ` [kernel-hardening] " Andy Lutomirski 2013-10-04 15:40 ` Andy Lutomirski 2013-10-04 18:23 ` Djalal Harouni 2013-10-04 18:23 ` [kernel-hardening] " Djalal Harouni 2013-10-04 18:23 ` Djalal Harouni 2013-10-04 18:34 ` Andy Lutomirski 2013-10-04 18:34 ` [kernel-hardening] " Andy Lutomirski 2013-10-04 18:34 ` Andy Lutomirski 2013-10-04 19:11 ` Djalal Harouni 2013-10-04 19:11 ` [kernel-hardening] " Djalal Harouni 2013-10-04 19:11 ` Djalal Harouni 2013-10-04 19:16 ` Andy Lutomirski 2013-10-04 19:16 ` [kernel-hardening] " Andy Lutomirski 2013-10-04 19:16 ` Andy Lutomirski 2013-10-04 19:27 ` Djalal Harouni 2013-10-04 19:27 ` [kernel-hardening] " Djalal Harouni 2013-10-04 19:27 ` Djalal Harouni 2013-10-04 19:32 ` Andy Lutomirski 2013-10-04 19:32 ` [kernel-hardening] " Andy Lutomirski 2013-10-04 19:32 ` Andy Lutomirski 2013-10-04 19:41 ` Djalal Harouni 2013-10-04 19:41 ` [kernel-hardening] " Djalal Harouni 2013-10-04 19:41 ` Djalal Harouni 2013-10-04 22:17 ` Andy Lutomirski 2013-10-04 22:17 ` [kernel-hardening] " Andy Lutomirski 2013-10-04 22:17 ` Andy Lutomirski 2013-10-04 22:55 ` Eric W. Biederman 2013-10-04 22:55 ` [kernel-hardening] " Eric W. Biederman 2013-10-04 22:55 ` Eric W. Biederman 2013-10-04 22:59 ` Andy Lutomirski 2013-10-04 22:59 ` [kernel-hardening] " Andy Lutomirski 2013-10-04 22:59 ` Andy Lutomirski 2013-10-04 23:08 ` Andy Lutomirski 2013-10-04 23:08 ` [kernel-hardening] " Andy Lutomirski 2013-10-04 23:08 ` Andy Lutomirski 2013-10-05 0:35 ` Eric W. Biederman 2013-10-05 0:35 ` [kernel-hardening] " Eric W. Biederman 2013-10-05 0:35 ` Eric W. Biederman 2013-10-09 10:35 ` Djalal Harouni 2013-10-09 10:35 ` [kernel-hardening] " Djalal Harouni 2013-10-09 10:35 ` Djalal Harouni 2013-10-05 13:23 ` Djalal Harouni 2013-10-05 13:23 ` [kernel-hardening] " Djalal Harouni 2013-10-05 13:23 ` Djalal Harouni 2013-10-07 21:41 ` Andy Lutomirski 2013-10-07 21:41 ` [kernel-hardening] " Andy Lutomirski 2013-10-07 21:41 ` Andy Lutomirski 2013-10-09 10:54 ` Djalal Harouni 2013-10-09 10:54 ` [kernel-hardening] " Djalal Harouni 2013-10-09 10:54 ` Djalal Harouni 2013-10-09 11:15 ` Djalal Harouni 2013-10-09 11:15 ` [kernel-hardening] " Djalal Harouni 2013-10-09 11:15 ` Djalal Harouni 2013-10-09 17:27 ` Andy Lutomirski 2013-10-09 17:27 ` [kernel-hardening] " Andy Lutomirski 2013-10-09 17:27 ` Andy Lutomirski 2013-10-13 10:18 ` Djalal Harouni 2013-10-13 10:18 ` [kernel-hardening] " Djalal Harouni 2013-10-13 10:18 ` Djalal Harouni 2013-10-01 20:26 ` [PATCH v2 3/9] procfs: Document the proposed solution to protect procfs entries Djalal Harouni 2013-10-01 20:26 ` [kernel-hardening] " Djalal Harouni 2013-10-01 20:26 ` [PATCH v2 4/9] procfs: make /proc/*/{stack,syscall} 0400 Djalal Harouni 2013-10-01 20:26 ` [kernel-hardening] " Djalal Harouni 2013-10-01 20:26 ` [PATCH v2 5/9] procfs: make /proc entries that use seq files able to access file->f_cred Djalal Harouni 2013-10-01 20:26 ` [kernel-hardening] " Djalal Harouni 2013-10-01 20:26 ` [PATCH v2 6/9] procfs: add permission checks on the file's opener of /proc/*/stat Djalal Harouni 2013-10-01 20:26 ` [kernel-hardening] " Djalal Harouni 2013-10-02 1:39 ` Andy Lutomirski 2013-10-02 1:39 ` [kernel-hardening] " Andy Lutomirski 2013-10-02 15:14 ` Djalal Harouni 2013-10-02 15:14 ` [kernel-hardening] " Djalal Harouni 2013-10-02 16:46 ` Andy Lutomirski 2013-10-02 16:46 ` [kernel-hardening] " Andy Lutomirski 2013-10-02 19:00 ` Djalal Harouni 2013-10-02 19:00 ` [kernel-hardening] " Djalal Harouni 2013-10-01 20:26 ` [PATCH v2 7/9] procfs: add permission checks on the file's opener of /proc/*/personality Djalal Harouni 2013-10-01 20:26 ` [kernel-hardening] " Djalal Harouni 2013-10-01 20:26 ` [PATCH v2 8/9] procfs: improve permission checks on /proc/*/stack Djalal Harouni 2013-10-01 20:26 ` [kernel-hardening] " Djalal Harouni 2013-10-01 20:26 ` [PATCH v2 9/9] procfs: improve permission checks on /proc/*/syscall Djalal Harouni 2013-10-01 20:26 ` [kernel-hardening] " Djalal Harouni 2013-10-02 1:40 ` [PATCH v2 0/9] procfs: protect /proc/<pid>/* files with file->f_cred Andy Lutomirski 2013-10-02 1:40 ` [kernel-hardening] " Andy Lutomirski 2013-10-02 14:37 ` Djalal Harouni 2013-10-02 14:37 ` [kernel-hardening] " Djalal Harouni 2013-10-02 16:51 ` Andy Lutomirski 2013-10-02 16:51 ` [kernel-hardening] " Andy Lutomirski 2013-10-02 17:48 ` Kees Cook [this message] 2013-10-02 17:48 ` Kees Cook 2013-10-02 17:48 ` Kees Cook 2013-10-02 18:00 ` Andy Lutomirski 2013-10-02 18:00 ` [kernel-hardening] " Andy Lutomirski 2013-10-02 18:00 ` Andy Lutomirski 2013-10-02 18:07 ` Kees Cook 2013-10-02 18:07 ` [kernel-hardening] " Kees Cook 2013-10-02 18:07 ` Kees Cook 2013-10-03 23:14 ` Julien Tinnes 2013-10-03 23:14 ` [kernel-hardening] " Julien Tinnes 2013-10-03 23:14 ` Julien Tinnes 2013-10-02 18:26 ` Djalal Harouni 2013-10-02 18:26 ` [kernel-hardening] " Djalal Harouni 2013-10-02 18:26 ` Djalal Harouni 2013-10-02 18:41 ` Djalal Harouni 2013-10-02 18:41 ` [kernel-hardening] " Djalal Harouni 2013-10-02 18:41 ` Djalal Harouni 2013-10-02 18:22 ` Djalal Harouni 2013-10-02 18:22 ` [kernel-hardening] " Djalal Harouni 2013-10-02 18:22 ` Djalal Harouni 2013-10-02 18:35 ` Kees Cook 2013-10-02 18:35 ` [kernel-hardening] " Kees Cook 2013-10-02 18:35 ` Kees Cook 2013-10-02 18:48 ` Djalal Harouni 2013-10-02 18:48 ` [kernel-hardening] " Djalal Harouni 2013-10-02 18:48 ` Djalal Harouni 2013-10-02 19:43 ` Kees Cook 2013-10-02 19:43 ` [kernel-hardening] " Kees Cook 2013-10-02 19:43 ` Kees Cook 2013-10-03 6:12 ` Ingo Molnar 2013-10-03 6:12 ` [kernel-hardening] " Ingo Molnar 2013-10-03 6:12 ` Ingo Molnar 2013-10-03 12:29 ` Djalal Harouni 2013-10-03 12:29 ` [kernel-hardening] " Djalal Harouni 2013-10-03 12:29 ` Djalal Harouni 2013-10-03 15:15 ` Andy Lutomirski 2013-10-03 15:15 ` [kernel-hardening] " Andy Lutomirski 2013-10-03 15:15 ` Andy Lutomirski 2013-10-03 15:40 ` Djalal Harouni 2013-10-03 15:40 ` [kernel-hardening] " Djalal Harouni 2013-10-03 15:40 ` Djalal Harouni 2013-10-03 15:50 ` Andy Lutomirski 2013-10-03 15:50 ` [kernel-hardening] " Andy Lutomirski 2013-10-03 15:50 ` Andy Lutomirski 2013-10-03 18:37 ` Djalal Harouni 2013-10-03 18:37 ` [kernel-hardening] " Djalal Harouni 2013-10-03 18:37 ` Djalal Harouni 2013-10-04 9:05 ` Djalal Harouni 2013-10-04 9:05 ` [kernel-hardening] " Djalal Harouni 2013-10-04 9:05 ` Djalal Harouni 2013-10-02 18:12 ` Djalal Harouni 2013-10-02 18:12 ` [kernel-hardening] " Djalal Harouni 2013-10-03 6:22 ` Ingo Molnar 2013-10-03 6:22 ` [kernel-hardening] " Ingo Molnar 2013-10-03 12:56 ` Djalal Harouni 2013-10-03 12:56 ` [kernel-hardening] " Djalal Harouni 2013-10-03 13:39 ` Ingo Molnar 2013-10-03 13:39 ` [kernel-hardening] " Ingo Molnar
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAGXu5j+APTTSKh_xvgpzV3wNYseQxafbKqQ3NyvUe50aGOOBGg@mail.gmail.com \ --to=keescook@chromium.org \ --cc=akpm@linux-foundation.org \ --cc=ebiederm@xmission.com \ --cc=gorcunov@openvz.org \ --cc=kernel-hardening@lists.openwall.com \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=luto@amacapital.net \ --cc=mingo@kernel.org \ --cc=rientjes@google.com \ --cc=serge.hallyn@ubuntu.com \ --cc=tixxdz@gmail.com \ --cc=tixxdz@opendz.org \ --cc=torvalds@linux-foundation.org \ --cc=viro@zeniv.linux.org.uk \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.