klibc - Feb 2020 - Latest kernel reports "process '/bin/sh' started with executable stack"

With latest kernel (Linus tree as of 5.6 merge window), I get the 
following warning in the kernel 'dmesg':

[    5.746588] process '/bin/sh' started with executable stack

This comes from commit 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/exec.c?id=47a2ebb7f5053387f5753b524f4920b9b829f922
"execve: warn if process starts with executable stack"

objdump -x shows:

/usr/lib/klibc/bin/sh:     file format elf32-powerpc
/usr/lib/klibc/bin/sh
architecture: powerpc:common, flags 0x00000102:
EXEC_P, D_PAGED
start address 0x10000140

Program Header:
     PHDR off    0x00000034 vaddr 0x10000034 paddr 0x10000034 align 2**2
          filesz 0x000000a0 memsz 0x000000a0 flags r-x
   INTERP off    0x000000d4 vaddr 0x100000d4 paddr 0x100000d4 align 2**0
          filesz 0x0000002a memsz 0x0000002a flags r--
     LOAD off    0x00000000 vaddr 0x10000000 paddr 0x10000000 align 2**16
          filesz 0x00010928 memsz 0x00010928 flags r-x
     LOAD off    0x00010928 vaddr 0x10020928 paddr 0x10020928 align 2**16
          filesz 0x00000144 memsz 0x00004880 flags rw-
    STACK off    0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**4
          filesz 0x00000000 memsz 0x00000000 flags rwx


Indeed, the stack is rwx, which is unexpected. And it is the case for 
all klibc tools.

How can we fix that ?

Thanks
Christophe

On Thu, Feb 06, 2020 at 04:38:34PM +0100, Christophe Leroy
wrote:
> With latest kernel (Linus tree as of 5.6 merge window), I get the following
> warning in the kernel 'dmesg':
> 
> [    5.746588] process '/bin/sh' started with executable stack
> 
> This comes from commit
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/exec.c?id=47a2ebb7f5053387f5753b524f4920b9b829f922
> "execve: warn if process starts with executable stack"
This commit is not a good idea. Does it think it's only in x86_64 land?
> 
> objdump -x shows:
> 
> /usr/lib/klibc/bin/sh:     file format elf32-powerpc
> /usr/lib/klibc/bin/sh
> architecture: powerpc:common, flags 0x00000102:
> EXEC_P, D_PAGED
> start address 0x10000140
> 
> Program Header:
>     PHDR off    0x00000034 vaddr 0x10000034 paddr 0x10000034 align 2**2
>          filesz 0x000000a0 memsz 0x000000a0 flags r-x
>   INTERP off    0x000000d4 vaddr 0x100000d4 paddr 0x100000d4 align 2**0
>          filesz 0x0000002a memsz 0x0000002a flags r--
>     LOAD off    0x00000000 vaddr 0x10000000 paddr 0x10000000 align 2**16
>          filesz 0x00010928 memsz 0x00010928 flags r-x
>     LOAD off    0x00010928 vaddr 0x10020928 paddr 0x10020928 align 2**16
>          filesz 0x00000144 memsz 0x00004880 flags rw-
>    STACK off    0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**4
>          filesz 0x00000000 memsz 0x00000000 flags rwx
> 
> 
> Indeed, the stack is rwx, which is unexpected. And it is the case for all
> klibc tools.
> 
> How can we fix that ?
klibc uses trampolines for its setjmp implementation. I ran into this
years ago when eradicating executable stacks from Ubuntu:
https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks

-- 
Kees Cook

On Wed, Feb 26, 2020 at 12:37 AM Kees Cook <keescook at chromium.org>
wrote:
>
> On Thu, Feb 06, 2020 at 04:38:34PM +0100, Christophe Leroy wrote:
> > With latest kernel (Linus tree as of 5.6 merge window), I get the
following
> > warning in the kernel 'dmesg':
> >
> > [    5.746588] process '/bin/sh' started with executable stack
> >
> > This comes from commit
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/exec.c?id=47a2ebb7f5053387f5753b524f4920b9b829f922
> > "execve: warn if process starts with executable stack"
>
> This commit is not a good idea. Does it think it's only in x86_64 land?
...
> >
> > Indeed, the stack is rwx, which is unexpected. And it is the case for
all
> > klibc tools.
> >
> > How can we fix that ?
>
> klibc uses trampolines for its setjmp implementation. I ran into this
> years ago when eradicating executable stacks from Ubuntu:
> https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks
debian sid/unstable sparc64
$ uname -a
Linux ttip 5.6.0-rc3 #27 SMP Mon Feb 24 14:11:35 MSK 2020 sparc64 GNU/Linux

$ dmesg | grep -i exec
[    5.312263] process '/usr/bin/fstype' started with executable stack

$ readelf -lW /usr/lib/klibc/bin/fstype |grep GNU_STACK
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000
0x000000 0x000000 RWE 0x10

$ objdump -x /usr/lib/klibc/bin/fstype  | grep -A1 STACK
   STACK off    0x0000000000000000 vaddr 0x0000000000000000 paddr
0x0000000000000000 align 2**4
         filesz 0x0000000000000000 memsz 0x0000000000000000 flags rwx

On Tue, 2020-02-25 at 13:36 -0800, Kees Cook wrote:
> On Thu, Feb 06, 2020 at 04:38:34PM +0100, Christophe Leroy wrote:
[...]
> > Indeed, the stack is rwx, which is unexpected. And it is the case for
all
> > klibc tools.
> > 
> > How can we fix that ?
> 
> klibc uses trampolines for its setjmp implementation. I ran into this
> years ago when eradicating executable stacks from Ubuntu:
> https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks
I've looked at all the setjmp() implementations and didn't spot any use
of trampolines.

Ben.

-- 
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL:
<https://lists.zytor.com/archives/klibc/attachments/20200228/0931c8ec/attachment.sig>

On Thu, 2020-02-06 at 16:38 +0100, Christophe Leroy
wrote:
> With latest kernel (Linus tree as of 5.6 merge window), I get the 
> following warning in the kernel 'dmesg':
> 
> [    5.746588] process '/bin/sh' started with executable stack
[...]
> Indeed, the stack is rwx, which is unexpected. And it is the case for 
> all klibc tools.
> 
> How can we fix that ?
Thanks for your report.  It turns out that the GNU assembler still
doesn't disable executable stacks by default, and we need to explicitly
tell it to do so.  I've just pushed a commit that appears to fix this;
can you test whether it fixes the warning for you?

Ben.

-- 
Ben Hutchings
It is easier to change the specification to fit the program
than vice versa.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL:
<https://lists.zytor.com/archives/klibc/attachments/20200229/55062a23/attachment.sig>