Re: [security] Race condition in udev

[Scott James Remnant <scott@canonical.com>]

[-- Attachment #1: Type: text/plain, Size: 3037 bytes --]

On Tue, 2009-08-25 at 19:31 +0200, Florian Zumbiehl wrote:

> actually, I even explained _how_ this could lead to temporarily wider
> permissions than configured, but let's trace through an example for
> Mr. POSIX:
> 
> Assumption:
> 
>  /dev/foo is configured to be owned by user root, group users, mode 0646.
>  The attacker tries to open /dev/foo for writing as a user that's not
>  root, not a member of the group root, but a member of the group users.
> 
> The Trace:
> 
>   action                     | owner | group | mode    | open(O_WRONLY)?
>  ----------------------------+-------+-------+---------+-----------------
>   mknod(/dev/foo)            | root  | root  | 0644(?) | no
>   chmod(/dev/foo,0646)       | root  | root  | 0646    | yes
>   chown(/dev/foo,root,users) | root  | users | 0646    | no
> 
> Could we now take care of the bug?
> 
Sure, let's invert the chmod() and chown()...

BUT WAIT!

Assumption:

 /dev/foo is configured to be owned by user mrposix, mode 0466.  The
 attacker (mrposix) tries to open /dev/foo for writing.

The Trace:

  action                        | owner   | mode    | open(O_WRONLY)?
  ------------------------------+---------+---------+-----------------
  mknod(/dev/foo)               | root    | 0644    | no
  chown(/dev/foo,mrposix,users) | mrposix | 0644    | yes
  chmod(/dev/foo,0466)          | mrposix | 0466    | no


In other words, exactly the same race.

Since we don't have a chownmod syscall, we have to do this
non-atomically, which means that either there's a race for denying
access for particular users or a race for denying access for particular
groups.


Now, let's put aside for a moment the fact that either of these modes is
insane.  Which of the two attempts to deny access _should_ work?

The surprising answer is that the attempt to deny access to the *user*
is the one that should work (ie. don't change the code), not the attempt
to deny access to a group.


There's a simple reason for this.

A user's uid is fixed, and is a key fact of that user's privilege.  The
only way for "mrposix" to change users is if he was really root in the
first place, or has access to a setuid program.

A user's gid *is not* fixed, in fact, a user may be a member of any one
or more groups at their own choice.  An entry in /etc/passwd
or /etc/groups does not *force* the user into those groups, it simply
grants the user *access* to be a member of those groups.

There are tried, tested and (most importantly) *permitted* methods for a
user to shed group membership.  Since a user can shed their group
membership in this way, they can work around your attempt to restrict
access, and thus grant themselves write access after all.


(This is, in fact, why it's "insane" to deny access using modes; a user
 can always find a way to become *less* privileged, and thus if you're
 trying to deny them access to things, actually gain privilege)

Scott
-- 
Scott James Remnant
scott@canonical.com

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]