File Path Race Condition & How To Prevent It - bin 0x31
HTML-код
- Опубликовано: 12 июл 2024
- In this video we look at a typical race condition involving file paths. We learn about the renameat syscall to exploit it and also how to fix it.
Source code: gist.github.com/LiveOverflow/...
=[ 🔴 Stuff I use ]=
→ Microphone:* amzn.to/2LW6ldx
→ Graphics tablet:* amzn.to/2C8djYj
→ Camera#1 for streaming:* amzn.to/2SJ66VM
→ Lens for streaming:* amzn.to/2CdG31I
→ Connect Camera#1 to PC:* amzn.to/2VDRhWj
→ Camera#2 for electronics:* amzn.to/2LWxehv
→ Lens for macro shots:* amzn.to/2C5tXrw
→ Keyboard:* amzn.to/2LZgCFD
→ Headphones:* amzn.to/2M2KhxW
=[ ❤️ Support ]=
→ per Video: / liveoverflow
→ per Month: / @liveoverflow
=[ 🐕 Social ]=
→ Twitter: / liveoverflow
→ Website: liveoverflow.com/
→ Subreddit: / liveoverflow
→ Facebook: / liveoverflow
=[ 📄 P.S. ]=
All links with "*" are affiliate links.
LiveOverflow / Security Flag GmbH is part of the Amazon Affiliate Partner Programm.
Wow, didn't know about the swapping syscall !
I really appreciate that you showed the way to fix this vulnerability also!! Very nice.
haha, you upload informational content on par with the best tutorials online, and your worried you don't upload enough. get some well needed rest buddy!
HOW IS HE UPLOADING THIS MUCH YOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
He's not wasting time:)
Interestingly, file contents may also suffer from race condition. I believe it was Samsung TVs which would read in firmware upgrade files from USB stick to verify their signature and if that check passed then read the file again to apply the upgrade. Issue is that one can easily create a USB device which returns some contents on first read but something completely different on another.
By the way, this file path race is essentially the reason why one cannot setuid shell scripts.
Can you expand on how this ties in with setuid on shell scripts?
@@SeanCMonahan, the way scripts work is that the kernel checks whether the first line of a file is a shebang line and then executes interpreter specified in that line with path to the file as an argument. Once the interpreter starts, it then reads contents of the file and executes it. This is the exact same scenario described in the video. If the executed script was a symbolic link, the kernel would resolve it once when checking ownership and permissions and then the interpreter would resolve the symbolic link again when it actually started executing the script.
And there isn’t really a way to solve this since the kernel cannot assume ‘/proc’ exists and besides passing a different path than the one pointing at the script may change how it is executed by the interpreter.
I'm extremely new to programming and still don't understand all of it. But this person is actively explaining code very well.
Awesome video. Never thought that race conditions on file paths would be a thing..
Hope you get well soon enough to enjoy Christmas!
Feel better man. Thanks for the video. Learned something new, as always from your channel.
It feels like Christmas, because so many new content! LOL. I appreciate your hard work LiveOverflow!
Out of all your videos, that's the first thing I geniunely didn't know about 🤩
I am surprised to see you uploading so many videos haha I hope you keep this up! love your content!
pretty sure this is because it's "hexember"
That was really interesting, even better that you showed how to prevent the race condition. Thank you!
Each video shows me, that I must no no have to learn more and more =D Thanks a lot for the explanation, and also for fixing part. It is really helpful.A few weeks ago I started to watch your binary series and now comes new episodes, they somehow filling each other. Really great recourse. Thanks again. By the way "Gute Beserrung" =) PS:I'm not a german,so hope I wrote it write =D
I have been using file paths without doing anything. Now I know. Please keep making more videos like this.
This is really cool, I've written similar racey file code before but never bothered to look into how you avoid it.
A great explanation of a common and easy to overlook bug.
Deine Videos retten gerade meine Klausur!
A classic well explained. It can help newcomers understand the newly introduced (thanks to systemd) pidfd in the Linux kernel.
Thanks, it really helped me to perform a priv esc
Thanks for the video, and thanks for the solution to the race condition. :)
This is a really useful video ..!! Keep this great work..
Great Video relly enjoyed it keep up the great work
thanks for such awesome tutorial. Keep it up
Reminds me of good old suid based dirtycow exploits, awesome video :D
Cool fix. Thanks!
Take your time and get better!
Exquisite! Thanks man 👍
If you need a break, take it! Have a nice christmas and get better ASAP, we can wait ^_^
Super interesting video, enjoyed it very much. Please take some rest if you are sick ;)
Get well soon!
Very cool I now know how to race a file path!!
Birth of new day huh?
I tried another approach, making a symlink to a empty file I have permissions to, breaking the readflag on an open() syscall and then pointing the symlink to the actual flag. This didnt work unfortunately, but I still learned stuff and you got me to do something, which is very lovely. Thank you.
" breaking the readflag on an open() syscall"
How? Did you attach a debugger? In case yes, then the program runs as a normal user, not as root, and it does not work.
@@happygimp0 yes yes, that makes sense
@MERL
You can still run it as root but then you have to start the debugger as root and that defeats the purpose of an exploit.
Really cool trick. Somewhat the same concept is using mkfifo to 'pause' the race - if a program writes to a pipe it'll then wait till something reads from it, and if it tries to read it'll wait till something writes.
I hope you get better master!
A simple way to show modifications through time, you can use the command watch -n 1 to execute a command each second to get the differences. Something like: ```watch -n 1 ls -lha```
Thanks for this boss
Nice video!
Don't worry about 24 videos! Get better first! :)
Amazing!
If you want to use only C without manual lesser-known syscalls, you can just make two files: One file is a blank local file owned by you, the other file is a symlink to the root-owned flag. Then in your while loop, you cp one of the two files into a third path, swapping back and forth between them. You would then call ./readflag on the third path.
I just realized it's an X-mas calendar. LOL
Get better man. Here comes the holidays abd family. :)
Gute Besserung
Cool
Would you be able to manually change the symlink if you set a breakpoint in the binary?
In a CTF context, the binary itself is owned by root, and executed as root (by setuid), so you can't debug it as regular user.
In the fixed variant it doesn't matter anyway. Open would dereference the symlink and get to the file, and then paths will have zero relevance.
Also don't try running gdb on setuid executables. Ain't working.
@@paulstelian97 I was talking about the non-fixed version. I just wanted to play around with it a bit.
@@user-qm4ev6jb7d hmm Yea. Didn't consider that. Thanks mate!
@@PinkDraconian ...the race itself with renameat does it as much justice as the breakpoint will do. And again, gdb on setuid is probably not fine.
@LiveOverflow, I noticed you did not close the file in readflag.c (before and after the refactor). Are you relying on cleanup to occur when the program exits? (I hope you feel well soon.)
Kernel is pretty good at cleaning up after processes which terminate and can easily deal with open file descriptors, allocated memory and other resources. Other than pedagogical, there’s no reason to worry about any of that in toy, non-production applications which terminate quickly.
Open file descriptors are closed when the program terminates. The only time where open file descriptors are not closed automatically and you need to close them is before an `exec()` system call: if you don't close them they are inherited by the program that you exec, if you didn't specify the option CLOSE_ON_EXEC when you opened the file (in which case they are closed).
And on a clone() / fork() call.
What about checking the inode of the file, can that be changed?
Apparantly with debugfs you can change the inode of a file, perhaps this can be used to still exploit the fstat trick?
At that point you can just ignore file permissions completely
@@TimLF Ooh ofcourse, debugfs requires root doesn't it?
How would you check an inode? To get inode of a file you need to use stat. You potentially could store (device id, inode) pair from the stat call and then do another fstat once the file is open to compare if you’ve opened the same file but at that point the first stat was pointless. Maybe it could make sense if the check and use happen at completely different times and places in the code so during the check you store the inode but even then it’d probably be easier to just open the file at check time and keep an open file descriptor.
@@mina86 I guess the point of this inquiry is more to understand what happens if you assign a different file to the same inode once a file descriptor was already created, does it keep using the inode to address the file and potentially address the different file, or does it use the original file? I know this is not a security vulnerability, because as Tim L pointed out, debugfs requires root privileges, but I'm just interested in the theory at this point.
How does renaming symlink gives you root permission? Not sure to understand this part. I either get file is owned by root or couldn't open file.
𝚒𝚏(𝚏𝚍
Don't worry about making it to 24 videos. Your health is more important than an arbitrary challenge.
With your program, you can read the files from all other non-root users even without the race condition.
Get well soon ☕
Handle points to data and it does not care of file name. It does not care to that point that you can delete file and still read data behind non - existing file
Couldn't we also just store the filepath locally and only use the locally stored string instead of directly calling argv[1]?
Would there be any problems doing it this way?
It doesn't matter because the argument (which is the file path) is staying the same anyways. It's the file the path is pointing to that is changing.
@@a544jh Ah I see, that is clever! Thanks for the help!
You did not understand the problem. The program asks the kernel "is the file ./flags owned by root?" when the kernel then says no, the program says "I want to open the file ./flags and read it", but in the meantime, the file ./flags was replaced by file owned by root.
There is no problem of someone changing argv[1], that should not be possible without root privileges. argv[1] always has the path ./flags stored.
I'm confused. If you can do the file renaming part, can't you just run cat on the file and read it?
Well... I tried to reproduce this procedure but without success. I'm using Arch Linux and I always get "Couldn't open /tmp/flag" or "File /tmp/flag is owned by root". What I am doing wrong? Thanks in advance.
Same.
I came here from THM.
couldn't you just rewrite the actual file at /tmp/hax/flag from being a text file to the symlink? I mean, there's no guarantee the file can't change on disk after open(), is there?
gws
6:21 Can't you switch the descriptor in /proc/$PID/fd/ ? Of course you need to have root access to change it and the exploit does not work.
If ‘/proc’ is mounted as procfs then you cannot change what ‘/proc/$pid/fd/$fd’ maps to even if you’re root. It’s always the file descriptor opened by $pid. As root you can mess around with mount points but then as you’ve pointed out, you’re already root.
24 Hex-cember videos, so you are doing 36 Videos for Dec-ember!!??
lol
The look during "it's a really awesome linux feature" talking about the "race-condition syscall" is priceless. That's basically the same telling someone about %n is a really awesome C feature :P
༼ つ ◕_◕ ༽つ ⚡ TAKE MY ENERGY ⚡ ༼ つ ◕_◕ ༽つ
Idk what this "rena meat" thing is but it sounds dangerous
Mmh but this means you can move a file owned by root around even if you are not root ?
If it is in a directory you have write access to, then yes. You can't read or write to it, but you can move and delete it.
i watched a few times and i understood the solution but i didnt understand the problem !!! what happens when you use the file path the 2nd time ??
You can have switched the files between the first and second use of the file path.
@@LiveOverflow oh thx i understand now !!!
Did I miss the part about renameat?
I think your white blood cells are giving you a race condition. Hope you nab your bugs. Love your vids
So theres absolutely no way to change a file descriptor to change where it points, its permanent??
Never suid.
The syscall is not the cause of the race condition here.
It is often necessary to rename or swap file path in legitimate programs.
This same race condition here can be achieve with just renaming two files separately to swap them.
The syscall used here just makes this quicker (making the example bug more likely to happen).
The example program is the one containing the race condition bug.
It first tests required permissions and then later reads some file with out any verifications that it is even the same file.
Just had to post this commend after reading some mislead commenters.
I didn’t say it’s the reason for race condition. I call it a race condition syscall because it’s beautiful perfect to exploit race conditions with it.
youtube rabit hole :)
The inconsistent curly braces irritate me lol.
@@da_frank C programmers use inconsistent braces within a single program? Is it a measurably worse problem in C than other languages? The C++ code that I work on has consistent braces.
are you sleeping well? so many videos so fast recently ... also that stubble
I'd love to like this channel, but I wouldn't... You put such beautiful themes, I want to see so much! But then, everything goes so fast and you start cutting parts of the video randomly? Can you start explaining a little more about the things you're doing? I'm studying cybersecurity, and I just want to do more and more, your topics are very good, but please start explaining in more detail what's happening, I'm really clueless
"File Path Race Condition" do you mean Time of check vs time of use (TOCTOU)?
do you mean watch the video?
@@LiveOverflow I like guessing what it will be about before I watch, it's like a mini exam questions~
seems I passed the course
The demonstration of the exploit is actually somewhat buggy. It does not necessarily show that the root file was opened via open just that the stat call was reading the meta data of the file that is not owned by root... it might very well happen that the stat *and* the open call target the same non-root file, i.e. the exploit kind of fails. Edit: this even happens in the video at around 6:44.
Of course. That’s not buggy. That’s just the nature and uncertainty of race conditions.
@@LiveOverflow My point is that you did not explain it at all. Only at the end you mention the contents of the files. Without that information the viewer cannot comprehend what's actually happening when you execute the program. Also, no, this is not just the nature of RCs but the way the "exploit" is designed. Practical file toctou implementations try to increase the probability of winning the races, e.g. by creating file system mazes.
stop making videos just take care of yourself
I only clicked cuz I've never been this early 🙄 dont even have time to watch this rn 🤣
stop worrying about the amount of videos you post and get some rest.
Your render settings are causing some serious colour banding 🙈
Huh where?
@@LiveOverflow It's most noticable when you're using VSCode - flickering at 0:16, but also the beginning of the video that has some overall brightness shifts due to the banding
But I don't get:
- Why would a file launched as a non root user be able to read a root file? Isn't that an insane vulnerability being able to read any file on the system simply by writing some c code?
- Why would you be able to rename a file not owned by you?
That’s setuid. Look through your system binaries. Many programs such as “sudo” or “ping” can be executrs by regular users but run as root. It’s a perfectly fine permission model. As long as these programs don’t have bugs like in this example.
I’m not renaming the file I don’t own. I rename the symlink I created. So I own that symlink
You can rename files owned by root as a normal user, when it is in a directory owned by you where you have write access to the directory. You can not read or write the file, but you can move it and delete it.
This video is...racist.
I want you to know that I lost my interest interest in this channel. What got me here were the CTF videos. I liked them, as they are easily understandable (for someone who likes programming, but not security/hacking related) and don't require me to fully know how that specific platform works.
Now you have shifted toward tutorials about specific exploits. While all of this is about hacking, what your viewers do with it is different.
I just wanted to let you know. Good luck with your channel which ever way you go!
Wat. I have started this channel on tutorials. Just last month I released a CTF video and todays video was inspired by a CTF challenge.
It’s always interesting to hear the completely skewed public perception versus the actual data.