Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The classic is say you know a root process will write a file called foo.lock in /run/lock, and you (a bad person) have write access to that directory. Then you make foo.lock a symlink to some file (/bin/init or /bin/sh or ld.so for example would be very inconvenient choices) and when the root process writes its lock it destroys that file.

Now obviously people these days generally know about that so hopefully don’t use predictable file names but that’s one way.



> and when the root process writes its lock it destroys that file.

Unless you do open("/run/lock/foo.lock", O_WRONLY|O_CREAT|O_EXCL|O_NOFOLLOW)


Yep. And for good measure, first open with O_CREAT as tempfile with random name, then rename() it to predictable "foo.lock".


Yup to both of you. But all of this is to say, running shellscripts as root (in particular) needs to be done with extreme care, because if people forget those precautions when writing C, they sure as heck don’t trouble themselves to do it when they’re writing shell.

I remember the time (around 2001-2002) when just about every binary was discovered to have some variant on this exact exploit. I happened to be linux sysadmin for a very large, high-profile set of linux boxes at the time. Happy times.


> Now obviously people these days generally know about that so hopefully don’t use predictable file names but that’s one way.

Annoying side effect: now you gotta guess which process created the darn lockfile.

A more sensible approach is to do sanity checking on the lockfile and its contents (i.e. does the contained PID match one's own binary).


> now you gotta guess which process created the darn lockfile

Or you can use “lsof” to just tell you.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: