[9fans] p9any auth in u9fs: uid value in ticked is ignored

[9fans] p9any auth in u9fs: uid value in ticked is ignored

[Yaroslav]

There is a security problem with p9auth in u9fs: it uses uname from
Tauth/Tattach as user's identity - ignoring the user id which has been
authenticated to the auth server.  As uname is always set to up->user
in devmnt, this means that:

a) a user cann't have a different name on the u9fs machine; and, more
serious,

b) a user can easily masquerade as another user to u9fs by simply
booting his terminal under that user while using own credentials for
optaining the ticket.

A proposed fix has been submitted as /n/sources/patch/u9fs-p9sk1:

/n/dump/2011/1010/sys/src/cmd/unix/u9fs/authp9any.c:369,375 -
/sys/src/cmd/unix/u9fs/authp9any.c:369,378
  		fprint(2, "p9anyattach: afid %d state %d\n", rx->afid, sp->state);
  	if (sp->state == Established && strcmp(rx->uname, sp->uname) == 0
  		&& strcmp(rx->aname, sp->aname) == 0)
+ 	{
+ 		rx->uname = sp->t.suid;
  		return nil;
+ 	}
  	return "authentication failed";
  }

Whether to use t.suid or t.cuid as the target uid remains an open
question: authsrv(6) says t.suid represents target uid; the real use,
howerver, is not that clear: cwfs for 9p2k uses t.suid; while fossil,
exportfs, cpu -R and cwfs for old9p check against t.cuid.  Comments in
/sys/include/authsrv.h:58,76 appear somewhat opaque until authsrv(6)
and p9sk1 client/server code in factotum are carefully studied.

- Yaroslav

─────
Related matter:
/sys/src/9/port/devmnt.c:281
/sys/src/9/port/devmnt.c:347
/sys/src/cmd/auth/factotum/p9sk1.c:170,171
/sys/src/cmd/auth/factotum/rpc.c:341
/sys/src/libauth/auth_chuid.c:37
/sys/src/cmd/unix/u9fs/authp9any.c:370
/sys/src/cmd/unix/u9fs/u9fs.c:417,420
/sys/src/cmd/cpu.c:665
/sys/src/cmd/fossil/9auth.c:30,38
/sys/src/cmd/fossil/9auth.c:132,151
/sys/src/cmd/fossil/9auth.c:155
/sys/src/cmd/fossil/9p.c:999,1007
/sys/src/cmd/cwfs/9p1.c:134,138
/sys/src/cmd/cwfs/9p2.c:252,262
/sys/src/cmd/cwfs/auth.c:313
/sys/src/cmd/cwfs/auth.c:291
/sys/src/cmd/exportfs/exportfs.c:189,192

Re: [9fans] p9any auth in u9fs: uid value in ticked is ignored

[Charles Forsyth]

It's true that the server must take account of the result of
authentication, but although that might not
mean identity, the results of authentication should be consistent with
the name presented as uname
in Tauth/Tattach. In the context of p9auth I think that means that the
cuid of AuthInfo should match.
That doesn't preclude the server from having a more subtle acquisition
of authority, for instance by
having an auth file that's kept open, allowing incremental
authentication using another protocol.

On 10 October 2011 13:07, Yaroslav <yarikos@gmail.com> wrote:
> There is a security problem with p9auth in u9fs: it uses uname from
> Tauth/Tattach as user's identity - ignoring the user id which has been
> authenticated to the auth server.  As uname is always set to up->user
> in devmnt, this means that:
>

Re: [9fans] p9any auth in u9fs: uid value in ticked is ignored

[Yaroslav]

devmnt always uses up->user for Tauth/Tattach no matter what an auth
protocol would yield (/sys/src/9/port/devmnt.c:281). Stock 9P servers
tolerate this and check Tattach.uname to match Tauth.uname but use
t.cuid or t.suid as the true user identity (unless no auth required).

Anyway, simply trusting Tattach.uname is too naïve - at least for p9any.

> It's true that the server must take account of the result of
> authentication, but although that might not
> mean identity, the results of authentication should be consistent with
> the name presented as uname
> in Tauth/Tattach. In the context of p9auth I think that means that the
> cuid of AuthInfo should match.

Re: [9fans] p9any auth in u9fs: uid value in ticked is ignored

[Charles Forsyth]

Indeed the whole point of Tauth is that the uname in Tattach isn't intended to
be trusted on its own, unless supported by an afid that attests to a previous
authentication of the uname. (An exception is that many servers only
run as the invoking user
and don't insist on authentication.) That's the documented protocol.

It seems that the servers you mention substitute t.cuid at the attach,
but that makes uname relatively pointless: it might just as well not
be provided in Tauth since it's effectively ignored. It would be
needed in Tattach in case there is no Tauth,
but is also effectively ignored in Tattach if there were a Tauth. (In that case,
who cares if the two strings are the same if they are irrelevant?
What's the point of the server checking?)
That isn't the documented protocol.

I'm ignoring the devmnt aspect because that's outside the protocol as such.
I'm interested in what servers ought to be doing (or perhaps whether
the protocol should be change).

Re: [9fans] p9any auth in u9fs: uid value in ticked is ignored

[Yaroslav]

Uname in Tauth/Tattach indeed seem to be irrelevant for p9any but as
it is external to 9P this may be a provision for other possible auth
schemes where the uname may be the only place to provide an indentity
being authenticated...

Re: [9fans] p9any auth in u9fs: uid value in ticked is ignored

[Charles Forsyth]

You could just define it in the first write to the auth file. In any
case, there wouldn't
be any need for the names in Tauth and Tattach to match, because the
server would
always use the result of the authentication.

I imagine the intention was that in Tauth, uname defined the user to
authenticate within
the space defined by the given aname (if relevant), and only that
uname (in that aname context)
would be authenticated; consequently it was reasonable to use the
resulting afid to authenticate
one or more matching Tattach requests. Thus the (uname, aname) on
Tauth should really be
constraining the initial state for authentication on the auth file
(ie, on success, it's taken to have
authenticated that uname). For instance, in the p9any case in
role=server, it should also be given user=uname,
and with p9sk1, only uname would be acceptable as {uid sub C}. Then
all the IDs involved would match.
(That doesn't preclude some sort of user name mapping, as is already
done for instance by fossil,
or a map of the name to an internal user ID as done by kfs.)

Note that on a shared server, with several unames actively accessing a
shared file server connection,
the users are trusting the server not to cheat with fids (ie, allow
one user to attach a fid,
however that's done, and then make that fid usable by another user by
accident, or to a miscreant by design).

On 10 October 2011 21:47, Yaroslav <yarikos@gmail.com> wrote:
> Uname in Tauth/Tattach indeed seem to be irrelevant for p9any but as
> it is external to 9P this may be a provision for other possible auth
> schemes where the uname may be the only place to provide an indentity
> being authenticated...
>
>