[CRIU] Hardening the criu service daemon

[Florian Weimer]

On 09/01/2015 11:45 AM, Pavel Emelyanov wrote:
> On 08/25/2015 02:55 PM, Florian Weimer wrote:
>> This was previously discussed privately, but we agreed to make this
>> public even before fixes are available, to ensure broadest possible
>> review of the solution we come up with.
>>
>> The service daemon currently has at least two sets of security issues:
>>
>> * CVE-2015-5228
>> https://bugzilla.redhat.com/show_bug.cgi?id=1255782
>>
>> The service daemon writes to arbitrary places in the file system.  One
>> file file (criu.log) is even created with ownership matching that of the
>> requesting process, which gives a fairly direct privilege escalation
>> path to full root for any local user.  The dump files themselves have
>> user-controlled contents, which can likely be exploited as well.
> 
> You told that you had similar issue in abrtd. Maybe we can poke kernel guys
> to provide the userspace the way to do some system call on behalf of any 
> other process? Of course, only allowed for root or those having ptrace_may_access
> ability.

The challenge is to obtain a stable identifier for that other process.
In the abrt crash dumper, this is easy because the process is in a
zombie-like state, and its PID cannot be reused until the crash dumper
completes, and the associated UIDs will not change, either.  I don't
think this is true for a client process requesting services from the
criu daemon.

> Well, we (in theory) can _make_ another process do what we want using the
> parasite code injection technique. CRIU already does this on the process it
> dumps, it can also do the same on the process that requests the dump. This
> would be heavier version of the above suggestion :)

You'd still need something stronger than a PID to attach to the process
(the requester process).

>> The file creation issue could also be fixed by having the requesting
>> process create the files and pass file descriptors to the dumping
>> process (or pass all data over the socket).  The kernel ptrace policy
>> enforcement could be emulated in user space.  These approaches are quite
>> brittle and dependent on specific security modules, I think.
>>
>>
>> The value of the long-running service daemon is not completely clear to
>> me.  Maybe it would be better to spawn a service on demand from libcriu?
> 
> The service appeared from the fact that non-root couldn't access many crucial
> for dump kernel APIs even for self. So we spawned a service with root caps
> and ask one for help. Later there appeared the so called "swrk mode". This
> is when you fork() + exec() CRIU and feed RPC commands into it as to a service.
> Provided criu binary is suid-ed it works exactly the same as service, so
> yes, standalone service is pretty much obsoleted by this.
> 
> But the question is -- does suid-ed criu suffer from the same set of CVE-s?

Oh.  I had no idea anyone would assume it's safe to install the criu
command SUID-anything.

I think so.  It seems even worse because of the scripts interface, which
is apparently not disabled in the SUID case, only for the daemon.


-- 
Florian Weimer / Red Hat Product Security