linux-kernel - Re: [PATCH v4 0/4] SROP Mitigation: Sigreturn Cookies

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]

Message-ID: <20160401125746.GC2088@uranus.lan>
Date:	Fri, 1 Apr 2016 15:57:46 +0300
From:	Cyrill Gorcunov <gorcunov@...il.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Scotty Bauer <sbauer@....utah.edu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andy Lutomirski <luto@...capital.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"kernel-hardening@...ts.openwall.com" 
	<kernel-hardening@...ts.openwall.com>, X86 ML <x86@...nel.org>,
	Andi Kleen <ak@...ux.intel.com>,
	Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>, wmealing@...hat.com,
	criu@...nvz.org, Pavel Emelyanov <xemul@...tuozzo.com>,
	Andrey Vagin <avagin@...tuozzo.com>
Subject: Re: [PATCH v4 0/4] SROP Mitigation: Sigreturn Cookies

On Thu, Mar 31, 2016 at 03:22:38PM -0500, Eric W. Biederman wrote:
> 
> Cc' the Criu list to attempt to give them a heads up.

Thanks Eric! I managed to miss this thread (I try to scan
lkml descussions one a day in my inbox, but this one somehow
escaped, thank you!)

> Scotty Bauer <sbauer@....utah.edu> writes:
...
> >> Because if it does break anything, it needs to be turned off by
> >> default. That's a hard rule. And since that would be largely defeating
> >> the whole point o fthe series, I think we really need to have made
> >> sure nothing breaks before a patch series like this can be accepted.
> >> 
> >> That said, if this is done right, I don't think it will break
> >> anything. CRIU may indeed be a special case, but CRIU isn't really a
> >> normal application, and the CRIU people may need to turn this off
> >> explicitly, if it does break.
> >> 
> >> But yes, dosemu needs to be tested, and needs to just continue
> >> working. But does dosemu actually create a signal stack, as opposed to
> >> just playing with one that has been created for it? I thought it was
> >> just the latter case, which should be ok even with a magic cookie in
> >> there.
...
> > For what it's worth this series is breaking CRIU, I just tested:
> >
> > root@...e0:/mnt/criu# criu restore -vvvv -o restore.log --shell-job
> > root@...e0:/mnt/criu# tail -3 /var/log/syslog
> > Mar 29 17:12:08 localhost kernel: [ 3554.625535] Possible exploit attempt or buggy program!
> > Mar 29 17:12:08 localhost kernel: [ 3554.625535] If you believe this is an error you can disable SROP  Protection by #echo 1 > /proc/sys/kernel/disable-srop-protection
> > Mar 29 17:12:08 localhost kernel: [ 3554.625545] test_[25305] bad frame in rt_sigreturn frame:000000000001e540 ip:7f561542cf20 sp:7ffe004ecfd8 orax:ffffffffffffffff in libc-2.19.so[7f561536c000+1bb0]
> > root@...e0:/mnt/criu# echo 1 > /proc/sys/kernel/disable-srop-protection 
> > root@...e0:/mnt/criu# criu restore -vvvv -o restore.log --shell-job
> > slept for one second
> > slept for one second
> > slept for one second
> > slept for one second
> > root@...e0:/mnt/criu#
> 
> Which means that if checkpoint/restart is going to continue to be
> something that is possible in Linux it should be possible to
> save/restore the per process sig_cookie.  Perhaps with a prctl?

Yes please. Currently (together with other aims) we're trying to
remove "root-only" requirement from criu, so user would be able
to c/r non-privileged processes without sudo/su. Thus I presume
such prctl will be cap-sysadmin only and we will have to run some
suid'ed daemon for it or something.

> This should be addressed as part of this patchset as making that
> information too easily accessible/changable will defeat the security
> guarantees.  Making it too difficult to do destroys the ability to
> migrate a process from one kernel to another.  As the existence of CRIU
> attests it is desirable to have a checkpoint/restart capability in the
> kernel.

To change sigframe an attacked process must have had some code
already injected and this cookie guard will help but not _that_
much I think.

> > I'm working on getting dosemu up and running-- are there any other applications
> > off the top of your head that I should be testing with?
> 
> There are a set of POSIX functions setcontext, getcontext, makecontext
> and swapcontext that to the best of my knowledge deal in signal stacks.
> Although I don't know that they use sigreturn.  Anything that makes use
> of those is potentially affected.
> 
> Perhaps you can find binaries that care by looking for libraries and
> executables that import those elf symbols.  glibc certainly provides
> them.

	Cyrill