Issue metadata
Sign in to add a comment
|
CVE-2017-14140 CrOS: Vulnerability reported in Linux kernel |
||||||||||||||||||||||
Issue descriptionVOMIT (go/vomit) has received an external vulnerability report for the Linux kernel. Advisory: CVE-2017-14140 Details: http://vomit.googleplex.com/advisory?id=CVE/CVE-2017-14140 CVSS severity score: 2.1/10.0 Description: The move_pages system call in mm/migrate.c in the Linux kernel before 4.12.9 doesn't check the effective uid of the target process, enabling a local attacker to learn the memory layout of a setuid executable despite ASLR. This bug was filed by http://go/vomit Please contact us at vomit-team@google.com if you need any assistance.
,
Sep 8 2017
Will only apply to chromeos-3.18 and later. Conflicts with older kernels are too substantial and add more risk than the potential benefit.
,
Sep 11 2017
,
Sep 11 2017
,
Sep 11 2017
,
Sep 12 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/87bc32a505b3a2c30633e788cf80b1a81901ca68 commit 87bc32a505b3a2c30633e788cf80b1a81901ca68 Author: Eric W. Biederman <ebiederm@xmission.com> Date: Tue Sep 12 08:12:01 2017 UPSTREAM: userns: Check euid no fsuid when establishing an unprivileged uid mapping setresuid allows the euid to be set to any of uid, euid, suid, and fsuid. Therefor it is safe to allow an unprivileged user to map their euid and use CAP_SETUID privileged with exactly that uid, as no new credentials can be obtained. I can not find a combination of existing system calls that allows setting uid, euid, suid, and fsuid from the fsuid making the previous use of fsuid for allowing unprivileged mappings a bug. This is part of a fix for CVE-2014-8989. BUG= chromium:762903 TEST=Build and run Change-Id: I1bdf5653654deda160581d1b6ce21c5e0cf0ff4d Cc: stable@vger.kernel.org Reviewed-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Guenter Roeck <groeck@chromium.org> (cherry picked from commit 80dd00a23784b384ccea049bfb3f259d3f973b9d) Reviewed-on: https://chromium-review.googlesource.com/660816 Reviewed-by: Dylan Reid <dgreid@chromium.org> [modify] https://crrev.com/87bc32a505b3a2c30633e788cf80b1a81901ca68/kernel/user_namespace.c
,
Sep 12 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/bba556c44f5abe9a29b16fc40796b1cb146be275 commit bba556c44f5abe9a29b16fc40796b1cb146be275 Author: Jann Horn <jann@thejh.net> Date: Tue Sep 12 08:12:02 2017 UPSTREAM: security: let security modules use PTRACE_MODE_* with bitmasks commit 3dfb7d8cdbc7ea0c2970450e60818bb3eefbad69 upstream. It looks like smack and yama weren't aware that the ptrace mode can have flags ORed into it - PTRACE_MODE_NOAUDIT until now, but only for /proc/$pid/stat, and with the PTRACE_MODE_*CREDS patch, all modes have flags ORed into them. BUG= chromium:762903 TEST=Build and run Change-Id: I6abf820218cfbb320cd0a998afe2684a5a6bcaae Signed-off-by: Jann Horn <jann@thejh.net> Acked-by: Kees Cook <keescook@chromium.org> Acked-by: Casey Schaufler <casey@schaufler-ca.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: James Morris <james.l.morris@oracle.com> Cc: "Serge E. Hallyn" <serge.hallyn@ubuntu.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Willy Tarreau <w@1wt.eu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Guenter Roeck <groeck@chromium.org> (cherry picked from commit e4a5a335105a557b5a78c1513650d1cf7c9f2edb) Reviewed-on: https://chromium-review.googlesource.com/661597 Reviewed-by: Dylan Reid <dgreid@chromium.org> [modify] https://crrev.com/bba556c44f5abe9a29b16fc40796b1cb146be275/security/yama/yama_lsm.c [modify] https://crrev.com/bba556c44f5abe9a29b16fc40796b1cb146be275/security/smack/smack_lsm.c
,
Sep 12 2017
Please mark security bugs as fixed as soon as the fix lands, and before requesting merges. This update is based on the merge- labels applied to this issue. Please reopen if this update was incorrect. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 12 2017
Not all fixes landed. Changed target release to M-61.
,
Sep 12 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/aac82c9d26d213bba708ddff1c896c695e3477fc commit aac82c9d26d213bba708ddff1c896c695e3477fc Author: Jann Horn <jann@thejh.net> Date: Tue Sep 12 20:03:17 2017 UPSTREAM: ptrace: use fsuid, fsgid, effective creds for fs access checks [ Upstream commit caaee6234d05a58c5b4d05e7bf766131b810a657 ] By checking the effective credentials instead of the real UID / permitted capabilities, ensure that the calling process actually intended to use its credentials. To ensure that all ptrace checks use the correct caller credentials (e.g. in case out-of-tree code or newly added code omits the PTRACE_MODE_*CREDS flag), use two new flags and require one of them to be set. The problem was that when a privileged task had temporarily dropped its privileges, e.g. by calling setreuid(0, user_uid), with the intent to perform following syscalls with the credentials of a user, it still passed ptrace access checks that the user would not be able to pass. While an attacker should not be able to convince the privileged task to perform a ptrace() syscall, this is a problem because the ptrace access check is reused for things in procfs. In particular, the following somewhat interesting procfs entries only rely on ptrace access checks: /proc/$pid/stat - uses the check for determining whether pointers should be visible, useful for bypassing ASLR /proc/$pid/maps - also useful for bypassing ASLR /proc/$pid/cwd - useful for gaining access to restricted directories that contain files with lax permissions, e.g. in this scenario: lrwxrwxrwx root root /proc/13020/cwd -> /root/foobar drwx------ root root /root drwxr-xr-x root root /root/foobar -rw-r--r-- root root /root/foobar/secret Therefore, on a system where a root-owned mode 6755 binary changes its effective credentials as described and then dumps a user-specified file, this could be used by an attacker to reveal the memory layout of root's processes or reveal the contents of files he is not allowed to access (through /proc/$pid/cwd). [akpm@linux-foundation.org: fix warning] Signed-off-by: Jann Horn <jann@thejh.net> Acked-by: Kees Cook <keescook@chromium.org> Cc: Casey Schaufler <casey@schaufler-ca.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: James Morris <james.l.morris@oracle.com> Cc: "Serge E. Hallyn" <serge.hallyn@ubuntu.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Willy Tarreau <w@1wt.eu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> BUG= chromium:762903 TEST=Build and run Change-Id: Iaa8322c2b218fd40e431dd06221cca7e59d6413b Signed-off-by: Sasha Levin <sasha.levin@oracle.com> Signed-off-by: Guenter Roeck <groeck@chromium.org> (cherry picked from commit b68c9b9a3f934851babe4862a19cedaeb20aa36b in linux-3.18.y) Reviewed-on: https://chromium-review.googlesource.com/657962 Reviewed-by: Dylan Reid <dgreid@chromium.org> [modify] https://crrev.com/aac82c9d26d213bba708ddff1c896c695e3477fc/include/linux/ptrace.h [modify] https://crrev.com/aac82c9d26d213bba708ddff1c896c695e3477fc/kernel/kcmp.c [modify] https://crrev.com/aac82c9d26d213bba708ddff1c896c695e3477fc/kernel/events/core.c [modify] https://crrev.com/aac82c9d26d213bba708ddff1c896c695e3477fc/fs/proc/base.c [modify] https://crrev.com/aac82c9d26d213bba708ddff1c896c695e3477fc/mm/process_vm_access.c [modify] https://crrev.com/aac82c9d26d213bba708ddff1c896c695e3477fc/fs/proc/array.c [modify] https://crrev.com/aac82c9d26d213bba708ddff1c896c695e3477fc/kernel/futex_compat.c [modify] https://crrev.com/aac82c9d26d213bba708ddff1c896c695e3477fc/kernel/futex.c [modify] https://crrev.com/aac82c9d26d213bba708ddff1c896c695e3477fc/fs/proc/namespaces.c [modify] https://crrev.com/aac82c9d26d213bba708ddff1c896c695e3477fc/kernel/ptrace.c [modify] https://crrev.com/aac82c9d26d213bba708ddff1c896c695e3477fc/security/commoncap.c
,
Sep 12 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/d188a47660fa43c07c70c6b10f0b0d01741bd25b commit d188a47660fa43c07c70c6b10f0b0d01741bd25b Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Tue Sep 12 20:03:18 2017 UPSTREAM: Sanitize 'move_pages()' permission checks The 'move_paghes()' system call was introduced long long ago with the same permission checks as for sending a signal (except using CAP_SYS_NICE instead of CAP_SYS_KILL for the overriding capability). That turns out to not be a great choice - while the system call really only moves physical page allocations around (and you need other capabilities to do a lot of it), you can check the return value to map out some the virtual address choices and defeat ASLR of a binary that still shares your uid. So change the access checks to the more common 'ptrace_may_access()' model instead. This tightens the access checks for the uid, and also effectively changes the CAP_SYS_NICE check to CAP_SYS_PTRACE, but it's unlikely that anybody really _uses_ this legacy system call any more (we hav ebetter NUMA placement models these days), so I expect nobody to notice. Famous last words. BUG= chromium:762903 TEST=Build and run Change-Id: Ie5c0299225b5e05a5da3c9e86d9275a28f073f44 Reported-by: Otto Ebeling <otto.ebeling@iki.fi> Acked-by: Eric W. Biederman <ebiederm@xmission.com> Cc: Willy Tarreau <w@1wt.eu> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Guenter Roeck <groeck@chromium.org> (cherry picked from commit 197e7e521384a23) Reviewed-on: https://chromium-review.googlesource.com/657963 Reviewed-by: Dylan Reid <dgreid@chromium.org> [modify] https://crrev.com/d188a47660fa43c07c70c6b10f0b0d01741bd25b/mm/migrate.c
,
Sep 12 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/3ceaa26be092567e8c5058f9722c4f39aa643ec7 commit 3ceaa26be092567e8c5058f9722c4f39aa643ec7 Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Tue Sep 12 20:17:39 2017 UPSTREAM: Sanitize 'move_pages()' permission checks The 'move_paghes()' system call was introduced long long ago with the same permission checks as for sending a signal (except using CAP_SYS_NICE instead of CAP_SYS_KILL for the overriding capability). That turns out to not be a great choice - while the system call really only moves physical page allocations around (and you need other capabilities to do a lot of it), you can check the return value to map out some the virtual address choices and defeat ASLR of a binary that still shares your uid. So change the access checks to the more common 'ptrace_may_access()' model instead. This tightens the access checks for the uid, and also effectively changes the CAP_SYS_NICE check to CAP_SYS_PTRACE, but it's unlikely that anybody really _uses_ this legacy system call any more (we hav ebetter NUMA placement models these days), so I expect nobody to notice. Famous last words. BUG= chromium:762903 TEST=Build and run Change-Id: Ie5c0299225b5e05a5da3c9e86d9275a28f073f44 Reported-by: Otto Ebeling <otto.ebeling@iki.fi> Acked-by: Eric W. Biederman <ebiederm@xmission.com> Cc: Willy Tarreau <w@1wt.eu> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Guenter Roeck <groeck@chromium.org> (cherry picked from commit 197e7e521384a23) Reviewed-on: https://chromium-review.googlesource.com/664041 [modify] https://crrev.com/3ceaa26be092567e8c5058f9722c4f39aa643ec7/mm/migrate.c
,
Sep 12 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/92105e8327f908198e242b5c66cecd30b948b6d7 commit 92105e8327f908198e242b5c66cecd30b948b6d7 Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Tue Sep 12 20:17:44 2017 UPSTREAM: Sanitize 'move_pages()' permission checks The 'move_paghes()' system call was introduced long long ago with the same permission checks as for sending a signal (except using CAP_SYS_NICE instead of CAP_SYS_KILL for the overriding capability). That turns out to not be a great choice - while the system call really only moves physical page allocations around (and you need other capabilities to do a lot of it), you can check the return value to map out some the virtual address choices and defeat ASLR of a binary that still shares your uid. So change the access checks to the more common 'ptrace_may_access()' model instead. This tightens the access checks for the uid, and also effectively changes the CAP_SYS_NICE check to CAP_SYS_PTRACE, but it's unlikely that anybody really _uses_ this legacy system call any more (we hav ebetter NUMA placement models these days), so I expect nobody to notice. Famous last words. BUG= chromium:762903 TEST=Build and run Change-Id: Ie5c0299225b5e05a5da3c9e86d9275a28f073f44 Reported-by: Otto Ebeling <otto.ebeling@iki.fi> Acked-by: Eric W. Biederman <ebiederm@xmission.com> Cc: Willy Tarreau <w@1wt.eu> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Guenter Roeck <groeck@chromium.org> (cherry picked from commit 197e7e521384a23) Reviewed-on: https://chromium-review.googlesource.com/664042 [modify] https://crrev.com/92105e8327f908198e242b5c66cecd30b948b6d7/mm/migrate.c
,
Sep 12 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/9c8f77a2eaa4282a4e30ce2094af68a7efb804c1 commit 9c8f77a2eaa4282a4e30ce2094af68a7efb804c1 Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Tue Sep 12 20:17:48 2017 UPSTREAM: Sanitize 'move_pages()' permission checks The 'move_paghes()' system call was introduced long long ago with the same permission checks as for sending a signal (except using CAP_SYS_NICE instead of CAP_SYS_KILL for the overriding capability). That turns out to not be a great choice - while the system call really only moves physical page allocations around (and you need other capabilities to do a lot of it), you can check the return value to map out some the virtual address choices and defeat ASLR of a binary that still shares your uid. So change the access checks to the more common 'ptrace_may_access()' model instead. This tightens the access checks for the uid, and also effectively changes the CAP_SYS_NICE check to CAP_SYS_PTRACE, but it's unlikely that anybody really _uses_ this legacy system call any more (we hav ebetter NUMA placement models these days), so I expect nobody to notice. Famous last words. BUG= chromium:762903 TEST=Build and run Change-Id: Ie5c0299225b5e05a5da3c9e86d9275a28f073f44 Reported-by: Otto Ebeling <otto.ebeling@iki.fi> Acked-by: Eric W. Biederman <ebiederm@xmission.com> Cc: Willy Tarreau <w@1wt.eu> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Guenter Roeck <groeck@chromium.org> (cherry picked from commit 197e7e521384a23) Reviewed-on: https://chromium-review.googlesource.com/661798 [modify] https://crrev.com/9c8f77a2eaa4282a4e30ce2094af68a7efb804c1/mm/migrate.c
,
Sep 12 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/830c222c5a65ca8e972e7a26e5a25f1a71aaea47 commit 830c222c5a65ca8e972e7a26e5a25f1a71aaea47 Author: Eric W. Biederman <ebiederm@xmission.com> Date: Tue Sep 12 20:20:14 2017 UPSTREAM: userns: Check euid no fsuid when establishing an unprivileged uid mapping setresuid allows the euid to be set to any of uid, euid, suid, and fsuid. Therefor it is safe to allow an unprivileged user to map their euid and use CAP_SETUID privileged with exactly that uid, as no new credentials can be obtained. I can not find a combination of existing system calls that allows setting uid, euid, suid, and fsuid from the fsuid making the previous use of fsuid for allowing unprivileged mappings a bug. This is part of a fix for CVE-2014-8989. BUG= chromium:762903 TEST=Build and run Change-Id: I1bdf5653654deda160581d1b6ce21c5e0cf0ff4d Cc: stable@vger.kernel.org Reviewed-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Guenter Roeck <groeck@chromium.org> (cherry picked from commit 80dd00a23784b384ccea049bfb3f259d3f973b9d) Reviewed-on: https://chromium-review.googlesource.com/660816 Reviewed-by: Dylan Reid <dgreid@chromium.org> (cherry picked from commit 87bc32a505b3a2c30633e788cf80b1a81901ca68) Reviewed-on: https://chromium-review.googlesource.com/664043 [modify] https://crrev.com/830c222c5a65ca8e972e7a26e5a25f1a71aaea47/kernel/user_namespace.c
,
Sep 12 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/843ce014457a99b57dd7cd6667559212dd5b4ad4 commit 843ce014457a99b57dd7cd6667559212dd5b4ad4 Author: Jann Horn <jann@thejh.net> Date: Tue Sep 12 20:22:31 2017 UPSTREAM: security: let security modules use PTRACE_MODE_* with bitmasks commit 3dfb7d8cdbc7ea0c2970450e60818bb3eefbad69 upstream. It looks like smack and yama weren't aware that the ptrace mode can have flags ORed into it - PTRACE_MODE_NOAUDIT until now, but only for /proc/$pid/stat, and with the PTRACE_MODE_*CREDS patch, all modes have flags ORed into them. BUG= chromium:762903 TEST=Build and run Change-Id: I6abf820218cfbb320cd0a998afe2684a5a6bcaae Signed-off-by: Jann Horn <jann@thejh.net> Acked-by: Kees Cook <keescook@chromium.org> Acked-by: Casey Schaufler <casey@schaufler-ca.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: James Morris <james.l.morris@oracle.com> Cc: "Serge E. Hallyn" <serge.hallyn@ubuntu.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Willy Tarreau <w@1wt.eu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Guenter Roeck <groeck@chromium.org> (cherry picked from commit e4a5a335105a557b5a78c1513650d1cf7c9f2edb) Reviewed-on: https://chromium-review.googlesource.com/661597 Reviewed-by: Dylan Reid <dgreid@chromium.org> (cherry picked from commit bba556c44f5abe9a29b16fc40796b1cb146be275) Reviewed-on: https://chromium-review.googlesource.com/663885 [modify] https://crrev.com/843ce014457a99b57dd7cd6667559212dd5b4ad4/security/yama/yama_lsm.c [modify] https://crrev.com/843ce014457a99b57dd7cd6667559212dd5b4ad4/security/smack/smack_lsm.c
,
Sep 12 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/c2aedb7b36d6ec7463cb342e3fe0d57a4e226d58 commit c2aedb7b36d6ec7463cb342e3fe0d57a4e226d58 Author: Jann Horn <jann@thejh.net> Date: Tue Sep 12 20:27:01 2017 UPSTREAM: ptrace: use fsuid, fsgid, effective creds for fs access checks [ Upstream commit caaee6234d05a58c5b4d05e7bf766131b810a657 ] By checking the effective credentials instead of the real UID / permitted capabilities, ensure that the calling process actually intended to use its credentials. To ensure that all ptrace checks use the correct caller credentials (e.g. in case out-of-tree code or newly added code omits the PTRACE_MODE_*CREDS flag), use two new flags and require one of them to be set. The problem was that when a privileged task had temporarily dropped its privileges, e.g. by calling setreuid(0, user_uid), with the intent to perform following syscalls with the credentials of a user, it still passed ptrace access checks that the user would not be able to pass. While an attacker should not be able to convince the privileged task to perform a ptrace() syscall, this is a problem because the ptrace access check is reused for things in procfs. In particular, the following somewhat interesting procfs entries only rely on ptrace access checks: /proc/$pid/stat - uses the check for determining whether pointers should be visible, useful for bypassing ASLR /proc/$pid/maps - also useful for bypassing ASLR /proc/$pid/cwd - useful for gaining access to restricted directories that contain files with lax permissions, e.g. in this scenario: lrwxrwxrwx root root /proc/13020/cwd -> /root/foobar drwx------ root root /root drwxr-xr-x root root /root/foobar -rw-r--r-- root root /root/foobar/secret Therefore, on a system where a root-owned mode 6755 binary changes its effective credentials as described and then dumps a user-specified file, this could be used by an attacker to reveal the memory layout of root's processes or reveal the contents of files he is not allowed to access (through /proc/$pid/cwd). [akpm@linux-foundation.org: fix warning] Signed-off-by: Jann Horn <jann@thejh.net> Acked-by: Kees Cook <keescook@chromium.org> Cc: Casey Schaufler <casey@schaufler-ca.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: James Morris <james.l.morris@oracle.com> Cc: "Serge E. Hallyn" <serge.hallyn@ubuntu.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Willy Tarreau <w@1wt.eu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> BUG= chromium:762903 TEST=Build and run Change-Id: Iaa8322c2b218fd40e431dd06221cca7e59d6413b Signed-off-by: Sasha Levin <sasha.levin@oracle.com> Signed-off-by: Guenter Roeck <groeck@chromium.org> (cherry picked from commit b68c9b9a3f934851babe4862a19cedaeb20aa36b in linux-3.18.y) Reviewed-on: https://chromium-review.googlesource.com/657962 Reviewed-by: Dylan Reid <dgreid@chromium.org> (cherry picked from commit aac82c9d26d213bba708ddff1c896c695e3477fc) Reviewed-on: https://chromium-review.googlesource.com/663886 [modify] https://crrev.com/c2aedb7b36d6ec7463cb342e3fe0d57a4e226d58/include/linux/ptrace.h [modify] https://crrev.com/c2aedb7b36d6ec7463cb342e3fe0d57a4e226d58/kernel/kcmp.c [modify] https://crrev.com/c2aedb7b36d6ec7463cb342e3fe0d57a4e226d58/kernel/events/core.c [modify] https://crrev.com/c2aedb7b36d6ec7463cb342e3fe0d57a4e226d58/fs/proc/base.c [modify] https://crrev.com/c2aedb7b36d6ec7463cb342e3fe0d57a4e226d58/mm/process_vm_access.c [modify] https://crrev.com/c2aedb7b36d6ec7463cb342e3fe0d57a4e226d58/fs/proc/array.c [modify] https://crrev.com/c2aedb7b36d6ec7463cb342e3fe0d57a4e226d58/kernel/futex_compat.c [modify] https://crrev.com/c2aedb7b36d6ec7463cb342e3fe0d57a4e226d58/kernel/futex.c [modify] https://crrev.com/c2aedb7b36d6ec7463cb342e3fe0d57a4e226d58/fs/proc/namespaces.c [modify] https://crrev.com/c2aedb7b36d6ec7463cb342e3fe0d57a4e226d58/kernel/ptrace.c [modify] https://crrev.com/c2aedb7b36d6ec7463cb342e3fe0d57a4e226d58/security/commoncap.c
,
Sep 12 2017
,
Sep 12 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/6db5669521763e6390a985b42453e6234fcd03ab commit 6db5669521763e6390a985b42453e6234fcd03ab Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Tue Sep 12 20:33:11 2017 UPSTREAM: Sanitize 'move_pages()' permission checks The 'move_paghes()' system call was introduced long long ago with the same permission checks as for sending a signal (except using CAP_SYS_NICE instead of CAP_SYS_KILL for the overriding capability). That turns out to not be a great choice - while the system call really only moves physical page allocations around (and you need other capabilities to do a lot of it), you can check the return value to map out some the virtual address choices and defeat ASLR of a binary that still shares your uid. So change the access checks to the more common 'ptrace_may_access()' model instead. This tightens the access checks for the uid, and also effectively changes the CAP_SYS_NICE check to CAP_SYS_PTRACE, but it's unlikely that anybody really _uses_ this legacy system call any more (we hav ebetter NUMA placement models these days), so I expect nobody to notice. Famous last words. BUG= chromium:762903 TEST=Build and run Change-Id: Ie5c0299225b5e05a5da3c9e86d9275a28f073f44 Reported-by: Otto Ebeling <otto.ebeling@iki.fi> Acked-by: Eric W. Biederman <ebiederm@xmission.com> Cc: Willy Tarreau <w@1wt.eu> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Guenter Roeck <groeck@chromium.org> (cherry picked from commit 197e7e521384a23) Reviewed-on: https://chromium-review.googlesource.com/657963 Reviewed-by: Dylan Reid <dgreid@chromium.org> (cherry picked from commit d188a47660fa43c07c70c6b10f0b0d01741bd25b) Reviewed-on: https://chromium-review.googlesource.com/664044 [modify] https://crrev.com/6db5669521763e6390a985b42453e6234fcd03ab/mm/migrate.c
,
Sep 13 2017
,
Dec 20 2017
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jan 22 2018
,
Jan 23 2018
,
Mar 27 2018
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by groeck@chromium.org
, Sep 7 2017Owner: groeck@chromium.org
Status: Assigned (was: Untriaged)
Upstream 197e7e521384a23 ("Sanitize 'move_pages()' permission checks")