Message-ID: <20091024064617.GC9883@dragontoe.org>
Date: Sat, 24 Oct 2009 01:46:17 -0500
From: Derek Martin <code@...zashack.org>
To: bugtraq@...urityfocus.com
Subject: Re: /proc filesystem allows bypassing directory permissions on
 Linux

On Fri, Oct 23, 2009 at 11:57:58PM +0400, Dan Yefimov wrote:
> That can hardly be called a real security hole, since the behaviour
> described above is expected, and is as it was conceived by design.

Lots of security holes can fall into that category!  The code matches
its design, and works as expected... it's just that the author had no
idea what he was getting himself into.  =8^)  

> If the file owner in fact allows writing to it, why should Linux
> prevent that from happening?

Because securing a file by securing directories that lead to it is a
valid and important (and expected) feature of file access semantics.

That said, the user in the example already has access to the file (in
a running process), and would be able to do so again, *if he had
access to a directory where the file was hard-linked*.  Pavel
described that the sysadmin checked for that, but even if this worked
as expected, there's a race condition where the user could create the
hard link after the sysadmin checked, but before the permissions were
corrected.  Unlikely, I know... but possible.

There's a nearly identical case that works in all Unixen, AFAIK:  You
have /a/b/file1, which is writable to user1.  The user has permission
to descend /a and /a/b.  At some point user1 does a cd to /a/b.  Then
at some later point, while the user still has that shell open, the
sysadmin closes off permission to /a, and user1 no longer can descend
it.  But it doesn't matter... user1 has already got a shell open in
/a/b, and therefore full access to all the files there which are not
otherwise protected against that user's access.  user1 can copy them,
mail them to friends, make hard links to them, etc....  Anything
desired, until that shell is closed.  This case won't work if you
close off /a/b, because you need to be able to modify the directory in
order to write to the file (I'm getting to that)...

I don't think what Pavel described is a very serious hole, but it *IS*
a hole, because:

1. It circumvents the fact that to write to a file, you MUST be able
to write to its directory, so that the file attributes can be updated.
That's an important part of accountability.

2. One of two things must be true: either the real directory itself is
not updated when the file is written (likely), or the directory IS
modified when the file is written, despite the fact that the user does
not have access to update the directory.  Either way, BAD LINUX.

I think there is one other legitimate answer to your question above:
If the person who created/accessed the file is an unauthorized user,
and the person who closed off directory access was responding to the
intrusion.  This includes a user who is authorized to use the system,
but has gained access to some part of the system that should not be
accessible, either by accident or by willful misdeed.  Of course,
there are likely other, better ways to respond than to simply close
off the directory permissions... but someone who is not expert in this
aspect of the behavior of the Linux kernel has every reason to think
that doing that would work. It's not documented anywhere a typical
sysadmin is likely to look that this method of filesystem permission
circumvention exists.

The most disturbing aspect of this is that the user went from having
read access, which was allowed, to getting write access, which should
never have been allowed.  It wasn't allowed with the old permissions,
and if the directory permissions had not been circumvented, it
wouldn't have been allowed with the new permissions.

I still think it's not very serious, because in order to exploit this,
you need:

 - The people responsible for managing access to sensitive data to
   mishandle the initial protections on the file(s)
 - Those same people to later protect the so-called sensitive file in
   a way that doesn't really make a whole lot of sense
 - A process that already has an affected file open before the bizarre
   change in protections
 - The sysadmins to fail to notice people are accessing the files they
   just protected.  You'd think if they just realized they had left
   permissions too open (and the data really was sensitive), they'd be
   paying attention...

That's a lot of crazy. =8^)  If your data really *is* sensitive, and
this happens, you probably need to fire your sysadmin.  Probably it
should still be fixed though.  I'm not sure what the point of making
the files accessible via /proc is...  It's good that open files are
*recorded* there, but making the contents accessible from there seems
unnecessary (and bad) to me, at least unless said access first
determines the canonical file system path to the file (i.e. the one
that the process used to open it), and checks the file access as it
would normally, using that path.  Still, I doubt I'll ever see this on
any system I manage.
 
If it were possible for a different user who wasn't already accessing
the file to get access this way, that would be a very different
matter...

-- 
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D


Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists