Race Condition Trick /proc/self/fd

In the suidbash CTF challenge there was an inconspicuous line of code, but it was actually there to prevent a race condition. Let's talk about it this video!


-=[ 🔴 Stuff I use ]=-


-=[ ❤️ Support ]=-


-=[ 🐕 Social ]=-


-=[ 📄 P.S. ]=-

All links with "*" are affiliate links.
LiveOverflow / Security Flag GmbH is part of the Amazon Affiliate Partner Programm.

[stormix_co]

Love the upload schedule, but make sure you're comfortable with it. We don't want you to burn out. Keep up the good work!

[BILLable]

For those who would wonder how come recreating the file does not change the status into the /proc/pid/fd directory after removing the file, it is because it gets another inode. Something that people should realise is that the kernel is not aware about file name (or path). It only knows about file inode. Since file descriptors are allocated by the kernel, it actually links the file descriptor of that process to a specific inode number. When you delete the file, you delete the inode. When you re-create the file, the a new inode is allocated and so the already opened file descriptors and their links are not impacted.

[luxdios]

Loving all of the new content! Thanks for all the hard work.

[tonyblox]

I don't know what you are talking about but I'm glad that you uploaded a video

[caquino]

Another trick for using proc file system that saved me before is /proc/self/exe. A user by accident deleted /bin/bash on the server and a lot of things started to fail because of that, I had a shell still open on the server so I could execute cat /proc/self/exe > /bin/bash and then fix the permissions on the recovered /bin/bash. This was many years ago, on the age of the kernel 2.0.X, I wonder if it still works actually.

[michaelscofield]

This was surprisingly helpful. Binging your videos lately

[suttichort]

Very good explanation of file descriptor. And this is the reason that if you want to remove the large log file, better to use echo > logfile instead of rm logfile :)

[crlfff]

Love your vids even tho i am still a newbie and don’t understand everything. I will continue to learn

[yuxin]

This is fascinating! I was always annoyed when I tried to rename or delete a file that is being opened and Windows does not allowed me to do so (it will throw an error such as the file is in use). Linux solves this problem much more elegantly and I don’t know how it works until I watched this video.

[Pyrazahn]

What surprised me is that the filename both
a) is reflecting the new name after the rename - which suggests that it's doing a reverse lookup from inode to path (which in turn I assumed was only possible through a full filesystem traversal because filename -> inode is a one way link)
b) stays visible after deletion - which suggests it's not doing a reverse lookup but instead the original path used in the open call is stored as string.
That makes me wonder what happens if you have a hardlinked file that you open through filename A, then unlink that and run ls on the file descriptor. will it then show "A (deleted)" or will it swap over to "B"?

[okaze]

Cool to teach the basics to people. The secure temporary files script shell tools were using these tools by creating a file with random name, keeping the fd then removing the file. People that don’t know the basics of filesystems don’t understand that when you remove a file, you just remove it from the directory structure, the file is still there until replaced by other data. The file descriptor is the true reference to a file though. As long as one reference exists, the filesystem won’t overwrite the file. When you understand how a filesystem works, you then can understand the purpose of the file shredding tools used in security, and why they can take so much time. Though for that, you need to understand how data are stored on storage media and know how each storage media works.

[Schwuuuuup]

nice trick, didn't know that the deleted files are visible in /proc. This knowledge would have been useful when I had a problem with PHP's APC which stores cache info in files in a deleted state. I had no space left on a file system which was virtually empty and had 100% available.

[MonkeeSage]

I remember back in the day, letting movies buffer all the way in the flash player browser plugin, and then copying the file from the deleted proc fd that the plugin was still holding open. Speaking theoretically of course.

[ShortGiant]

Awesome video! Make one on zombie processes please.

[klightspeed]

I'm guessing that open(path, flags) treats symlinks in /proc/{pid}/fd/{fd} specially - instead of doing normal symlink resolution, it is equivalent to newfd = dup(fd); fcntl(newfd, F_SETFL, flags); except where {fd} belongs to the process {pid}

[benhetland]

It is interesting that in procfs the files are presented as symbolic links while acting almost exactly like hard links (i.e. as if using reference-counted inodes). The difference is merely that the links cross the FS boundary between the virtual procfs and the target FS. While the latter most likely is an extN variant under Linux this now makes me curious as to how many other kinds of more or less obscure file systems this works with ... ntfs, fat12, cifs?

[dWHOHWb]

What would happen if you read the deleted file via the file descriptor, AFTER overwriting that sector on your hard drive with some other data? Presumably if it's marked deleted, the file system would mark it as free and allow for overwrites. Unless the file descriptor being held open prevents the corresponding physical memory on the hard drive from being marked as "free".

[hikaru-live]

I wonder if I can use Swift REPL as Python replacement?

[beron_the_colossus]

Wow, this was a great video! Very informative, thanks!

[jfly]

I don’t know if you can say it like this, but is an open file descriptor similar to the windows files which have that ~ in front of them ?