Bug#552255: linux-image-2.6.26-2-686: /proc permission bypass
We have been having a back and fourth on this with a couple of people.
It has not shown up on BUGTRAQ yet because it is sitting in the
moderator queue.
First of all, any permission bypass is bad. Principle of least surprise.
Second, the important thing here is that directory permissions are
ignored. Whatever the reason, that is not good. The case shown by Pavel
is an extreme example (using 666), but you can most likely have a less
extreme example where this can be put to "good" use.
Third, there is a non-zero size class of applications where it is likely
such idiocy like 666 protected one level above by dir to be found -
ported from Windows. Under windows, locking is non-advisory and apps
tend to scribble "under themselves". So if you open a file with an
exclusive Read/write lock nobody can read/write it regardless of
permissions. When a program gets ported to unix developers (or the
porting toolkit) replaces the code with flocks or fcntl which are
advisory and the file becomes nicely accessible. No such code in debian
proper, but that does not mean that there is no such code out there in
the wild.
Fourth, during the discussion it was claimed that this does not work on
Linux proper. I have some doubts about the claim, but cannot verify it
(I am off on holiday in an hour or so). It maybe Debian specific or
specific to a patch which Debian and more than one other distro is using
(ptrace comes to mind). I personally do not think that is the case,
however it is worth checking and if it is coming from the ptrace patches
double check if they do not introduce something worse than that
somewhere.
Cheers,
On Sat, 2009-10-24 at 21:18 +0100, Ben Hutchings wrote:
> On Sat, 2009-10-24 at 20:19 +0100, Anton Ivanov wrote:
> > Package: linux-image-2.6.26-2-686
> > Version: 2.6.26-17
> > Severity: important
> >
> >
> > Currently discussed on bugtraq
> >
> > Cut-n-pasting the email
> >
> > Hi!
> >
> > This is forward from lkml, so no, I did not invent this
> > hole. Unfortunately, I do not think lkml sees this as a security hole,
> > so...
> >
> > Jamie Lokier said:
> > > > > a) the current permission model under /proc/PID/fd has a security
> > > > > hole (which Jamie is worried about)
> > > >
> > > > I believe its bugtraq time. Being able to reopen file with additional
> > > > permissions looks like a security problem...
> > > >
> > > > Jamie, do you have some test script? And do you want your 15 minutes
> > > > of bugtraq fame? ;-).
> >
> > > The reopen does check the inode permission, but it does not require
> > > you have any reachable path to the file. Someone _might_ use that as
> > > a traditional unix security mechanism, but if so it's probably quite rare.
> >
> > Ok, I got this, with two users. I guess it is real (but obscure)
> > security hole.
>
> So obscure that it doesn't really count as important.
>
> > So, we have this scenario. pavel/root is not doing anything interesting in
> > the background.
> >
> > pavel@toy:/tmp$ uname -a
> > Linux toy.ucw.cz 2.6.32-rc3 #21 Mon Oct 19 07:32:02 CEST 2009 armv5tel GNU/Linux
> > pavel@toy:/tmp mkdir my_priv; cd my_priv
> > pavel@toy:/tmp/my_priv$ echo this file should never be writable > unwritable_file
> > # lock down directory
> > pavel@toy:/tmp/my_priv$ chmod 700 .
> > # relax file permissions, directory is private, so this is safe
> > # check link count on unwritable_file. We would not want someone
> > # to have a hard link to work around our permissions, would we?
> > pavel@toy:/tmp/my_priv$ chmod 666 unwritable_file
> [...]
>
> But who's really going to do that, other that to demonstrate this?
>
> Ben.
>
--
Understanding is a three-edged sword:
your side, their side, and the truth. --Kosh Naranek
A. R. Ivanov
E-mail: aivanov@sigsegv.cx
WWW: http://www.sigsegv.cx/
pub 1024D/DDE5E715 2002-03-03 Anton R. Ivanov <arivanov@sigsegv.cx>
Fingerprint: C824 CBD7 EE4B D7F8 5331 89D5 FCDA 572E DDE5 E715
Reply to: