[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#508867: stale nfs filehandle

On Wed, 2009-03-04 at 11:32 +1100, Tim Connors wrote:
> severity grave
> tags 508867 security
> thanks
> As a test, I commented out the access() calls in AuGetAddr.c that are
> commented as saying "checks REAL id", and this bug disappears.  But now
> that I know the purpose of the access() call, I presume this is because
> suid programs like xterm link against libxau6, and thus need to check the
> access permissions of $XAUTHORITY using the real uid/gid rather than the
> effective uid/gid.
> Unfortunately, as per access(2):
>        Warning: Using access() to check if a user is authorized to, for
>        example, open a file before actually doing so using open(2)
>        creates a security hole, because the user might exploit the
>        short time interval between checking and opening the file to
>        manipulate it.  For this reason, the use of this system call
>        should be avoided.
> So, it looks like to my untrained eye that one could set
> XAUTHORITY=/tmp/hack/wtmp, where /tmp/hack is a symlink to a directory
> called /tmp/hack.1, on the same filesystem as /var/log.  Then get libxau6
> to read the contents of /tmp/hack/wtmp, then racily change the symlink of
> /tmp/hack to point to /var/log before libxau6 writes the new $XAUTHORITY
> back out to disk, and voila, corrupt the contents of /var/log/wtmp or any
> other file of gid of /usr/bin/xterm.
> Would it be better to temporarily drop priveleges and just do an open()
> instead which will also have the side benefit of closing this bug and the
> alleged security bug above?  As it stands, the access() presumably isn't
> adding much security as per above, so should be removed altogether, also
> closing this bug (just leaving the security bug that exists anyway, but
> /var/log/wtmp is not that critical anyway).

If there's a bug here, I don't think it warrants 'grave' severity.  Also
the initial bug is being fixed in the kernel in 2.6.29 (#508866), so
this one should probably be retitled.


Reply to: