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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <202006251253.2893D4F67@keescook>
Date:   Thu, 25 Jun 2020 13:20:19 -0700
From:   Kees Cook <keescook@...omium.org>
To:     Dan Carpenter <dan.carpenter@...cle.com>,
        Ben Hutchings <ben@...adent.org.uk>
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, 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

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ