Next Page >>
hard/linked
standards (a function called llink). Today's fix for Solaris, Linux
etc. also makes Postfix future-proof for such changes.
Wietse
1. Postfix local privilege escalation via hardlinked symlinks
=============================================================
Sebastian Krahmer of SuSE has found a privilege escalation problem.
On some systems an attacker can hardlink a root-owned symlink to
for example /var/mail, and cause Postfix to append mail to existing
files that are owned by root or non-root accounts. This can happen
>
> || User1 creates file with permissions 0644
> || User2 opens file for read access on file descriptor 4
> || User1 chmod's directory to 0700
> || User1 chmod's file to 0666
> || User1 verifies no hard links to file
> || User2 can not open the file for read or write access
> || User2 can not write to file descriptor 4
> || User2 _can_ write to /proc/$$/fd/4
> ||
> || Now user2 is expected to be able to have read-access to the file via
> >under traditional unix, and you can not write into that file when
> >/proc is unmounted.
> >
> >I do not think mounting /proc should change access control semantics.
> >
> It didn't in fact change anything. If the guest created hardlink to
> that file in a unrestricted location, what would you say? Procfs is
> in that respect just another sort of hardlinks, whether you like
> that or not. If you didn't in fact restrict an access to the file,
> you're on your own.
Dan Yefimov said:
>> I do not think mounting /proc should change access control semantics.
>>
>It didn't in fact change anything. If the guest created hardlink to that file in
>a unrestricted location, what would you say? Procfs is in that respect just
>another sort of hardlinks, whether you like that or not. If you didn't in fact
>restrict an access to the file, you're on your own.
(1) This is WRONG, and I find it interesting that nobody bothered to check
|| User1 creates file with permissions 0644
|| User2 opens file for read access on file descriptor 4
|| User1 chmod's directory to 0700
|| User1 chmod's file to 0666
|| User1 verifies no hard links to file
|| User2 can not open the file for read or write access
|| User2 can not write to file descriptor 4
|| User2 _can_ write to /proc/$$/fd/4
||
|| Now user2 is expected to be able to have read-access to the file via
>>>> check the link count, *then* chmod the file to 0666:
>>>>
>>>> User1 creates file with permissions 0644
>>>> User2 opens file for read access on file descriptor 4
>>>> User1 chmod's directory to 0700
>>>> User1 verifies no hard links to file
>>>
>>> Here's a window, during which User2 is able to create a hardlink and
>>> that will remain unnoticed by User1. There's no way to perform link
>>> check and conditionally do chmod in an atomic manner.
>>
> Now... go back to my original email:
>
> %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
>
> Yes, you are right, open file descriptor acts as a kind of hardlink
> here. Except that
>
You wrote:
>> User1 creates file with permissions 0644
>> User2 opens file for read access on file descriptor 4
>> User1 chmod's directory to 0700
>> User1 verifies no hard links to file
>
> Here's a window, during which User2 is able to create a hardlink and that will
> remain unnoticed by User1. There's no way to perform link check and
> conditionally do chmod in an atomic manner.
Sebastian Krahmer of SuSE has found that Postfix allows to deliver mail
to root-owned symlinks in an insecure manner under certain conditions.
Normally, Postfix does not deliver mail to symlinks, except to
root-owned symlinks, for compatibility with the systems using symlinks
in /dev like Solaris. Furthermore, some systems like Linux allow to
hardlink a symlink, while the POSIX.1-2001 standard requires that the
symlink is followed. Depending on the write permissions and the
delivery agent being used, this can lead to an arbitrary local file
overwriting vulnerability (CVE-2008-2936). Furthermore, the Postfix
delivery agent does not properly verify the ownership of a mailbox
before delivering mail (CVE-2008-2937).
>
> >> I do not think mounting /proc should change access control
> semantics.
> >>
> >It didn't in fact change anything. If the guest created
> hardlink to that file in a unrestricted location, what would you say?
>
> Do your homework and test it. You can't create the hardlink -
> the link(oldpath, newpath) call will fail with EACCES if
> search permission is denied for any directory in oldpath or
> newpath. Documented in the manpage, and I just tested and verified it.
On 26.10.2009 23:05, Isara Beaumont wrote:
> Dan Yefimov said:
>
>>> I do not think mounting /proc should change access control semantics.
>>>
>> It didn't in fact change anything. If the guest created hardlink to that file in
>> a unrestricted location, what would you say? Procfs is in that respect just
>> another sort of hardlinks, whether you like that or not. If you didn't in fact
>> restrict an access to the file, you're on your own.
>
> (1) This is WRONG, and I find it interesting that nobody bothered to check
> >check the link count, *then* chmod the file to 0666:
> >
> > User1 creates file with permissions 0644
> > User2 opens file for read access on file descriptor 4
> > User1 chmod's directory to 0700
> > User1 verifies no hard links to file
>
> Here's a window, during which User2 is able to create a hardlink and
> that will remain unnoticed by User1. There's no way to perform link
> check and conditionally do chmod in an atomic manner.
>>> check the link count, *then* chmod the file to 0666:
>>>
>>> User1 creates file with permissions 0644
>>> User2 opens file for read access on file descriptor 4
>>> User1 chmod's directory to 0700
>>> User1 verifies no hard links to file
>>
>> Here's a window, during which User2 is able to create a hardlink and
>> that will remain unnoticed by User1. There's no way to perform link
>> check and conditionally do chmod in an atomic manner.
>
On Wed, Oct 28, 2009 at 10:30:37PM +0100, Pavel Machek wrote:
> On Tue 2009-10-27 11:49:32, CaT wrote:
> > On Tue, Oct 27, 2009 at 12:29:09AM +0300, Dan Yefimov wrote:
> > > and testing them. Remember the scenario from the original mail and try
> > > finding a window, during which creating a hardlink would still work thus
> > > evading directory permissions check.
> >
> > The main thing this does is allow a hardlink-like attack to work across
> > mountpoints afaics.
>
|| >check the link count, *then* chmod the file to 0666:
|| >
|| > User1 creates file with permissions 0644
|| > User2 opens file for read access on file descriptor 4
|| > User1 chmod's directory to 0700
|| > User1 verifies no hard links to file
||
|| Here's a window, during which User2 is able to create a hardlink
|| and that will remain unnoticed by User1. There's no way to perform
|| link check and conditionally do chmod in an atomic manner.
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.
On 26.10.2009 18:14, nomail@nomail.com wrote:
>>> I do not think mounting /proc should change access control semantics.
>>>
>> It didn't in fact change anything. If the guest created hardlink to that file in
>> a unrestricted location, what would you say?
>
> Do your homework and test it. You can't create the hardlink - the link(oldpath,
> newpath) call will fail with EACCES if search permission is denied for any
> directory in oldpath or newpath. Documented in the manpage, and I just tested
> and verified it.
On Sat, Oct 24, 2009 at 02:31:47AM +0400, Dan Yefimov wrote:
> On 24.10.2009 1:56, Pavel Machek wrote:
> >a) this kind of hardlink does not exist when /proc is mounted (and on
> >non-Linux)
> >(and c) writing to file descriptor opened read-only is bad).
> Did you think of creating a hardlink to the file in an unrestricted
> location?
On Tue 2009-10-27 11:49:32, CaT wrote:
> On Tue, Oct 27, 2009 at 12:29:09AM +0300, Dan Yefimov wrote:
> > and testing them. Remember the scenario from the original mail and try
> > finding a window, during which creating a hardlink would still work thus
> > evading directory permissions check.
>
> The main thing this does is allow a hardlink-like attack to work across
> mountpoints afaics.
Yes, plus it allows "hardlinks" on deleted files, and this "strange
------------------------------------------------------------------------
The PulseAudio binary is affected by a local race condition. If the
binary is installed as SUID root, it is possible to exploit this
vulnerability to gain root privileges. This attack requires that a local
attacker can create hard links on the same hard disk partition on which
PulseAudio is installed (i.e. /usr/bin and /tmp reside on the same
partition).
------------------------------------------------------------------------
See also
>>> subtle but I believe I got it right, and file would not be writable
>>> with /proc unmounted.
>>>
>> I remember the original mail content. You're right, you can't reach
>> the file if the procfs is not mounted, but you forget about the
>> race, allowing the guest to create a hardlink to the file in an
>> unrestricted location before the directory access becomes
>> restricted. Again, procfs is just another, specific kind of
>> hardlinks.
>
> Check it again. There's no race; I check link count before chmod 666.
> >>>Dear Dan,
> >>>
> >>>>... in authentic kernels /proc/<PID>/fd/<FD> are symlinks ...
> >>>
> >>>They appear to /bin/ls as symlinks, but observation suggests that they
> >>>"act" as hardlinks. Could that be fixed somehow? (I did look at the
> >>>kernel fs/proc/base.c but did not make much sense to me...)
> >>>
> >>Just looked more carefully at fs/proc/base.c. That behavior is due
> >>to proc_fd_info() called from proc_fd_link() obtains file->f_path,
> >>that in turn contains the reference to the open file dentry and
> >Dear Dan,
> >
> >>... in authentic kernels /proc/<PID>/fd/<FD> are symlinks ...
> >
> >They appear to /bin/ls as symlinks, but observation suggests that they
> >"act" as hardlinks. Could that be fixed somehow? (I did look at the
> >kernel fs/proc/base.c but did not make much sense to me...)
> >
> Just looked more carefully at fs/proc/base.c. That behavior is due
> to proc_fd_info() called from proc_fd_link() obtains file->f_path,
> that in turn contains the reference to the open file dentry and
>>> Dear Dan,
>>>
>>>> ... in authentic kernels /proc/<PID>/fd/<FD> are symlinks ...
>>>
>>> They appear to /bin/ls as symlinks, but observation suggests that they
>>> "act" as hardlinks. Could that be fixed somehow? (I did look at the
>>> kernel fs/proc/base.c but did not make much sense to me...)
>>>
>> Just looked more carefully at fs/proc/base.c. That behavior is due
>> to proc_fd_info() called from proc_fd_link() obtains file->f_path,
>> that in turn contains the reference to the open file dentry and
> Dear Dan,
>
>> ... in authentic kernels /proc/<PID>/fd/<FD> are symlinks ...
>
> They appear to /bin/ls as symlinks, but observation suggests that they
> "act" as hardlinks. Could that be fixed somehow? (I did look at the
> kernel fs/proc/base.c but did not make much sense to me...)
>
Just looked more carefully at fs/proc/base.c. That behavior is due to
proc_fd_info() called from proc_fd_link() obtains file->f_path, that in turn
contains the reference to the open file dentry and hence inode. That's exactly
Gabor Gombas wrote:
>
> On Mon, Nov 02, 2009 at 08:53:26PM +0100, Pavel Machek wrote:
>
> > > The link count of a files tells you the number of hard links that
> > > are persisted within the same filesystem. It is _NOT_ a promise
> > > that there are no other means to access the inode of the file.
> >
> > It used to be promise before /proc was mounted.
On Tue, Oct 27, 2009 at 12:29:09AM +0300, Dan Yefimov wrote:
> and testing them. Remember the scenario from the original mail and try
> finding a window, during which creating a hardlink would still work thus
> evading directory permissions check.
The main thing this does is allow a hardlink-like attack to work across
mountpoints afaics.
Instead of making hardlink you run something that keeps an fd open to the
file.
> subtle but I believe I got it right, and file would not be writable
> with /proc unmounted.
>
I remember the original mail content. You're right, you can't reach the file if
the procfs is not mounted, but you forget about the race, allowing the guest to
create a hardlink to the file in an unrestricted location before the directory
access becomes restricted. Again, procfs is just another, specific kind of
hardlinks.
--
Sincerely Your, Dan.
On Tue, Nov 03, 2009 at 12:33:28AM +0100, Martin Rex wrote:
> > "mount --bind" behaves like a hard link and it does not increment the link
> > count.
>
> that seems to work similar to a hardlink on a directory (and also requires
> root privileges). It doesn't work for the same directory level, because
> of this (the directory permissions of the mounted directories and
> directories below it remain effective -- the permissions of directories
> above disappear, however!
>> I do not think mounting /proc should change access control semantics.
>>
>It didn't in fact change anything. If the guest created hardlink to that file in a unrestricted location, what would you say?
Do your homework and test it. You can't create the hardlink - the link(oldpath, newpath) call will fail with EACCES if search permission is denied for any directory in oldpath or newpath. Documented in the manpage, and I just tested and verified it.
Fact is, directory permissions are relevant in Unix. Despite it's permissions, under the Unix access permission semantics the file is unwriteable for anyone but the owner, and this bug pokes a hole into that.
Next Page>>
|
