[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20150423182441.GB16300@pc.thejh.net>
Date: Thu, 23 Apr 2015 20:24:41 +0200
From: Jann Horn <jann@...jh.net>
To: oss-security@...ts.openwall.com
Subject: Re: open(2) with side effects
On Thu, Apr 23, 2015 at 03:08:43PM +0200, Florian Weimer wrote:
> How common are file names on Linux which, when just opened and closed
> (maybe with fstat or fgetattr inbetween), trigger side effects, such as
> tape rewind?
>
> Do we still have to guard against that? Or is that a thing of the past?
Well, opening anything creates an inotify event that can be observed by
anyone with read access to the thing. So if I can make you open a symlink
to "/root/.ssh/../../tmp/foobar" with root privileges, I can observe
whether an IN_OPEN event happens on /tmp/foobar and deduce from that
whether a folder /root/.ssh exists. As far as I know, there is no way to
prevent that notification. So the fix is to never follow symlinks, or in
other words, never use paths including slashes in syscalls that take a
path and only open directories using "open(..., O_NOFOLLOW);fchdir(...)",
I guess. (You can do the same attack by polling st_atime instead of using
inotify, but that might not work depending on the mount options and
whether O_NOATIME was used.)
> At least before containers, the risk is greatly reduced because /dev is
> a separate file system these days, so you can only use symbolic links,
As you said, containers complicate finding out where you are a bit, even
if you're not inside one - see the recently updated getcwd(3) manpage
(<http://man7.org/linux/man-pages/man2/getcwd.2.html>):
If the current directory is not below the root directory of the
current process (e.g., because the process set a new filesystem root
using chroot(2) without changing its current directory into the new
root), then, since Linux 2.6.36, the returned path will be prefixed
with the string "(unreachable)". Such behavior can also be caused by
an unprivileged user by changing the current directory into another
mount namespace. When dealing with paths from untrusted sources,
callers of these functions should consider checking whether the
returned path starts with '/' or '(' to avoid misinterpreting an
unreachable path as a relative path.
But yeah, that also only applies if you follow symlinks somehow.
> and those are more straightforward to deal with (hard links need O_PATH
> for a race- and side-effect-free link count check).
You can do a race-free link count check? How does that work? As far as I
know, an attacker could always just remove the dentry through which
you're accessing the inode before the fstat() and put it back in place
after fstat().
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
