linux-kernel - Re: process '/usr/bin/rsync' started with executable stack

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 25 Jul 2020 22:27:56 +0100
From:   Ben Hutchings <ben@...adent.org.uk>
To:     Kees Cook <keescook@...omium.org>,
        Dan Carpenter <dan.carpenter@...cle.com>
Cc:     Christian Kujau <lists@...dbynature.de>,
        Alexey Dobriyan <adobriyan@...il.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Willy Tarreau <w@....eu>, linux-kernel@...r.kernel.org,
        klibc@...ts.zytor.com, "H. Peter Anvin" <hpa@...or.com>
Subject: Re: process '/usr/bin/rsync' started with executable stack

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@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.


Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)