Bug 1330056 - Kernel: ppc64 sbrk returns executable heap in 32-bit emulation mode
Summary: Kernel: ppc64 sbrk returns executable heap in 32-bit emulation mode
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1330058 1330059 1330060 1330061 1330062 1330063 1330064
Blocks: 1330074
TreeView+ depends on / blocked
 
Reported: 2016-04-25 11:03 UTC by Prasad Pandit
Modified: 2021-08-11 12:20 UTC (History)
35 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-06-08 02:50:59 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2017:2437 0 normal SHIPPED_LIVE Important: kernel security and bug fix update 2017-08-08 20:14:23 UTC

Description Prasad Pandit 2016-04-25 11:03:44 UTC
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.

Comment 1 Prasad Pandit 2016-04-25 11:04:30 UTC
Created kernel tracking bugs for this issue:

Affects: fedora-all [bug 1330058]

Comment 4 Prasad Pandit 2016-04-25 11:54:59 UTC
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.

Comment 5 Florian Weimer 2016-05-03 08:20:33 UTC
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.

Comment 6 Florian Weimer 2016-05-12 13:41:50 UTC
Raised upstream (I think):

  https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-May/143113.html

Comment 7 Denys Vlasenko 2016-07-27 16:03:10 UTC
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]

Comment 8 Florian Weimer 2016-07-27 20:31:59 UTC
(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).

Comment 9 Florian Weimer 2016-07-28 16:01:33 UTC
Reproducer: https://pagure.io/execmod-tests

Comment 10 Denys Vlasenko 2016-07-29 17:08:42 UTC
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.

Comment 11 Denys Vlasenko 2016-07-30 20:31:45 UTC
Patch works for rhel7: these messages are gone:

  FAIL exec  malloc (small) (unexpected result)
  FAIL exec  malloc (page size) (unexpected result)

Comment 12 Florian Weimer 2016-07-31 13:49:21 UTC
(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

Comment 13 Denys Vlasenko 2016-08-01 19:36:51 UTC
(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.

Comment 14 Denys Vlasenko 2016-08-03 13:23:29 UTC
Submitted mainline patch:
https://lkml.org/lkml/2016/8/1/547

Comment 15 Denys Vlasenko 2017-03-08 13:56:10 UTC
Patch is in Linus tree now:

commit 16e72e9b30986ee15f17fbb68189ca842c32af58
Author: Denys Vlasenko <dvlasenk>
Date:   Wed Feb 22 15:45:16 2017 -0800

    powerpc: do not make the entire heap executable

Comment 16 errata-xmlrpc 2017-08-08 16:20:11 UTC
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


Note You need to log in before you can comment on or make changes to this bug.