klibc - Jun 2020 - process '/usr/bin/rsync' started with executable stack

On Thu, Jun 25, 2020 at 01:04:29PM +0300, Dan Carpenter
wrote:
> On Wed, Jun 24, 2020 at 12:39:24PM -0700, Kees Cook wrote:
> > On Wed, Jun 24, 2020 at 07:51:48PM +0300, Dan Carpenter wrote:
> > > In Debian testing the initrd triggers the warning.
> > > 
> > > [   34.529809] process '/usr/bin/fstype' started with
executable stack
> > 
> > Where does fstype come from there? I am going to guess it is either
> > busybox or linked against klibc?
> > 
> > klibc has known problems with executable stacks due to its trampoline
> > implementation:
> > https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks
> 
> Yeah.  It comes from klibc-utils.
This is exactly what I was worried about back in Feb:
https://lore.kernel.org/lkml/202002251341.48BC06E at keescook/

This warning, combined with klibc-based initrds, makes the whole thing
pointless because it will always warn once on boot for the klibc stack,
and then not warn about anything else after that.

It looks like upstream klibc hasn't been touched in about 4 years, and
it's been up to Ben to keep it alive in Debian.

A couple ideas, in order of my preference:

1) stop using klibc-utils[1]. initramfs-tools-core is the only thing with a
   dependency on klibc-utils. Only a few things are missing from busybox.

2) make the warning rate-limited instead?

3) fix the use of trampolines in klibc

Thoughts?

-Kees


[1] Ben appears well aware of this idea, as he suggested it in 2018. :)
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887159

-- 
Kees Cook

Kees Cook dixit:
>3) fix the use of trampolines in klibc
AIUI done in klibc, but post-2.0.7

bye,
//mirabilos
-- 
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh

On Thu, Jun 25, 2020 at 09:16:10PM +0000, Thorsten Glaser
wrote:
> Kees Cook dixit:
> 
> >3) fix the use of trampolines in klibc
> 
> AIUI done in klibc, but post-2.0.7
Ah-ha, I see it. Ben got it fixed in Feb. :)

https://git.kernel.org/pub/scm/libs/klibc/klibc.git/commit/?id=9d8d648e604026b32cad00a84ed6c29cbd157641

I don't see it in Debian? I remain confused, but there's hope!
https://salsa.debian.org/kernel-team/klibc/-/commits/master

-- 
Kees Cook

Le 25/06/2020 ? 22:20, Kees Cook a ?crit?:
> On Thu, Jun 25, 2020 at 01:04:29PM +0300, Dan Carpenter wrote:
>> On Wed, Jun 24, 2020 at 12:39:24PM -0700, Kees Cook wrote:
>>> On Wed, Jun 24, 2020 at 07:51:48PM +0300, Dan Carpenter wrote:
>>>> In Debian testing the initrd triggers the warning.
>>>>
>>>> [   34.529809] process '/usr/bin/fstype' started with
executable stack
>>>
>>> Where does fstype come from there? I am going to guess it is either
>>> busybox or linked against klibc?
>>>
>>> klibc has known problems with executable stacks due to its
trampoline
>>> implementation:
>>> https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks
>>
>> Yeah.  It comes from klibc-utils.
> 
> This is exactly what I was worried about back in Feb:
> https://lore.kernel.org/lkml/202002251341.48BC06E at keescook/
> 
> This warning, combined with klibc-based initrds, makes the whole thing
> pointless because it will always warn once on boot for the klibc stack,
> and then not warn about anything else after that.
> 
> It looks like upstream klibc hasn't been touched in about 4 years, and
> it's been up to Ben to keep it alive in Debian.
> 
> A couple ideas, in order of my preference:
> 
> 1) stop using klibc-utils[1]. initramfs-tools-core is the only thing with a
>     dependency on klibc-utils. Only a few things are missing from busybox.
Does busybox cleanly build with klibc lib ?
If it does, is the result as small ?
> 
> 2) make the warning rate-limited instead?
> 
> 3) fix the use of trampolines in klibc
That's done, see 
https://git.kernel.org/pub/scm/libs/klibc/klibc.git/commit/?id=9d8d648e604026b32cad00a84ed6c29cbd157641

Discussed here 
https://lists.zytor.com/archives/klibc/2020-February/004271.html

Christophe
> 
> Thoughts?
> 
> -Kees
> 
> 
> [1] Ben appears well aware of this idea, as he suggested it in 2018. :)
>      https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887159
>

On Thu, 2020-06-25 at 13:20 -0700, Kees Cook wrote:
> On Thu, Jun 25, 2020 at 01:04:29PM +0300, Dan Carpenter wrote:
> > On Wed, Jun 24, 2020 at 12:39:24PM -0700, Kees Cook wrote:
> > > On Wed, Jun 24, 2020 at 07:51:48PM +0300, Dan Carpenter wrote:
> > > > In Debian testing the initrd triggers the warning.
> > > > 
> > > > [   34.529809] process '/usr/bin/fstype' started
with executable stack
> > > 
> > > Where does fstype come from there? I am going to guess it is
either
> > > busybox or linked against klibc?
> > > 
> > > klibc has known problems with executable stacks due to its
trampoline
> > > implementation:
> > > https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks
> > 
> > Yeah.  It comes from klibc-utils.
> 
> This is exactly what I was worried about back in Feb:
> https://lore.kernel.org/lkml/202002251341.48BC06E at keescook/
> 
> This warning, combined with klibc-based initrds, makes the whole thing
> pointless because it will always warn once on boot for the klibc stack,
> and then not warn about anything else after that.
> 
> It looks like upstream klibc hasn't been touched in about 4 years, and
> it's been up to Ben to keep it alive in Debian.
> 
> A couple ideas, in order of my preference:
> 
> 1) stop using klibc-utils[1]. initramfs-tools-core is the only thing with a
>    dependency on klibc-utils. Only a few things are missing from busybox.
> 
> 2) make the warning rate-limited instead?
> 
> 3) fix the use of trampolines in klibc
It only uses trampolines on alpha, m68k, parisc, s390, and sparc32.  As
of today, the master branch should correctly enable executable stacks
on these and only these architecture.

I have a development branch that sets sa_restorer and disables
executable stacks on alpha, s390, and sparc32:

https://git.kernel.org/pub/scm/libs/klibc/klibc.git/log/?h=execstack-fixes

But I haven't yet tested those changes other than on qemu-user.

The m68k and parisc kernel ports still don't support any alternatives
to trampolines for signal return, or they didn't when I reviewed this
a few months ago.

Ben.
> Thoughts?
> 
> -Kees
> 
> 
> [1] Ben appears well aware of this idea, as he suggested it in 2018. :)
>     https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887159
> 
-- 
Ben Hutchings
Anthony's Law of Force: Don't force it, get a larger hammer.

-------------- 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/20200725/84b845be/attachment.sig>

On Sat, Jul 25, 2020 at 10:27:56PM +0100, Ben Hutchings
wrote:
> On Thu, 2020-06-25 at 13:20 -0700, Kees Cook wrote:
> > On Thu, Jun 25, 2020 at 01:04:29PM +0300, Dan Carpenter wrote:
> > > On Wed, Jun 24, 2020 at 12:39:24PM -0700, Kees Cook wrote:
> > > > On Wed, Jun 24, 2020 at 07:51:48PM +0300, Dan Carpenter
wrote:
> > > > > In Debian testing the initrd triggers the warning.
> > > > > 
> > > > > [   34.529809] process '/usr/bin/fstype'
started with executable stack
> > > > 
> > > > Where does fstype come from there? I am going to guess it is
either
> > > > busybox or linked against klibc?
> > > > 
> > > > klibc has known problems with executable stacks due to its
trampoline
> > > > implementation:
> > > >
https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks
> > > 
> > > Yeah.  It comes from klibc-utils.
> > 
> > This is exactly what I was worried about back in Feb:
> > https://lore.kernel.org/lkml/202002251341.48BC06E at keescook/
> > 
> > This warning, combined with klibc-based initrds, makes the whole thing
> > pointless because it will always warn once on boot for the klibc
stack,
> > and then not warn about anything else after that.
> > 
> > It looks like upstream klibc hasn't been touched in about 4 years,
and
> > it's been up to Ben to keep it alive in Debian.
> > 
> > A couple ideas, in order of my preference:
> > 
> > 1) stop using klibc-utils[1]. initramfs-tools-core is the only thing
with a
> >    dependency on klibc-utils. Only a few things are missing from
busybox.
> > 
> > 2) make the warning rate-limited instead?
> > 
> > 3) fix the use of trampolines in klibc
> 
> It only uses trampolines on alpha, m68k, parisc, s390, and sparc32.  As
> of today, the master branch should correctly enable executable stacks
> on these and only these architecture.
> 
> I have a development branch that sets sa_restorer and disables
> executable stacks on alpha, s390, and sparc32:
> 
> https://git.kernel.org/pub/scm/libs/klibc/klibc.git/log/?h=execstack-fixes
Awesome! Thanks for tackling this. :)

-- 
Kees Cook