[<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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
