hard links create local DoS vulnerability and security problems

hard links create local DoS vulnerability and security problems

[Jakob Lell]

Hello,
on Linux it is possible for any user to create a hard link to a file belonging 
to another user. This hard link continues to exist even if the original file 
is removed by the owner. However, as the link still belongs to the original 
owner, it is still counted to his quota. If a malicious user creates hard 
links for every temp file created by another user, this can make the victim 
run out of quota (or even fill up the hard disk). This makes a local DoS 
attack possible.

Furthermore, users can even create links to a setuid binary. If there is a 
security whole like a buffer overflow in any setuid binary, a cracker can 
create a hard link to this file in his home directory. This link still exists 
when the administrator has fixed the security whole by removing or replacing 
the insecure program. This makes it possible for a cracker to keep a security 
whole open until an exploit is available. It is even possible to create links 
to every setuid program on the system. This doesn't create new security 
wholes but makes it more likely that they are exploited.

To solve the problem, the kernel shouldn't allow users to create hard links to 
files belonging to someone else.

I could reproduce the problem on linux 2.2.19 and 2.4.21 (and found nothing 
about it in the changelogs to 2.4.23-rc3).

Regards
 Jakob

Re: hard links create local DoS vulnerability and security problems

[Måns Rullgård]

Jakob Lell <jlell@JakobLell.de> writes:

> on Linux it is possible for any user to create a hard link to a file
> belonging to another user. This hard link continues to exist even if
> the original file is removed by the owner. However, as the link
> still belongs to the original owner, it is still counted to his
> quota. If a malicious user creates hard links for every temp file
> created by another user, this can make the victim run out of quota
> (or even fill up the hard disk). This makes a local DoS attack
> possible.

This only make for a DoS attack if the there are user-writable
directories on a filesystem that the system depends on being writable.

> Furthermore, users can even create links to a setuid binary. If
> there is a security whole like a buffer overflow in any setuid
> binary, a cracker can create a hard link to this file in his home
> directory. This link still exists when the administrator has fixed
> the security whole by removing or replacing the insecure
> program. This makes it possible for a cracker to keep a security
> whole open until an exploit is available. It is even possible to
> create links to every setuid program on the system. This doesn't
> create new security holes but makes it more likely that they are
> exploited.

If any SUID user writable directories (/tmp, /var/various, /home) are
kept on separate partitions from any SUID executables (belonging in
/bin and /usr/bin), creating such links becomes impossible, and the
problem vanishes.

If a SUID program is found to have a security hole, the administrator
should make sure he removes all links to it when deleting it, just to
be safe.

-- 
Måns Rullgård
mru@kth.se

Re: hard links create local DoS vulnerability and security problems

[Richard B. Johnson]

On Mon, 24 Nov 2003, Jakob Lell wrote:

> Hello,
> on Linux it is possible for any user to create a hard link to a file belonging
> to another user. This hard link continues to exist even if the original file
> is removed by the owner. However, as the link still belongs to the original
> owner, it is still counted to his quota. If a malicious user creates hard
> links for every temp file created by another user, this can make the victim
> run out of quota (or even fill up the hard disk). This makes a local DoS
> attack possible.
>

You can create hard-links to any file that a user has given you
permission to read or execute. This is correct. The new hard-link
still belongs to the original user, which is also correct.

To prevent this, a user can set his default permissions so that
neither group nor world can read the files. This is usually done
by setting the attributes in the user's top directory.

> Furthermore, users can even create links to a setuid binary. If there is a
> security whole like a buffer overflow in any setuid binary, a cracker can
> create a hard link to this file in his home directory. This link still exists
> when the administrator has fixed the security whole by removing or replacing
> the insecure program. This makes it possible for a cracker to keep a security
> whole open until an exploit is available. It is even possible to create links
> to every setuid program on the system. This doesn't create new security
> wholes but makes it more likely that they are exploited.
>

A setuid binary created with a hard-link will only work as a setuid
binary if the directory it's in is owned by root. If you have users
that can create files or hard-links within such directories, you
have users who either know the root password already or have used
some exploit to become root. In any case, it's not a hard-link
problem

> To solve the problem, the kernel shouldn't allow users to create hard
> links to
> files belonging to someone else.
>

No. Users must be able to create hard links to files that belong
to somebody else if they are readable. It's a requirement.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: hard links create local DoS vulnerability and security problems

[Jamie Lokier]

Richard B. Johnson wrote:
> To prevent this, a user can set his default permissions so that
> neither group nor world can read the files. This is usually done
> by setting the attributes in the user's top directory.

Correct, but the quota problem is genuine: what if I want to create a
lot of files in /home/jamie that are readable by other users, but I
want to be able to delete them at some later time and reuse my quota
for something else?

This is quite a normal scenario on multi-user systems with quotas.

You seem to be suggesting that the only method is to have a separate
partition for each user, which is absurd.

Another method is "tree quotas" which have come up on this list
before.  Hopefully they will be included one day; tree quotas seem
like they would solve this problem and some others.

> A setuid binary created with a hard-link will only work as a setuid
> binary if the directory it's in is owned by root.

That isn't true.

> If you have users that can create files or hard-links within such
> directories, you have users who either know the root password
> already or have used some exploit to become root. In any case, it's
> not a hard-link problem

/tmp is owned by root and anyone can create a hard link in /tmp to
other files, on a system where /tmp doesn't have its own filesystem.

> No. Users must be able to create hard links to files that belong
> to somebody else if they are readable. It's a requirement.

I disagree.  The ability to create files and declare that someone else
can't hard link to them would be useful in a multi-user environment.

-- Jamie

Re: hard links create local DoS vulnerability and security problems

[Rudo Thomas]

> A setuid binary created with a hard-link will only work as a setuid
> binary if the directory it's in is owned by root. [...]

This is not true, just verified it.

Rudo.

Re: hard links create local DoS vulnerability and security problems

[Jakob Lell]

Hello
On Monday 24 November 2003 18:14, Richard B. Johnson wrote:
> On Mon, 24 Nov 2003, Jakob Lell wrote:
> > Hello,
> > on Linux it is possible for any user to create a hard link to a file
> > belonging to another user. This hard link continues to exist even if the
> > original file is removed by the owner. However, as the link still belongs
> > to the original owner, it is still counted to his quota. If a malicious
> > user creates hard links for every temp file created by another user, this
> > can make the victim run out of quota (or even fill up the hard disk).
> > This makes a local DoS attack possible.
>
> You can create hard-links to any file that a user has given you
> permission to read or execute. This is correct. The new hard-link
> still belongs to the original user, which is also correct.
No. You need neither read nor execute permission to create a hard link.
>
> To prevent this, a user can set his default permissions so that
> neither group nor world can read the files. This is usually done
> by setting the attributes in the user's top directory.
Even if you needed read or execute permissions to create hard link, this isn't 
always possible. Some files have to be world readable.
>
> > Furthermore, users can even create links to a setuid binary. If there is
> > a security whole like a buffer overflow in any setuid binary, a cracker
> > can create a hard link to this file in his home directory. This link
> > still exists when the administrator has fixed the security whole by
> > removing or replacing the insecure program. This makes it possible for a
> > cracker to keep a security whole open until an exploit is available. It
> > is even possible to create links to every setuid program on the system.
> > This doesn't create new security wholes but makes it more likely that
> > they are exploited.
>
> A setuid binary created with a hard-link will only work as a setuid
> binary if the directory it's in is owned by root. If you have users
> that can create files or hard-links within such directories, you
> have users who either know the root password already or have used
> some exploit to become root. In any case, it's not a hard-link
> problem
Setuid-root binaries also work in a home directory.
You can try it by doing this test:
ln /bin/ping $HOME/ping
$HOME/ping localhost
>
> > To solve the problem, the kernel shouldn't allow users to create hard
> > links to
> > files belonging to someone else.
>
> No. Users must be able to create hard links to files that belong
> to somebody else if they are readable. It's a requirement.
If this is REALLY neccessary, it might be possible to prevent hard links to 
setuid binaries.
Regards
 Jakob

Re: hard links create local DoS vulnerability and security problems

[splite]

On Mon, Nov 24, 2003 at 06:57:41PM +0100, Jakob Lell wrote:
> [...]
> Setuid-root binaries also work in a home directory.
> You can try it by doing this test:
> ln /bin/ping $HOME/ping
> $HOME/ping localhost
> [...]

That's why you don't put user-writable directories on the root or /usr
partitions.  (For extra points, mount your /tmp and /var/tmp partitions
nodev,nosuid.)  Seriously guys, this is Unix Admin 101, not a major new
security problem.

Re: hard links create local DoS vulnerability and security problems

[Richard B. Johnson]

On Mon, 24 Nov 2003, Rudo Thomas wrote:

> > A setuid binary created with a hard-link will only work as a setuid
> > binary if the directory it's in is owned by root. [...]
>
> This is not true, just verified it.
>
> Rudo.
>
Really? Has your system been hacked?

Script started on Mon Nov 24 12:56:36 2003
# cat xxx.c

#include <stdio.h>
#include <unistd.h>

int main()
{
   setuid(0);
   setgid(0);
   system("whoami");
   return 0;
}
# gcc -o /tmp/xxx xxx.c
# cd /tmpo\b \b
# chmod 4755 xxx
# su johnson
$ pwd
/tmp
$ ./xxx
root
$ cd ~
$ cp /tmp/xxx .
$ ls -la xxx
-rwxr-xr-x   1 rjohnson guru         4887 Nov 24 12:57 xxx
$ ./xxx
rjohnson
$ chmod 4755 xxx
$ ./xxx
rjohnson
$ rm xxx
$ ln /tmp/xxx xxx
$ ./xxx
rjohnson
You have new mail in /var/spool/mail/root
$ exit
exit

Script done on Mon Nov 24 13:00:08 2003


This clearly shows that once the file exists in a non-root
directory, it will not function as setuid root.


Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: hard links create local DoS vulnerability and security problems

[Richard B. Johnson]

On Mon, 24 Nov 2003 splite@purdue.edu wrote:

> On Mon, Nov 24, 2003 at 06:57:41PM +0100, Jakob Lell wrote:
> > [...]
> > Setuid-root binaries also work in a home directory.
> > You can try it by doing this test:
> > ln /bin/ping $HOME/ping
> > $HOME/ping localhost
> > [...]
>
> That's why you don't put user-writable directories on the root or /usr
> partitions.  (For extra points, mount your /tmp and /var/tmp partitions
> nodev,nosuid.)  Seriously guys, this is Unix Admin 101, not a major new
> security problem.
>

And if the inode that was referenced in the root-owned directory
was deleted, it would no longer function as setuid root.


Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: hard links create local DoS vulnerability and security problems

[Jakob Lell]

On Monday 24 November 2003 19:08, splite@purdue.edu wrote:
> On Mon, Nov 24, 2003 at 06:57:41PM +0100, Jakob Lell wrote:
> > [...]
> > Setuid-root binaries also work in a home directory.
> > You can try it by doing this test:
> > ln /bin/ping $HOME/ping
> > $HOME/ping localhost
> > [...]
>
> That's why you don't put user-writable directories on the root or /usr
> partitions.  (For extra points, mount your /tmp and /var/tmp partitions
> nodev,nosuid.)  Seriously guys, this is Unix Admin 101, not a major new
> security problem.
Even if you put /usr on a separate partition, users can create a setuid (not 
setuid-root) program in their home directory. Other users can create links to 
this program in their home directory. Even if this can't be used to become 
root, it shouldn't be possible. To prevent this, you have to put every user's 
home directory on a separate partition.

Re: hard links create local DoS vulnerability and security problems

[Michael Buesch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 24 November 2003 18:57, Jakob Lell wrote:
> > > To solve the problem, the kernel shouldn't allow users to create hard
> > > links to
> > > files belonging to someone else.
> >
> > No. Users must be able to create hard links to files that belong
> > to somebody else if they are readable. It's a requirement.
>
> If this is REALLY neccessary, it might be possible to prevent hard links to
> setuid binaries.

What about _not_ modifying the mainstream-kernel behaviour,
but adding an option, to make users unable to create such hard-links,
to selinux and/or grsec?

> Regards
>  Jakob

- -- 
Regards Michael Buesch  [ http://www.tuxsoft.de.vu ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/wkw8oxoigfggmSgRArwLAJ47CAW90QtuEK+PNAlpzDf3ZBmohgCeKaGT
YKUZQRAYYnszq90a34KmH6U=
=EUOO
-----END PGP SIGNATURE-----

Re: hard links create local DoS vulnerability and security problems

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 490 bytes --]

On Mon, 24 Nov 2003 13:10:46 EST, "Richard B. Johnson" said:

> # chmod 4755 xxx
> # su johnson
> $ cp /tmp/xxx .
> $ ls -la xxx
> -rwxr-xr-x   1 rjohnson guru         4887 Nov 24 12:57 xxx
     ^  Hmm.. this sucker is mode 755, not 4755...

> This clearly shows that once the file exists in a non-root
> directory, it will not function as setuid root.

No, what it shows is that once you *copy* the file to another file,
and the second file isn't set-UID, it won't run as set-UID anymore.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: hard links create local DoS vulnerability and security problems

[Jakob Lell]

On Monday 24 November 2003 19:13, Richard B. Johnson wrote:
> On Mon, 24 Nov 2003 splite@purdue.edu wrote:
> > On Mon, Nov 24, 2003 at 06:57:41PM +0100, Jakob Lell wrote:
> > > [...]
> > > Setuid-root binaries also work in a home directory.
> > > You can try it by doing this test:
> > > ln /bin/ping $HOME/ping
> > > $HOME/ping localhost
> > > [...]
> >
> > That's why you don't put user-writable directories on the root or /usr
> > partitions.  (For extra points, mount your /tmp and /var/tmp partitions
> > nodev,nosuid.)  Seriously guys, this is Unix Admin 101, not a major new
> > security problem.
>
> And if the inode that was referenced in the root-owned directory
> was deleted, it would no longer function as setuid root.
Hello,
I've just checked it out. It still works as setuid root. Just try this (as 
root):
cp /bin/ping /tmp/ping
chmod 4755 /tmp/ping
su user
ln /tmp/ping $HOME/ping
exit
rm /tmp/ping
su user
$HOME/ping localhost
rm $HOME/ping

Regards
 Jakob

Re: hard links create local DoS vulnerability and security problems

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1088 bytes --]

On Mon, 24 Nov 2003 19:18:56 +0100, Jakob Lell said:
> 
> Even if you put /usr on a separate partition, users can create a setuid (not 
> setuid-root) program in their home directory. Other users can create links to
 
> this program in their home directory. Even if this can't be used to become 
> root, it shouldn't be possible. To prevent this, you have to put every user's
 
> home directory on a separate partition.

mkdir ~/bin
chmod 700 ~/bin
cat > ~/bin/show-me
#!/bin/sh
whoami
^D
chmod 4755 ~/bin/show-me

No separate partitions needed.

If the link() syscall doesn't throw an EACCESS because of that chmod,
you have bigger problems.

In any case, if a user is *MAKING* a program set-UID, it's probably because
he *wants* it to run as himself even if others invoke it (otherwise, he
could just leave it in ~/bin and be happy).  So this is really a red herring,
as it's only a problem if (a) he decides to get rid of the binary, and fails
to do so because of hard links he doesn't know about, or (b) he's an idiot
programmer and it malfunctions if invoked with an odd argv[0]....

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: hard links create local DoS vulnerability and security problems

[Jakob Lell]

On Monday 24 November 2003 19:21, Michael Buesch wrote:
> On Monday 24 November 2003 18:57, Jakob Lell wrote:
> > > > To solve the problem, the kernel shouldn't allow users to create hard
> > > > links to
> > > > files belonging to someone else.
> > >
> > > No. Users must be able to create hard links to files that belong
> > > to somebody else if they are readable. It's a requirement.
> >
> > If this is REALLY neccessary, it might be possible to prevent hard links
> > to setuid binaries.
>
> What about _not_ modifying the mainstream-kernel behaviour,
> but adding an option, to make users unable to create such hard-links,
> to selinux and/or grsec?
Hello,
this would be possible. However, most admins don't install this patches and 
thus stay vulnerable. Is there any reason why users should be able to create 
hard links to setuid programs belonging to anyone else?
Regards
 Jakob

Re: hard links create local DoS vulnerability and security problems

[Chris Wright]

* Michael Buesch (mbuesch@freenet.de) wrote:
> What about _not_ modifying the mainstream-kernel behaviour,
> but adding an option, to make users unable to create such hard-links,
> to selinux and/or grsec?

It's already in grsec and owl.  SELinux has the ability to control this
behaviour, just requires the right policy.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: hard links create local DoS vulnerability and security problems

[Mike Fedyk]

On Mon, Nov 24, 2003 at 06:05:53PM +0100, M?ns Rullg?rd wrote:
> If a SUID program is found to have a security hole, the administrator
> should make sure he removes all links to it when deleting it, just to
> be safe.

or in the common case:
s/administrator/package manager/

Re: hard links create local DoS vulnerability and security problems

[Andy Lutomirski]

Valdis.Kletnieks@vt.edu wrote:

> 
> In any case, if a user is *MAKING* a program set-UID, it's probably because
> he *wants* it to run as himself even if others invoke it (otherwise, he
> could just leave it in ~/bin and be happy).  So this is really a red herring,
> as it's only a problem if (a) he decides to get rid of the binary, and fails
> to do so because of hard links he doesn't know about, or (b) he's an idiot
> programmer and it malfunctions if invoked with an odd argv[0]....

Right... but non-privileged users _can't_ delete these extra links, even 
if they notice them from the link count.  And non-idiots do make 
security errors -- they just fix them.  But in this case, fixing the 
error after the fact may be impossible without root's help.

And how many package managers / install scripts check for hard links of 
files they're about to overwrite?

--Andy

Re: hard links create local DoS vulnerability and security problems

[Linus Torvalds]

On Mon, 24 Nov 2003, Andy Lutomirski wrote:
>
> Right... but non-privileged users _can't_ delete these extra links, even
> if they notice them from the link count.  And non-idiots do make
> security errors -- they just fix them.  But in this case, fixing the
> error after the fact may be impossible without root's help.

Just do

	chmod ug-s file

and you're done.

If you delete the file first, you'll need roots help, but hey, be careful.

		Linus

Re: hard links create local DoS vulnerability and security problems

[John Bradford]

Quote from Andy Lutomirski <luto@myrealbox.com>:
> 
> 
> Valdis.Kletnieks@vt.edu wrote:
> 
> > 
> > In any case, if a user is *MAKING* a program set-UID, it's probably because
> > he *wants* it to run as himself even if others invoke it (otherwise, he
> > could just leave it in ~/bin and be happy).  So this is really a red herring,
> > as it's only a problem if (a) he decides to get rid of the binary, and fails
> > to do so because of hard links he doesn't know about, or (b) he's an idiot
> > programmer and it malfunctions if invoked with an odd argv[0]....
> 
> Right... but non-privileged users _can't_ delete these extra links, even 
> if they notice them from the link count.

They can truncate the file to zero length, though, then delete the
'original' link, making all of the other links point to the zero
length file.

John.

Re: hard links create local DoS vulnerability and security problems

[Måns Rullgård]

John Bradford <john@grabjohn.com> writes:

>> Right... but non-privileged users _can't_ delete these extra links, even 
>> if they notice them from the link count.
>
> They can truncate the file to zero length, though, then delete the
> 'original' link, making all of the other links point to the zero
> length file.

It could be tricky to find those extra links if the original has been
deleted, of course.

-- 
Måns Rullgård
mru@kth.se

Re: hard links create local DoS vulnerability and security problems

[Ricky Beam]

On Mon, 24 Nov 2003, Linus Torvalds wrote:
>Just do
>
>	chmod ug-s file
>
>and you're done.
>
>If you delete the file first, you'll need roots help, but hey, be careful.

Heh, thus enters paranoia... patern fill the file (zero's will do), truncate,
'chmod 0', and *then* unlink it.  Yeah, it's eating up an inode charged to
the user, but otherwise, no space and the contents are gone.

--Ricky

Re: hard links create local DoS vulnerability and security problems

[bill davidsen]

In article <200311241736.23824.jlell@JakobLell.de>,
Jakob Lell  <jlell@JakobLell.de> wrote:

| on Linux it is possible for any user to create a hard link to a file belonging 
| to another user. This hard link continues to exist even if the original file 
| is removed by the owner. However, as the link still belongs to the original 
| owner, it is still counted to his quota. If a malicious user creates hard 
| links for every temp file created by another user, this can make the victim 
| run out of quota (or even fill up the hard disk). This makes a local DoS 
| attack possible.

Of course they must be created in a directory when the evil user has
write, from a directory where the evil user has... have to check if
that's read or just evecute.
| 
| Furthermore, users can even create links to a setuid binary. If there is a 
| security whole like a buffer overflow in any setuid binary, a cracker can 
| create a hard link to this file in his home directory.

Not unless the admin is a total bozo... remember hard links must be in
the same filesystem, and I wouldn't expect untrusted users to have write
in /usr, /var, /lib or /opt, which is where the problem might likely to
exist.

|                                                        This link still exists 
| when the administrator has fixed the security whole by removing or replacing 
| the insecure program. This makes it possible for a cracker to keep a security 
| whole open until an exploit is available. It is even possible to create links 
| to every setuid program on the system. This doesn't create new security 
| wholes but makes it more likely that they are exploited.

See above, this is less likely that you make it sound.
| 
| To solve the problem, the kernel shouldn't allow users to create hard links to 
| files belonging to someone else.

While I think you're overblowing the problem, it is an issue which might
be addressed in SE Linux or somewhere. I have an idea on that, but I
want to look before I suggest anything.
| 
| I could reproduce the problem on linux 2.2.19 and 2.4.21 (and found nothing 
| about it in the changelogs to 2.4.23-rc3).

Bear in mind it isn't a "problem" it's 'expected behaviour" for the o/s,
and might even be mentioned in SuS somehow. Interesting topic, but not a
bug, since the behaviour is as intended.
-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: hard links create local DoS vulnerability and security problems

[bill davidsen]

In article <Pine.LNX.4.53.0311241312180.18685@chaos>,
Richard B. Johnson <root@chaos.analogic.com> wrote:
| On Mon, 24 Nov 2003 splite@purdue.edu wrote:
| 
| > On Mon, Nov 24, 2003 at 06:57:41PM +0100, Jakob Lell wrote:
| > > [...]
| > > Setuid-root binaries also work in a home directory.
| > > You can try it by doing this test:
| > > ln /bin/ping $HOME/ping
| > > $HOME/ping localhost
| > > [...]
| >
| > That's why you don't put user-writable directories on the root or /usr
| > partitions.  (For extra points, mount your /tmp and /var/tmp partitions
| > nodev,nosuid.)  Seriously guys, this is Unix Admin 101, not a major new
| > security problem.
| >
| 
| And if the inode that was referenced in the root-owned directory
| was deleted, it would no longer function as setuid root.

??? think about how the inode is deleted... by removing all links.
Clearly if there is another link the inode can't be deleted, and if the
inode is deleted whatever you meant by "it" would function or even exist
(both the link and the inode would be gone).
-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: hard links create local DoS vulnerability and security problems

[bill davidsen]

In article <20031124105321.A16684@osdlab.pdx.osdl.net>,
Chris Wright  <chrisw@osdl.org> wrote:
| * Michael Buesch (mbuesch@freenet.de) wrote:
| > What about _not_ modifying the mainstream-kernel behaviour,
| > but adding an option, to make users unable to create such hard-links,
| > to selinux and/or grsec?
| 
| It's already in grsec and owl.  SELinux has the ability to control this
| behaviour, just requires the right policy.

Bah!! I just spent 20 minutes deciding that I could add an attribute to
a file which prevented hard links, and similar to a directory. OTOH you
saved me the work of doing more than a few lines on paper, and it's
reassuring to know the security patches are ahead of the problem.
-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: hard links create local DoS vulnerability and security problems

[Mike Fedyk]

On Mon, Nov 24, 2003 at 11:50:12PM +0000, Bill Davidsen wrote:
> While I think you're overblowing the problem, it is an issue which might
> be addressed in SE Linux or somewhere. I have an idea on that, but I
> want to look before I suggest anything.

Other posts in this thread confirm that se-linux is able to do this if
configured correctly, and is an option in grsec.

Re: hard links create local DoS vulnerability and security problems

[Chris Wright]

* bill davidsen (davidsen@tmr.com) wrote:
> 
> While I think you're overblowing the problem, it is an issue which might
> be addressed in SE Linux or somewhere. I have an idea on that, but I
> want to look before I suggest anything.

SELinux controls hard link creation by checking, among other things,
the security context of the process attempting the link, and the security
context of the target (oldpath).  Other MAC systems do similar, and some
patches such as grsec and owl simply disable linking to files the user
can't read/write to for example.

> Bear in mind it isn't a "problem" it's 'expected behaviour" for the o/s,
> and might even be mentioned in SuS somehow. Interesting topic, but not a
> bug, since the behaviour is as intended.

SuS states:
	
	The implementation may require that the calling process has
	permission to access the existing file.

Note the use of *may*.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: hard links create local DoS vulnerability and security problems

[Matthias Andree]

On Mon, 24 Nov 2003, Jamie Lokier wrote:

> You seem to be suggesting that the only method is to have a separate
> partition for each user, which is absurd.

In a previous life, I've seen this happen on a Solaris box, where each
user's home directory was auto-mounted. I haven't tried to betray quotas
at that time though.

> /tmp is owned by root and anyone can create a hard link in /tmp to
> other files, on a system where /tmp doesn't have its own filesystem.

Convert /tmp to swap, mount -t tmpfs :-)

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95

Re: hard links create local DoS vulnerability and security problems

[Amon Ott]

On Dienstag, 25. November 2003 01:35, Chris Wright wrote:
> * bill davidsen (davidsen@tmr.com) wrote:
> > 
> > While I think you're overblowing the problem, it is an issue which might
> > be addressed in SE Linux or somewhere. I have an idea on that, but I
> > want to look before I suggest anything.
> 
> SELinux controls hard link creation by checking, among other things,
> the security context of the process attempting the link, and the security
> context of the target (oldpath).  Other MAC systems do similar, and some
> patches such as grsec and owl simply disable linking to files the user
> can't read/write to for example.

..and in RSBAC, LINK_HARD has been a controlled separate type of access since 
the very first version back in 1997. It has always been treated like a write 
access to the target file by all decision modules, because of the 
implications mentioned in this thread.

Amon.
-- 
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22

Re: hard links create local DoS vulnerability and security problems

[Gianni Tedesco]

[-- Attachment #1: Type: text/plain, Size: 437 bytes --]

On Mon, 2003-11-24 at 17:36, Jakob Lell wrote:
> To solve the problem, the kernel shouldn't allow users to create hard links to 
> files belonging to someone else.

chmod(fn, 0);
truncate(fn, 0);
unlink(fn);

then just the inode remains.

-- 
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source www.scaramanga.co.uk/scaramanga.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: hard links create local DoS vulnerability and security problems

[John Bradford]

Quote from mru@kth.se (=?iso-8859-1?q?M=E5ns_Rullg=E5rd?=):
> John Bradford <john@grabjohn.com> writes:
> 
> >> Right... but non-privileged users _can't_ delete these extra links, =
> even=20
> >> if they notice them from the link count.
> >
> > They can truncate the file to zero length, though, then delete the
> > 'original' link, making all of the other links point to the zero
> > length file.
> 
> It could be tricky to find those extra links if the original has been
> deleted, of course.

True, but as long as at least one of the links which has been made to
the original file is in a directory you have access to, you can simply
create a new link to the file, truncate it, then delete your newly
created link, so actually deleting the 'original' link is not
necessarily a problem :-).

John.

Re: hard links create local DoS vulnerability and security problems

[Måns Rullgård]

John Bradford <john@grabjohn.com> writes:

>> > They can truncate the file to zero length, though, then delete the
>> > 'original' link, making all of the other links point to the zero
>> > length file.
>> 
>> It could be tricky to find those extra links if the original has been
>> deleted, of course.
>
> True, but as long as at least one of the links which has been made to
> the original file is in a directory you have access to, you can simply
> create a new link to the file, truncate it, then delete your newly
> created link, so actually deleting the 'original' link is not
> necessarily a problem :-).

There's no need to make a new link, since any links will be owned by
the original owner.  That was the concern in the first place.  The
problem is finding a link after the file has been deleted.  It could
be hidden away somewhere in a directory you don't have read or execute
permission for.

-- 
Måns Rullgård
mru@kth.se

Re: hard links create local DoS vulnerability and security problems

[John Bradford]

Quote from mru@kth.se (=?iso-8859-1?q?M=E5ns_Rullg=E5rd?=):
> John Bradford <john@grabjohn.com> writes:
> 
> >> > They can truncate the file to zero length, though, then delete the
> >> > 'original' link, making all of the other links point to the zero
> >> > length file.
> >>=20
> >> It could be tricky to find those extra links if the original has bee=
> n
> >> deleted, of course.
> >
> > True, but as long as at least one of the links which has been made to
> > the original file is in a directory you have access to, you can simpl=
> y
> > create a new link to the file, truncate it, then delete your newly
> > created link, so actually deleting the 'original' link is not
> > necessarily a problem :-).
> 
> There's no need to make a new link, since any links will be owned by
> the original owner.  That was the concern in the first place.  The
> problem is finding a link after the file has been deleted.  It could
> be hidden away somewhere in a directory you don't have read or execute
> permission for.

Ah, OK, I was thinking of something else entirely :-)

John.

Re: hard links create local DoS vulnerability and security problems

[Jesse Pollard]

On Monday 24 November 2003 11:57, Jakob Lell wrote:
> Hello
>
> On Monday 24 November 2003 18:14, Richard B. Johnson wrote:
> > On Mon, 24 Nov 2003, Jakob Lell wrote:
> > > Hello,
> > > on Linux it is possible for any user to create a hard link to a file
> > > belonging to another user. This hard link continues to exist even if
> > > the original file is removed by the owner. However, as the link still
> > > belongs to the original owner, it is still counted to his quota. If a
> > > malicious user creates hard links for every temp file created by
> > > another user, this can make the victim run out of quota (or even fill
> > > up the hard disk). This makes a local DoS attack possible.
[snip]
> >
> > A setuid binary created with a hard-link will only work as a setuid
> > binary if the directory it's in is owned by root. If you have users
> > that can create files or hard-links within such directories, you
> > have users who either know the root password already or have used
> > some exploit to become root. In any case, it's not a hard-link
> > problem
>
> Setuid-root binaries also work in a home directory.
> You can try it by doing this test:
> ln /bin/ping $HOME/ping
> $HOME/ping localhost

What? You allow users write access to a filesystem containing privileged
applications????

You really shouldn't do that. Any filesystem a user has write access to should
be mounted nosgid.

> > > To solve the problem, the kernel shouldn't allow users to create hard
> > > links to
> > > files belonging to someone else.
> >
> > No. Users must be able to create hard links to files that belong
> > to somebody else if they are readable. It's a requirement.
>
> If this is REALLY neccessary, it might be possible to prevent hard links to
> setuid binaries.
> Regards
>  Jakob

You would also have to consider setgid binaries.

It also means that you have to read the inode of the source file. Right now,
only the contents of directory have to be read (the file search for the inode
number).

Re: hard links create local DoS vulnerability and security problems

[Jan Kara]

> Richard B. Johnson wrote:
> > To prevent this, a user can set his default permissions so that
> > neither group nor world can read the files. This is usually done
> > by setting the attributes in the user's top directory.
> 
> Correct, but the quota problem is genuine: what if I want to create a
> lot of files in /home/jamie that are readable by other users, but I
> want to be able to delete them at some later time and reuse my quota
> for something else?
> 
> This is quite a normal scenario on multi-user systems with quotas.
> 
> You seem to be suggesting that the only method is to have a separate
> partition for each user, which is absurd.
  I agree that malicious user can make some user run out of quotas
(actually he can do it even by more secret way by just opening the files
- but for this at least read permission is needed). But I guess that
reasonably capable admin discovers the problem and /bin/nologin as a
login shell solves the problem...

> Another method is "tree quotas" which have come up on this list
> before.  Hopefully they will be included one day; tree quotas seem
> like they would solve this problem and some others.
  Yes they would but denying hardlinks across 'quota trees' seems to be
the easiest way of making them technically possible and so you end up in
a similar situation as with some security patches...

								Honza

-- 
Jan Kara <jack@suse.cz>
SuSE CR Labs

Re: hard links create local DoS vulnerability and security problems

[Jakob Lell]

On Tuesday 25 November 2003 15:48, Jan Kara wrote:
> > Richard B. Johnson wrote:
> > > To prevent this, a user can set his default permissions so that
> > > neither group nor world can read the files. This is usually done
> > > by setting the attributes in the user's top directory.
> >
> > Correct, but the quota problem is genuine: what if I want to create a
> > lot of files in /home/jamie that are readable by other users, but I
> > want to be able to delete them at some later time and reuse my quota
> > for something else?
> >
> > This is quite a normal scenario on multi-user systems with quotas.
> >
> > You seem to be suggesting that the only method is to have a separate
> > partition for each user, which is absurd.
>
>   I agree that malicious user can make some user run out of quotas
> (actually he can do it even by more secret way by just opening the files
> - but for this at least read permission is needed). But I guess that
> reasonably capable admin discovers the problem and /bin/nologin as a
> login shell solves the problem...
Hello,
if it's a web server with thousands of users (and maybe millions of files 
in  /home), searching /home for files belonging to one user can take quite 
long (maybe hours). 
If the evil users can't create hard links and thus has to keep the file open 
instead of creating a hard link, the problem can quickly be found using lsof.
>
> > Another method is "tree quotas" which have come up on this list
> > before.  Hopefully they will be included one day; tree quotas seem
> > like they would solve this problem and some others.
>
>   Yes they would but denying hardlinks across 'quota trees' seems to be
> the easiest way of making them technically possible and so you end up in
> a similar situation as with some security patches...

This would also be a good way to fix the problem.
>
> 								Honza

Regards
  Jakob

Re: hard links create local DoS vulnerability and security problems

[Bill Davidsen]

On Mon, 24 Nov 2003, Chris Wright wrote:

> * bill davidsen (davidsen@tmr.com) wrote:
> > 
> > While I think you're overblowing the problem, it is an issue which might
> > be addressed in SE Linux or somewhere. I have an idea on that, but I
> > want to look before I suggest anything.
> 
> SELinux controls hard link creation by checking, among other things,
> the security context of the process attempting the link, and the security
> context of the target (oldpath).  Other MAC systems do similar, and some
> patches such as grsec and owl simply disable linking to files the user
> can't read/write to for example.
> 
> > Bear in mind it isn't a "problem" it's 'expected behaviour" for the o/s,
> > and might even be mentioned in SuS somehow. Interesting topic, but not a
> > bug, since the behaviour is as intended.
> 
> SuS states:
> 	
> 	The implementation may require that the calling process has
> 	permission to access the existing file.
> 
> Note the use of *may*.

I note the "permission to access" as well, that's not exactly definitive,
either. Could mean anything from rwx on the file to execute on the file
and all directories in the path. And a conforming o/s could demand that
the process doing the link have the same EUID as the UID of the file. I
would expect that to break things, however, although the things which
break may not be desirable!

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.