10

Dumb things you can sometimes do with hard links

 2 years ago
source link: http://rachelbythebay.com/w/2022/03/15/link/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

Dumb things you can sometimes do with hard links

Here's a very old and stupid trick you could do with some filesystems in some situations back in the day... and might still be able to do in a few places today.

Let's say you have an account on a vaguely Unixy box that you don't run, and you are looking to exploit a hole to get root. You notice there's some program that is installed suid root and which has a terrible security record. It's chock full of awful practices and it seems like every month there's a new hole in it and admins have to race to patch it before the script kiddies of the world use it for great evil.

The problem is that while version X might eventually have an exploit, it'll get removed and it'll be replaced by version Y without that particular hole. By the time you get your hands on a tool to break into X, it'll be gone.

But... what if you could keep a copy of X around, you know, for later?

What you'd do is create a hard link pointing at the file you wanted to preserve, storing it in a spot which was writable by your account. Then, say, /usr/bin/sudo (because that never has security issues...) gets replaced at some point with a new file and you get to keep the old version. When you get the tool to pop it, off you go!

This is one of those reasons why old-school multi-user systems used to put stuff like /usr on one filesystem and things like home directories on another. That way, they couldn't hard link to arbitrary crap like that and extend the lifespan of a potentially vulnerable file. Of course, they could also extend the lifespan of someone else's stuff and screw up their quota, so there was that...

Of course, these days, it's not quite so easy on the more modern systems you find. Debian 11 here won't let me do it - it's EPERM city. Rocky 8 (so CentOS 8 and RHEL 8 too) also won't do it. They both have some gunk in /usr/lib/sysctl.d to lock this down. But, my old Slackware 14.2 install of my workstation let me do it the last time I tried about a year ago. How about that, huh? I bet it'd still work if I dug out the old drives and booted them up.

So, if you have older machines in your lives with potentially shady characters running things on them, you might want to check them out. You might learn something new and interesting.

Incidentally, this is the magic sauce: /proc/sys/fs/protected_hardlinks Read the man page for proc(5) to learn more about it.

What's kind of funny is that there was a discussion about this on the linux-kernel mailing list back in November 2003 according to my original notes on the subject. So, I went looking for it, and sure enough, here it is, the thread I read a long time ago. It's interesting to note that as far as I can tell, nothing actually changed upstream. This left paranoid admins like me with no option but to use the (most excellent) Openwall patches to lock down this kind of stuff. I used that on my machines at work which had non-staff users... just in case.

It appears this /proc knob showed up in Linux 3.6, and it looks like that dates to 2012. Hmm. 2003... and 2012. That's a long time. Obviously, mad props are due the person who braved the lkml and got it to finally happen upstream.

This whole situation is scary. Read more about it.


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK