Red Hat Bugzilla – Bug 1330056
Kernel: ppc64 sbrk returns executable heap in 32-bit emulation mode
Last modified: 2018-08-28 18:04:47 EDT
Linux kernel built for the 64-bit PowerPC(CONFIG_PPC) platform, with 32-bit emulation support is vulnerable to a potential privilege escalation issue. It could occur because sbrk(2) call on PPC64 seems to return an address of the executable heap area. Note: This issue by itself does not lead to privilege escalation, but only adds to weaken the system . One would need another kernel vulnerability to leverage this weakness and escalate their privileges on a system.
Created kernel tracking bugs for this issue: Affects: fedora-all [bug 1330058]
Acknowledgements: Florian Weimer (Red Hat)
Statement: This issue affects the versions of the Linux kernel as shipped with Red Hat Enterprise Linux 5, 6 and 7. Future kernel updates for Red Hat Enterprise Linux 5, 6 and 7 may address this issue.
A hint to an explanation is contained in arch/powerpc/include/asm/page.h: /* * Unfortunately the PLT is in the BSS in the PPC32 ELF ABI, * and needs to be executable. This means the whole heap ends * up being executable. */ #define VM_DATA_DEFAULT_FLAGS32 (VM_READ | VM_WRITE | VM_EXEC | \ VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC) But this does not make much sense to me.
Raised upstream (I think): https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-May/143113.html
I can confirm it this way. 32-bit binary has rwxp mappings: # ./busybox cat /proc/self/maps 00100000-00120000 r-xp 00000000 00:00 0 [vdso] 10000000-10230000 r-xp 00000000 fd:00 34704270 /home/busybox/busybox 10230000-10250000 rwxp 00220000 fd:00 34704270 /home/busybox/busybox 10970000-109b0000 rwxp 00000000 00:00 0 [heap] ffae0000-ffb10000 rw-p 00000000 00:00 0 [stack] whereas 64-bit one does not, they are rw-p in this case: # busybox cat /proc/self/maps 10000000-10270000 r-xp 00000000 fd:00 1112737 /usr/sbin/busybox 10270000-102a0000 rw-p 00270000 fd:00 1112737 /usr/sbin/busybox 10034410000-10034450000 rw-p 00000000 00:00 0 [heap] 3fff9f540000-3fff9f560000 r-xp 00000000 00:00 0 [vdso] 3fffddd60000-3fffddd90000 rw-p 00000000 00:00 0 [stack]
(In reply to Denys Vlasenko from comment #7) > I can confirm it this way. 32-bit binary has rwxp mappings: Just a caveat: I think it is not totally unheard of that the kernel reports protection flags that are not supported by the hardware (but this doesn't apply here because the hardware support is present, the defaults just aren't the one we want).
Reproducer: https://pagure.io/execmod-tests
Looks like there was a patch to avoid having _all_ binaries with executable brk: https://lkml.org/lkml/2012/9/30/138 The patch makes ELF loader respect X bit in ELF load header. Thus, only programs linked with "old PLT style" will have them mapped X, whereas --secure-plt linked ones won't.
Patch works for rhel7: these messages are gone: FAIL exec malloc (small) (unexpected result) FAIL exec malloc (page size) (unexpected result)
(In reply to Denys Vlasenko from comment #10) > Looks like there was a patch to avoid having _all_ binaries with executable > brk: > > https://lkml.org/lkml/2012/9/30/138 > > The patch makes ELF loader respect X bit in ELF load header. Thus, only > programs linked with "old PLT style" will have them mapped X, whereas > --secure-plt linked ones won't. Great find. This patch is what I expected what needed to be done to fix this. (In reply to Denys Vlasenko from comment #11) > Patch works for rhel7: these messages are gone: > > FAIL exec malloc (small) (unexpected result) > FAIL exec malloc (page size) (unexpected result) Could you check that a decently sized program compiled with “gcc -Wl,--bss-plt” still works? It should have an RWE segment according to “eu-readelf -l”: LOAD 0x00fefc 0x1001fefc 0x1001fefc 0x001120 0x0022dc RWE 0x10000
(In reply to Florian Weimer from comment #12) > (In reply to Denys Vlasenko from comment #10) > Could you check that a decently sized program compiled with “gcc > -Wl,--bss-plt” still works? It should have an RWE segment according to > “eu-readelf -l”: > > LOAD 0x00fefc 0x1001fefc 0x1001fefc 0x001120 0x0022dc RWE 0x10000 Yes, I built such a binary and it works on a patched kernel. Tried rhel5, rhel6 and rhel7.
Submitted mainline patch: https://lkml.org/lkml/2016/8/1/547
Patch is in Linus tree now: commit 16e72e9b30986ee15f17fbb68189ca842c32af58 Author: Denys Vlasenko <dvlasenk@redhat.com> Date: Wed Feb 22 15:45:16 2017 -0800 powerpc: do not make the entire heap executable
This issue has been addressed in the following products: Red Hat Enterprise Linux 7.3 Extended Update Support Via RHSA-2017:2437 https://access.redhat.com/errata/RHSA-2017:2437