Agent Authentication Question

[Colin Walters]

Hi Tavis,

(By the way, thanks for all of your work in security research)

On Fri, May 29, 2015, at 02:00 PM, Tavis Ormandy wrote:
> Hello, I've been browsing the reference code and have a question about
> how the session cookies are maintained. It looks like the cookie
> generator can wrap and two identical cookies could exist
> simultaneously in the active sessions list.

...

> My question is, what are the implications of that? Is it a security
> vulnerability?
 
I'll be honest, I inherited maintenance of this code, it's only a < 2%
time job for me currently.  So take what I say below with that in mind.

I spent some time analyzing this.  One of the things that took
me a bit of time to appreciate is that AuthenticationAgentResponse
is a privileged (uid 0) operation.  Unprivileged code in session
agents only are able to invoke it by calling polkit's own setuid helper
binary for this.

The caller gets to choose the username and cookie, but the
call only can be made if the caller can PAM authenticate as the
username.

With those facts in mind, let's examine the scenario where we 
have multiple logged in users, call them Alice and Mallory.

= Causing authentication to spuriously succeed/fail? =
My initial worry here was that Mallory could cause authentication
requests inside Alice's session to succeed or fail, by guessing the cookie.

However, because the caller of the DBus API must have authenticated
as the target identity, in the most common cases of auth-as-self
or auth-as-root, Mallory would have to know either Alice's password
or the root password.  (Really s/password/PAM/ but the point stands)

I think we can say this situation is not a vulernability - if Mallory has
either of those things, they're either equivalent to Alice, or they're
root.

= The duplicate cookie scenario =

So what happens if the current cookie wraps, and we end up with
multiple, where we have one AuthenticationSession for Alice,
and one AuthenticationSession for Mallory?

I think here if Mallory happens to be first in the hash table
order, could cause Alice's AuthenticationResponses to
fail.

This would then be a local, authenticated denial of service
against other users.

Concretely for example, Mallory could cause Alice's attempts
to start virt-manager to fail. 

Does that sound right?

I'll work on a patch.