Issue metadata
Sign in to add a comment
|
Security: Integer overflow in Linux's create_elf_tables() |
||||||||||||||||||||||
Issue descriptionPer https://www.openwall.com/lists/oss-security/2018/09/25/4 We discovered an integer overflow in the Linux kernel's create_elf_tables() function: on a 64-bit system, a local attacker can exploit this vulnerability via a SUID-root binary and obtain full root privileges. Only kernels with commit b6a2fea39318 ("mm: variable length argument support", from July 19, 2007) but without commit da029c11e6b1 ("exec: Limit arg stack to at most 75% of _STK_LIM", from July 7, 2017) are exploitable. Most Linux distributions backported commit da029c11e6b1 to their long-term-supported kernels, but Red Hat Enterprise Linux and CentOS (and Debian 8, the current "oldstable" version) have not, and are therefore vulnerable and exploitable. Seems like our pre-4.4 kernels are vulnerable. Mitigating factors: The PoC seems to require quite a bit of memory though, so it'll likely not work without further adjustments on Chrome OS. We should probably apply backports where they are available. Assigning to zsm@ for further triage.
,
Sep 26
,
Sep 26
,
Sep 26
The bug is caused if commit b6a2fea39318 ("mm: variable length argument
support") is present and commit da029c11e6b1 ("exec:
Limit arg stack to at most 75% of _STK_LIM") is not present.
v4.14, v4.4 have both commits.
v3.18 has b6a2fea39318 does not have da029c11e6b1. The fix applies cleanly.
Older kernels have b6a2fea39318 does not have da029c11e6b1. The fix does not apply cleanly.
,
Sep 26
3.18.y seems to have the fix already, will pull it down to v3.18.
,
Sep 26
,
Sep 28
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/54f3b9ec712baddd4c5c1681715c58e72150d57a commit 54f3b9ec712baddd4c5c1681715c58e72150d57a Author: Kees Cook <keescook@chromium.org> Date: Fri Sep 28 20:34:35 2018 UPSTREAM: exec: Limit arg stack to at most 75% of _STK_LIM commit da029c11e6b12f321f36dac8771e833b65cec962 upstream. To avoid pathological stack usage or the need to special-case setuid execs, just limit all arg stack usage to at most 75% of _STK_LIM (6MB). BUG= chromium:889448 TEST=None Change-Id: I874c7b14790cee1a959713bc85ebdca215488fde Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 915d918369390e5746794ca0d38a40ba05745b4a from linux-3.18.y) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1246402 [modify] https://crrev.com/54f3b9ec712baddd4c5c1681715c58e72150d57a/fs/exec.c
,
Oct 1
"Our exploit requires "only" 2 * 16GB = 32GB of memory, instead of 3 * 16GB = 48GB or more, because we use a few tricks to reduce its memory footprint (for example, we replace the nearly 16GB of equal argument pointers with equivalent file-backed mappings that consume practically no memory)." It should be fine to not backport da029c11e6b1 to <= v3.14. Marking as Fixed.
,
Oct 2
,
Jan 8
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 sheriffbot@chromium.org
, Sep 26