Next Page >>
hardlink
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
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
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
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.
>
> >> 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.
> 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
>
> >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.
>>>> 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.
>>
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).
>
> || 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
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!
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.
|| >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 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?
>> 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.
------------------------------------------------------------------------
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
>>> 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.
>
> 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.
|| 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
Problem Description:
Raphael Marichez discovered a denial of service bug in how vixie-cron
verifies crontab file integrity. A local user with the ability
to create a hardlink to /etc/crontab could prevent vixie-cron from
executing certain system cron jobs.
The updated packages have been patched to correct this issue.
_______________________________________________________________________
Cron is a standard UNIX daemon that runs specified programs at
scheduled times.
A denial of service issue was found in the way vixie-cron verified
crontab file integrity. A local user with the ability to create a
hardlink to /etc/crontab could potentially prevent vixie-cron from
executing certain system cron jobs. (CVE-2007-1856)
Thanks to Raphael Marichez for identifying this issue.
ESX
>>> 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.
> >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.
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.
>
> 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.
> Plus, you may run traditional unix/POSIX application, expecting
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.
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
A vulnerability has been found and corrected in rpm:
lib/fsm.c in RPM 4.8.0 and unspecified 4.7.x and 4.6.x versions, and
RPM before 4.4.3, does not properly reset the metadata of an executable
file during replacement of the file in an RPM package upgrade, which
might allow local users to gain privileges by creating a hard link
to a vulnerable (1) setuid or (2) setgid file (CVE-2010-2059).
The updated packages have been patched to correct this issue.
_______________________________________________________________________
Next Page>>
|
