Re: hard links create local DoS vulnerability and security problems

[davidsen@tmr.com (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.