Kernel Root Exploit via a ptrace() and execve() Race Condition

Let's have a look at a recent kernel local privilege escalation exploit!
Exploit Source: hxp.io/blog/79/hxp-CTF-2020-w...
Kernel Developer Walkthrough: • SerenityOS exploit ana...
Syscalls, Kernel vs. User Mode and Linux Kernel Source Code: • Syscalls, Kernel vs. U...
How Do Linux Kernel Drivers Work? • How Do Linux Kernel Dr...
👕 T-Shirt Series: • My Life in Short/Shirt...
00:00 - Introduction
00:15 - Exploit PoC
00:39 - main()
00:52 - prepare_shellcode()
02:39 - mmap() shared memory to signal "ready" state
03:07 - fork() into [child] and [parent]
03:44 - [parent] wait for the child
04:00 - [child] unveil() loop
05:03 - [parent] ptrace ATTACH and POKE child
05:58 - [child] execve("passwd")
06:38 - [parent] PEEK entrypoint of child in loop
07:34 - [parent] child entrypoint changes!
07:49 - Exploit Walkthrough
09:20 - Root Shell via Shellcode
10:10 - Vulnerability Summary
10:37 - Which UNIX-like Kernel is this?
12:44 - The importance for Security Research
13:59 - Next Video and Resources
14:22 - Patreon and YT Members
=[ ❤️ 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.

[@esertekin9727]

movie hackers: I have 6 screen 3 keybord, 4 mouse and I can read binary just by looking into it. real hackers:pen and paper

[@flp322]

Facts

[@OskarNendes]

best paper is no paper, brain paper

[@werren894]

yea but they paper is more minimalistic than programmer so essentially, movies actually tell the truth

[@No-jz1jk]

@@Ormaaj you speaking from experience? Because you seem like you actually are one, no offense.

[@No-jz1jk]

@@Ormaaj bad or good hacker, or something in between?

[@awesomekling]

Oh man, I loved this video! The explanations, the visuals, all just great! :) Thanks for shining a light on our little project.

[@Shamouth]

Linux kernel is vulnerable too! Or was... the same race condition was discovered almost 20 years ago. CVE-2001-0317 :) The exploit that was released then, used exactly the same approch, using "passwd" as a setuid child. That make me think the idea is not so new, but still worth keeping in mind!

[@arijitkumarhaldar3197]

I am a beginner in Linux..and I found something useful about passwd too. So, I was gifted a Beaglebone black by someone which had Debian 9 flashed. Who used it earlier had forgot the password for both "root" and "debian" users. Without knowing the passwords, I was able to get in the terminal using Cloud9 IDE, and reset password for both users and then login using ssh. I don't know if it could be called a vulnerability...but...should such an access be allowed ?

[@ThiesBroetje]

@@arijitkumarhaldar3197 that’s a big no no. Your web-IDE should never ever be running with root privileges

[@arijitkumarhaldar3197]

@@ThiesBroetje Then I'll check what the new BBB's do under the same condition. Thanks 😌

[@tacokoneko]

@@arijitkumarhaldar3197 i heavily use my beaglebone black and i immediately panicked when you said that and began mashing all its ip addresses into my browser. 502 bad gateway. 502 bad gateway. whew that was close, i disabled all the services like nginx except those i actually use just to be sure.

[@arijitkumarhaldar3197]

@@tacokoneko Seems the issue is fixed in the new Buster image. I had the Jessie installed back then. Yet, glad I could be of any help in securing your network. Could you let me know if the same issue is reproducible on your end too? I guess it only happens when you connect the beaglebone physically with a USB cable and then open the Cloud9 IDE at the default port that is setup for practicing the basic codes. I was a complete noob back then..hehe. Blocking everything except the SSH port is the safest, I guess. I primarily SSH into it now.

[@cyber1377]

The way you simplify these things is amazing, I got interested in this stuff originally watching your binexp playlist and can honestly say its the best resource for beginners, never change :)

[@drac.96]

I feel like liveOverflow videos are becoming more and mainstream. Really good!

[@nicodomino6713]

What!? Was the t-shirt "advents" series really not that well liked? I find that hard to believe, I really loved it! Thanks for putting yourself out there and telling the stories behind each shirt!

[@simonfarre4907]

I love the energy of this guy. Unfortunately on KZbin, everybody is an expert, and by that logic they can think their understanding of the world is flawless - even if some of the people online are really smart, their narrow minded approach to how things should be done is counterproductive. The approach of this guy to talking about computer science-y stuff, is incredibly appealing. Definitely subbing.

[@danihp9238]

This videos about operating systems are simply awesome man, keep going

[@zyansheep]

One of the first live overflow videos I've watched in awhile... great video!

[@zaspanyflegmatyk2446]

That's some quality content right here! Please do more!!!

[@kanskejonasidag1]

This was such a great video. The explanation itself was great, but not only that, the production and editing was great! Clear and beautiful. Keep it up.

[@nikoshalk]

Awesome! Can't wait for the kernel follow-up video!

[@bertrandfossung1216]

It's always awesome working on a Unix kernel. What caught my attention the most is the exploit. Thanks very much for sharing this video👍

[@bpbrainiak]

Thanks! This kind of videos wakes my curiosity thanks a lot :)

[@somehow_sane]

That is one awesome Exploit! Also I love the new setup!

[@vin-goldi]

Don't get discouraged by peoples talking bad about the T-Shirt series. I like it!

[@kangalio]

This is a fantastic video. Explained a complex, super interesting topic, in an understandable no fuss way

[@mitja5980]

very interesting topic! I think its really sad that your december project got some negative response. For me it was very interesting and I also saw other people in the comments liking it very much! Keep up :-)

[@r.pizzamonkey7379]

3 seconds in: "#define ass"

[@lyr7d1h41]

Really cool that you've actually checked out serenity OS!

[@AnkitDasOfficial]

Wow, this exploit is awesome! your video made me understand every bit of the exploit, Thank you!

[@dsmithprogrammer]

That was fun and interesting to watch ☺️

[@mechjack]

Leveraging knowledge across platforms AND DISCIPLINES! Awesome!

[@tastyrobot9369]

Yes yes ofc Ahh yes that makes sense. Yep that's right.

[@AnonYmous-spyonmepls]

to be fair if he explained everything this would be a 20 hour video

[@rajnhard]

Gf : tell me beautiful things... Me : LiveOverflow just released a new video Gf : I am yours

[@greob]

Very interesting stuff, thank you!

[@peepeefrog_]

I actually understood most of it. Great explanation!

[@swizzlatheone4081]

One ofbthe best exploiting videos i have ever seen... you deserved the bell 😀

[@b1rds_arent_real]

You've found the most mature, prod-ready name for an assert macro

[@NetworkITguy]

Thank you for actually doing awesome content. vielen dank

[@kevinwydler4405]

Thank you! This was really interesting!

[@nstepsforward865]

That was awesome, great and rich content my man, congrats from Brazil, south america.

[@mohammedzaid6634]

can't wait for the next video!!!

[@hamidcrazy9027]

I'm glad I finally have the knowledge to understand this, really a great idea

[@rujotheone]

Any tutorials you could point me to catch up? I have some C knowledge but I got lost later

[@hamidcrazy9027]

@@rujotheone can you point where you got lost exactly ? So I can suggest something specific or I can explain it to you, because there are few topics here, C programing which is not that needed to understand what's going on here, ptrace(), shellcoding, race conditions and other stuff

[@rujotheone]

@@hamidcrazy9027 ptrace() and his explanation of the race condition but his next video made it clearer. I wouldn't mind any other stuff you have. Thanks

[@hamidcrazy9027]

@@rujotheone ptrace() is a system call used for debugging, it lets you examine memory of another program, change it, change registers value etc etc, it's what used by debuggers to control other programs, to understand it more you might wanna read its manual page, a brief explanation of what happened here would be that he wrote a known value to the entry point of an suid program (0xcccccccc), and tried to load that program, and he kept the checking if that value changed or not, meaning if the program wa loaded yet, the moment it loaded he copied the the shellcode wich spawns a shell to that entry causing the OS to execute that shellcode with elevated privileges, same thing is done for stuff like process hijacking in linux, you attach your self to a process using ptrace(), then write your shellcode to the next instruction that will be used by the cpu, an example would be [this](www.real0day.com/hacking-tutorials/2017/11/6/injecting-a-running-process-linux) (without the setuid race condition of course), for more info about race conditions watch [this video by liveoverflow](kzbin.info/www/bejne/a5iUZGqdqKdsjc0) or just google it, lemme know if anything is still unclear

[@rujotheone]

@@hamidcrazy9027 thank you. That is clear enough. I had known about race conditions but never really studied the mechanics of an exploit. It is interesting how one can manipulate computer time to your own advantage with large data

[@weinihao3632]

It would be interesting to know how this vulnerability was found. Was it likely found by a detailed study of the kernel source code or by some (educated) guesswork (maybe having a rough idea like ptrace & setuid execve and then fuzzing the interface to the kernel running in an emulator for the details to discover a race condition)?

[@peterarbeitsloser7819]

That would be really interesting!

[@catlord69]

agree

[@c1ph3rpunk]

I’ll take “complete accident while working on something else” for $1.

[@Shamouth]

100% sure it was found by some dinosaur, which remember about the same vulnerability in the linux kernel, 20 years ago...

[@akashbr7181]

Nice explanation👍👍

[@Epinardscaramel]

Very interesting, thank you!

[@teefhennessy]

Just explanation is hard for me to understand but what's even more mind blowing for me is how someone discovered it.

[@BlackHermit]

Serenity! My childhood's silver coins come back to life! :)

[@albertb4460]

Pls do a video on the solution they implement, your explanations are very interesting!

[@aartavazd]

Yeeesssssssssssssssss this is FANTASTICALLY COOL, awesome this is what I call smart brain. very good explanation.

[@technovikingsnephew8833]

Great video as always!

[@mactalk2871]

awesome video! Could you make a video about fuzzing? Its something I'm really interested in, and I want to know your take on it. Keep up this great work!

[@BGroothedde]

Amazing exploit, clever discovery too holy shit!

[@dayumnson9769]

The shirt series are great :)

[@lafayetzhou8902]

Thanks for your sharing

[@padwan1000]

Hi man, your videos are great. I have gained a big notion about your content. I was always very curious and enjoy understanding/learning how things work in your essence. I always like programming/electronics and I have decided truly to learn about C programming and Reversing Engineering but has so much trash and not so good content mainly for beginners and I get lost when searching for really good content, could you recommend a good C book and on-line content about C and reversing engineering besides yours? If you do can help me a lot. Thanks and again, great content.

[@CyberKing7]

Thanks you share this

[@johannespain7855]

Great Video :)

[@andreavergani7414]

Thank for your video. They are inspiring me into ethical hacking. Ciao grazie

[@strangedude9008]

after 3 hrs of this video released we already have 5 dull people that thought it is some kind of giveaway of "pwn anyone in a minute or less free download torrent no ads"

[@olso8621]

amazing video

[@Th31nf1d31]

Everytime I think I really could be a penetration tester, what a cool job, I watch your videos and realise I understand nothing and probably never will. This is not a reflection of how well you explain these things and more a limit in my intelligence I think...

[@tartas1995]

i love this video.

[@JanWestin]

Great content!

[@theopbro8691]

Cool!!

[@tg7943]

Algo push!

[@sankarghosh172]

Super 1 👌👌

[@treydelbonis4028]

I actually was reading the exec impl in Linux about a year ago when I was trying to learn how arguments are passed to the new process. Linux creates a new virtual memory space loads the new program and other data into that and then swaps out the process's memory table with the new one in a single step. I don't remember the specifics but I'm sure there's some extra bits in there to ensure that a ptrace gets closed if there is one on the process when it execs.

[@TheVertical92]

I didnt understand much of the C code, but it was very interesting. And it motivates me to learn more about C (i like the language anyway).

[@anonymanonym9004]

C is quite easy imo

[@TheVertical92]

@@anonymanonym9004 Well yeah kind of. What i meant was learning how to use C. The language itself is somewhat easy to learn. But you have to know more than just the language to really use its potential. Like knowing how Operating Systems work, how the Hardware works, etc.

[@anupamjaiswal7714]

11:25 was op😂

[@goldibollocks]

I feel kinda nerdy (but also good) for assuming this was about a Linux exploit initially but still thinking „wait... Linux has unveil??“ when that was mentioned 😁

[@airxperimentboom]

So geil

[@toreshimada]

Like your yeard!

[@0-h031]

Imagine being able to come up with this stuff

[@anonanon3066]

Nobody: This channel: Video 1: what is a byte? Video 2: how to exploit a race condition using a byte array containing executable code by overwriting a root process

[@spfab3429]

I have a question: Which use had the unveil calls? Where they just there to delay something in the exec system call or the passwd programm? You explained what the unveil was, but never why it is there in the first place.

[@Drysart]

My educated guess is the kernel has to do some work to clean up the unveils before it kicks off execution of the setuid binary at its entry point; and that work is what adds the extra time necessary for the parent process to detect the entry point change and inject their own code. Or, in other words, the kernel is probably doing these steps in order when execve is called: 1. Stop execution of the current binary 2. Load up the new binary in the address space 3. Clean up kernel state from the previous binary's execution (e.g., undoing all those unveil calls) 4. Detach any connected ptrace users (probably just another step of 'cleanup kernel state', but it's done *after* cleaning up the unveils) 5. Jump to the entry point of the new binary The race is to get in between steps 2 and 4, and that's assisted by making step 3 take an extra long time.

[@michael-nef]

Maybe I missed something obvious, but why did we need to create all those temp files to complete the exploit? My understanding is that the exploit goes like: 1. Run parent (evil process) 2. Parent forks to create a child 3. Parent constantly checks the child's entrypoint address 4. The moment the child execves the entrypoint is overwritten by the passwd program image 5. The parent detects this and super quickly overwrites the entrypoint code with some shellcode to execute with root privs. Nowhere in my understanding the weird "make tons of temp files" comes into play, could someone clarify why we had to do that. Thanks for another good video :)

[@gabiold]

I don't know, but my guess it is to do something to enlarge the time window to have a chance to overwrite the code.

[@seths1997]

wow peek and poke...not a developer but remember using peek and poke for reading/writing memory locations in Commodore basic decades ago

[@in70x]

This is a great explanation. I might have missed it but what was the exploit trying to achieve with creating and unveiling all the tmp files? Was it simply trying to exhaust kernel resources needed to cause the race?

[@typedeaf]

Bump edit: explained in another video. the race condition between loading the progam and changing the uid has a function that clears veiled pathts in between.

[@JoeTaber]

The whole idea of fork and exec simply replacing an existing process in-place while implicitly inheriting every byte of crap the previous process left around and all its processes properties like fds and attached debuggers is insane to me. In a standard that also specifies the concept of setuid.....

[@soveu8237]

nice moustache oh and good explanation

[@anonymanonym9004]

Nice owl Oh and good comment

[@HackingIsDope]

3:57 BURN 🔥🔥

[@filipenicoli_]

I really liked the stories behind the T-shirts! Btw, how is unveil() related to the rest of the exploit? I hope you explain on the next video. Thank you for the good content!

[@neumdeneuer1890]

Good question

[@TimLF]

I'd wager it slows down the exec call to give more time to the race condition to swap the code before it's run.

[@filipenicoli_]

@@TimLF But this happens during the synchronous part of the exploit. My guess is that maybe it forces some strange state inside the kernel.

[@fangzhang9376]

@@LittleLily_ As the hxp write-up says, the kernel actually _cleans up_ the unveiled paths during the time window that is being exploited.

[@arminsmajlagic2907]

To understand that piece of software and everything relevant to it...you have to be prety darn good

[@SlyEcho]

lol, i though the user 'courage' looked familiar

[@dianpratama2003]

The magic is on the :break

[@zCri]

dark theme lets go

[@pitust]

Oh good, i though i have to worry about this in my OS but i mean the userland can just ask for any page in memory (anywhere) and get it mapped to its virtual memory area. No UIDs. No KASLR too (physical or virtual). But i am safe - all binaries are stowed into the image build time.

[@osamazaid25]

LiverOverflow is the ultimate scriptkiddie to security researcher converter

[@GIJOEG36]

We should come up with a set of standard testcases that every kernel dev could use

[@andreiromila8129]

I just spent the whole 2020 studying get a certification in script kidding.

[@alerey4363]

Reminds me of 6510 assembly poked from BASIC to crack games

[@motbus3]

hey LO could you revisit recommendations for security study?

[@ciberman]

How do you do the visuals of your videos? I mean, they are awesome

[@LiveOverflow]

You can find some making of videos

[@ciberman]

@@LiveOverflow I just saw it. You are amazing man! Keep up the good work!! :D

[@ahmedkhaldi2057]

Hi my best teacher

[@Aziqfajar]

I am not even in this field, but does 7:48 is the part of the code (I'll assume that the code is about when the address we're looking for is not in the provided range, thus finding the right address for it) is the part we are exploiting?

[@Wyvernnnn]

Beard is cool

[@renanamd.d9485]

Noice video

[@headcheese3]

Michae Cera teaches us computer exploits

[@kangalio]

Lol biggest plot twist ever with the OS reveal

[@safwanljd]

My mind literally blew up

[@anonymanonym9004]

Literally? Sorry man :( hope you survived it

[@mohammedjawahri5726]

I understand the basic idea of exploiting the race condition and grabbing that opportunnity once the binary is loaded into memory to execve sh instead (while the kernel granted u root privileges to use setid). but I seem to miss what is ptrace doing for us exactly again?

[@sokrates297]

en.wikipedia.org/wiki/Ptrace#:~:text=ptrace%20is%20a%20system%20call,internal%20state%20of%20its%20target.

[@Rodrigo-xf2oe]

It is detecting when the passwd code start to being loaded, and is modifying it by writing the payload.

[@renakunisaki]

ptrace is how the parent process is able to change the code in passwd at all.

[@alonzy989]

do you happen to know about the ptrace traceme LPE in linux? its from 2019 and very recent

[@matzibeater]

I feel like race conditions are the new buffer overflows, they just keep popping up everywhere, even in very modern systems. Or maybe especially in modern systems, because they need to rely on multithreading more and more. I felt like there was a fairly recent race condition root exploit in the Linux kernel but I can't seem to find any sources for it atm. The best I could find so far was CVE-2020-15702 for Ubuntu, not exactly what I had in mind but maybe I'm just misremembering. Anyways, I think we'll see many more exploits like this, aswell as use-after-free race conditions in the coming years. Fortunately, the kernel devs are not against adding Rust code in the future, which should bring some safety guarantees, and Microsoft has said similar things about Windows once Rust has better C++ interop.

[@nagitokomaeda3237]

Ah, another terminus user. Cultured.

[@martino6172]

Actually ptrace exploit is something which should be not possible in 2020 cuz it was a thing around 15-20 years ago ptrace was exploited and after it every security researcher till today looking for holes in it. You should check historical ptrace exploit it was doom day of the servers and internet “openssl-too-open”, OpenSSL 443 port remote exploit to almost every server to get user privilages and in same time local ptrace() exploit was a dream team.

[@ThisIsTheInternet]

So I guess Serenity doesn't have ASLR/PIE? If it did, another exploit to get around those would have been required and made this more complicated, right?

[@David-yr3xd]

it wouldn't be a big problem in practice. At least on linux, there's only 19 bits of ASLR giving a total of 2^19 different memory layout possibilities. On average you'd have a success rate of about 1 in 2^18 -> 1 in 262144 tries. Since you can just repeat the fork() trick you'd have a root shell within an hour.

[@David-yr3xd]

depending on your race window you can PTRACE_POKE at multiple page offsets as well which would reduce the amount of total tries needed. You might(?) be able to only write int3 instructions instead of the entire shellcode which would in turn make it possible to perform more writes per process.

[@awesomekling]

It does have PIE, but before this vulnerability was found, we didn't randomize the location of the dynamic loader in new processes. It was always loaded at the same exact address (oopsie!) The whole system is a work in progress, and we're improving as fast as we can :)

[@1Hippo]

@@David-yr3xd That is for 32 bit Linux, right? For 64 bit the ASLR entropy is effectively 28 bit as far as I am aware.

[@David-yr3xd]

@@1Hippo Seems like you are right. This does complicate the situation, but I think it would be possible regardless, especially when permitted multiple writes at different page offsets for a single "try".

[@fangzhang9376]

Nitpick: I believe unveil() doesn't block access to the specified files, but instead blocks access to the entire file system *except* to those specified files. A "final" call to unveil() with null pointers as both argument is supposed to happen in order to prevent further unveil() calls from gaining access to new files.

[@in70x]

I am not sure why the creation of /tmp/files and the unviels() were relevant to the exploit what am I missing? Is he just trying to tie up kernel resources for the race windows to increase?

[@fangzhang9376]

@@in70x 14:15

[@in70x]

@@fangzhang9376 Ah yup. As I imagined.

[@issaloubani5583]