Issue metadata
Sign in to add a comment
|
CVE-2017-2618 CrOS: Vulnerability reported in Linux kernel |
||||||||||||||||||||||
Issue descriptionVOMIT (go/vomit) has received an external vulnerability report for the Linux kernel. Advisory: CVE-2017-2618 Details: http://vomit.googleplex.com/advisory?id=CVE/CVE-2017-2618 CVSS severity score: 4.9/10.0 Description: A flaw was found in the Linux kernel's handling of clearing SELinux attributes on /proc/pid/attr files before 4.9.10. An empty (null) write to this file can crash the system by causing the system to attempt to access unmapped kernel memory. This bug was filed by http://go/vomit Please contact us at vomit-team@google.com if you need any assistance.
,
Sep 24
,
Sep 25
,
Sep 25
,
Sep 26
Patch is in CQ now : https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1240896
,
Sep 26
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/48b8aeeb65f4749d1c6cce01e12b9b2c2e084f52 commit 48b8aeeb65f4749d1c6cce01e12b9b2c2e084f52 Author: Stephen Smalley <sds@tycho.nsa.gov> Date: Wed Sep 26 21:59:56 2018 UPSTREAM: selinux: fix off-by-one in setprocattr commit 0c461cb727d146c9ef2d3e86214f498b78b7d125 upstream. SELinux tries to support setting/clearing of /proc/pid/attr attributes from the shell by ignoring terminating newlines and treating an attribute value that begins with a NUL or newline as an attempt to clear the attribute. However, the test for clearing attributes has always been wrong; it has an off-by-one error, and this could further lead to reading past the end of the allocated buffer since commit bb646cdb12e75d82258c2f2e7746d5952d3e321a ("proc_pid_attr_write(): switch to memdup_user()"). Fix the off-by-one error. Even with this fix, setting and clearing /proc/pid/attr attributes from the shell is not straightforward since the interface does not support multiple write() calls (so shells that write the value and newline separately will set and then immediately clear the attribute, requiring use of echo -n to set the attribute), whereas trying to use echo -n "" to clear the attribute causes the shell to skip the write() call altogether since POSIX says that a zero-length write causes no side effects. Thus, one must use echo -n to set and echo without -n to clear, as in the following example: $ echo -n unconfined_u:object_r:user_home_t:s0 > /proc/$$/attr/fscreate $ cat /proc/$$/attr/fscreate unconfined_u:object_r:user_home_t:s0 $ echo "" > /proc/$$/attr/fscreate $ cat /proc/$$/attr/fscreate Note the use of /proc/$$ rather than /proc/self, as otherwise the cat command will read its own attribute value, not that of the shell. There are no users of this facility to my knowledge; possibly we should just get rid of it. UPDATE: Upon further investigation it appears that a local process with the process:setfscreate permission can cause a kernel panic as a result of this bug. This patch fixes CVE-2017-2618. BUG= chromium:888312 TEST=None Change-Id: I6c285a84286aaa2b2fc298bd6e1b12a740388050 Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov> [PM: added the update about CVE-2017-2618 to the commit description] Signed-off-by: Paul Moore <paul@paul-moore.com> Signed-off-by: James Morris <james.l.morris@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 0f436bf3f81b0674414d198a01bffc4ecae4590e from linux-3.18.y) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1240896 [modify] https://crrev.com/48b8aeeb65f4749d1c6cce01e12b9b2c2e084f52/security/selinux/hooks.c
,
Sep 28
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/f28e5fd9555b60454f9cc5ee5c6e02e0a4b1a39a commit f28e5fd9555b60454f9cc5ee5c6e02e0a4b1a39a Author: Stephen Smalley <sds@tycho.nsa.gov> Date: Fri Sep 28 02:44:52 2018 UPSTREAM: selinux: fix off-by-one in setprocattr SELinux tries to support setting/clearing of /proc/pid/attr attributes from the shell by ignoring terminating newlines and treating an attribute value that begins with a NUL or newline as an attempt to clear the attribute. However, the test for clearing attributes has always been wrong; it has an off-by-one error, and this could further lead to reading past the end of the allocated buffer since commit bb646cdb12e75d82258c2f2e7746d5952d3e321a ("proc_pid_attr_write(): switch to memdup_user()"). Fix the off-by-one error. Even with this fix, setting and clearing /proc/pid/attr attributes from the shell is not straightforward since the interface does not support multiple write() calls (so shells that write the value and newline separately will set and then immediately clear the attribute, requiring use of echo -n to set the attribute), whereas trying to use echo -n "" to clear the attribute causes the shell to skip the write() call altogether since POSIX says that a zero-length write causes no side effects. Thus, one must use echo -n to set and echo without -n to clear, as in the following example: $ echo -n unconfined_u:object_r:user_home_t:s0 > /proc/$$/attr/fscreate $ cat /proc/$$/attr/fscreate unconfined_u:object_r:user_home_t:s0 $ echo "" > /proc/$$/attr/fscreate $ cat /proc/$$/attr/fscreate Note the use of /proc/$$ rather than /proc/self, as otherwise the cat command will read its own attribute value, not that of the shell. There are no users of this facility to my knowledge; possibly we should just get rid of it. UPDATE: Upon further investigation it appears that a local process with the process:setfscreate permission can cause a kernel panic as a result of this bug. This patch fixes CVE-2017-2618. BUG= chromium:888312 TEST=None Change-Id: I6c285a84286aaa2b2fc298bd6e1b12a740388050 Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov> [PM: added the update about CVE-2017-2618 to the commit description] Cc: stable@vger.kernel.org # 3.5: d6ea83ec6864e Signed-off-by: Paul Moore <paul@paul-moore.com> Signed-off-by: James Morris <james.l.morris@oracle.com> (cherry picked from commit 0c461cb727d146c9ef2d3e86214f498b78b7d125) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1249723 [modify] https://crrev.com/f28e5fd9555b60454f9cc5ee5c6e02e0a4b1a39a/security/selinux/hooks.c
,
Sep 28
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/a038086a7cae13f99242a45dc36e3a4879c77840 commit a038086a7cae13f99242a45dc36e3a4879c77840 Author: Stephen Smalley <sds@tycho.nsa.gov> Date: Fri Sep 28 02:44:43 2018 UPSTREAM: selinux: fix off-by-one in setprocattr SELinux tries to support setting/clearing of /proc/pid/attr attributes from the shell by ignoring terminating newlines and treating an attribute value that begins with a NUL or newline as an attempt to clear the attribute. However, the test for clearing attributes has always been wrong; it has an off-by-one error, and this could further lead to reading past the end of the allocated buffer since commit bb646cdb12e75d82258c2f2e7746d5952d3e321a ("proc_pid_attr_write(): switch to memdup_user()"). Fix the off-by-one error. Even with this fix, setting and clearing /proc/pid/attr attributes from the shell is not straightforward since the interface does not support multiple write() calls (so shells that write the value and newline separately will set and then immediately clear the attribute, requiring use of echo -n to set the attribute), whereas trying to use echo -n "" to clear the attribute causes the shell to skip the write() call altogether since POSIX says that a zero-length write causes no side effects. Thus, one must use echo -n to set and echo without -n to clear, as in the following example: $ echo -n unconfined_u:object_r:user_home_t:s0 > /proc/$$/attr/fscreate $ cat /proc/$$/attr/fscreate unconfined_u:object_r:user_home_t:s0 $ echo "" > /proc/$$/attr/fscreate $ cat /proc/$$/attr/fscreate Note the use of /proc/$$ rather than /proc/self, as otherwise the cat command will read its own attribute value, not that of the shell. There are no users of this facility to my knowledge; possibly we should just get rid of it. UPDATE: Upon further investigation it appears that a local process with the process:setfscreate permission can cause a kernel panic as a result of this bug. This patch fixes CVE-2017-2618. BUG= chromium:888312 TEST=None Change-Id: I6c285a84286aaa2b2fc298bd6e1b12a740388050 Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov> [PM: added the update about CVE-2017-2618 to the commit description] Cc: stable@vger.kernel.org # 3.5: d6ea83ec6864e Signed-off-by: Paul Moore <paul@paul-moore.com> Signed-off-by: James Morris <james.l.morris@oracle.com> (cherry picked from commit 0c461cb727d146c9ef2d3e86214f498b78b7d125) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1249724 [modify] https://crrev.com/a038086a7cae13f99242a45dc36e3a4879c77840/security/selinux/hooks.c
,
Sep 28
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/c3243734ce73159616d16f4c5d0107938acbf2c7 commit c3243734ce73159616d16f4c5d0107938acbf2c7 Author: Stephen Smalley <sds@tycho.nsa.gov> Date: Fri Sep 28 17:11:00 2018 UPSTREAM: selinux: fix off-by-one in setprocattr SELinux tries to support setting/clearing of /proc/pid/attr attributes from the shell by ignoring terminating newlines and treating an attribute value that begins with a NUL or newline as an attempt to clear the attribute. However, the test for clearing attributes has always been wrong; it has an off-by-one error, and this could further lead to reading past the end of the allocated buffer since commit bb646cdb12e75d82258c2f2e7746d5952d3e321a ("proc_pid_attr_write(): switch to memdup_user()"). Fix the off-by-one error. Even with this fix, setting and clearing /proc/pid/attr attributes from the shell is not straightforward since the interface does not support multiple write() calls (so shells that write the value and newline separately will set and then immediately clear the attribute, requiring use of echo -n to set the attribute), whereas trying to use echo -n "" to clear the attribute causes the shell to skip the write() call altogether since POSIX says that a zero-length write causes no side effects. Thus, one must use echo -n to set and echo without -n to clear, as in the following example: $ echo -n unconfined_u:object_r:user_home_t:s0 > /proc/$$/attr/fscreate $ cat /proc/$$/attr/fscreate unconfined_u:object_r:user_home_t:s0 $ echo "" > /proc/$$/attr/fscreate $ cat /proc/$$/attr/fscreate Note the use of /proc/$$ rather than /proc/self, as otherwise the cat command will read its own attribute value, not that of the shell. There are no users of this facility to my knowledge; possibly we should just get rid of it. UPDATE: Upon further investigation it appears that a local process with the process:setfscreate permission can cause a kernel panic as a result of this bug. This patch fixes CVE-2017-2618. BUG= chromium:888312 TEST=None Change-Id: I6c285a84286aaa2b2fc298bd6e1b12a740388050 Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov> [PM: added the update about CVE-2017-2618 to the commit description] Cc: stable@vger.kernel.org # 3.5: d6ea83ec6864e Signed-off-by: Paul Moore <paul@paul-moore.com> Signed-off-by: James Morris <james.l.morris@oracle.com> (cherry picked from commit 0c461cb727d146c9ef2d3e86214f498b78b7d125) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1249725 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> [modify] https://crrev.com/c3243734ce73159616d16f4c5d0107938acbf2c7/security/selinux/hooks.c
,
Sep 28
,
Sep 29
,
Jan 5
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 |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by zsm@chromium.org
, Sep 24Labels: Security_Severity-Medium Security_Impact-Stable Pri-2
Owner: zsm@chromium.org
Status: Assigned (was: Untriaged)
Upstream commit is 0c461cb72("selinux: fix off-by-one in setprocattr"). This commit is present in v4.14, v4.4. Older kernels do not have this commit. This commit is present in 3.18.y, so will pull it down into v3.18.