Thanks for making this. Code analysis for exploits can seem super impenetrable especially for these old Unix utilities that feel like a fact of life. It's great to have stuff like this showing how you could find an exploit like this on your own. Especially I feel like it's pretty common to get to the point of crashing something and think "OK cool I crashed it, but now what do I do? How do I actually exploit this?", and the segment with GDB really helps with that.
I've done it, though not on Linux code (was part of a bug analysis for a program I was maintaining). Found a potential massive security hole by accident going through the code looking for something completely different. Luckily that piece of code had not yet been rolled out to any production server, and the patch was small and easy to deploy to the test servers it was already running on. Sometimes that's all it takes to find an exploit, sheer luck.
What's the point of kernel vulnerabilities when your whole CPU is a backdoor for the NSA XD. Meltdown and Scepter are just the tip of the iceberg of what type of vulnerabilities are hidden in our CPU's, South and North bridges, NIC's and other hardware.
@@gmdzbanwic Exactly. I don't know what the fear is lmao. NSA won't just randomly select people to investigate. It's a waste of resources. Unless you are doing some really suspicious stuff, NSA shouldn't investigate you. And even then, nothing will happen if you did nothing. "Which owes nothing fears nothing". Or maybe they do idk I don't work at NSA, seems dumb to me though.
@@Perseagatuna yet they did mass surveillance as evident by Snowden. Moreover if they save everything, they’ll be able to look through it later to retroactively find something that you might not want to be public.
totally unrelated. but I've smashed my head against the wall trying to do setup for a process that would run as its own user and spent hours not getting it to run right only to break down and do it with su. this vid answered so many questions for me that I didnt show up trying to answer.
This is so interesting! It really doesn't look that complicated tbh. Step 1: find a vulnerable function for buffer overflow Step 2: find a way to access that function in a vulnerable state Step 3: find a place to overwrite that could cause arbitrary code execution Fascinating!
As always, great video. I think you may have overstated the difficulty of setting up afl to fuzz commandline input though. It's a super common thing to do if you fuzz a lot. What I'm partially saying is that it's inexcusable that no one has fuzzed it before. Commandline programs are fuzzed all the time and with afl at that!
what i find amazing is how this eventually got discovered because normally i think such vulnerabilities get discovered accidently for example someone tries to head or tail a file for example and since head and tail displays the first or last part of a file if the file is a binary maybe the system interprets the head or tail output wrongly and not realizing it they have set a memory value and maybe the next time they do something that requires sudo or maybe sudo does not ask for the password or the command is done as if they did sudo. so the only way i can think of is someone decompiled the sudo binary and looked at the code and saw a piece of assembly code that did not look right maybe a jump or copy command and decided to throw stuff at it and got it to work.
Still.... Every person who has ever used or developed a fuzzer is kicking themselves right now for now realizing this bug. (-s) ?? Wow that blew my mind. That's all you gotta do? -s and a trailing backslash... 😲
It's Baron Samedit as a play on the name Baron Samedi from Haitian Vodou (Voodoo). He is also a prominent character in the James Bond film Live and Let Die. en.wikipedia.org/wiki/Baron_Samedi Naming it "pwnedit" wouldn't work for this reference.
Thank you for the tutorial, clear as always. I am trying to replicate the CVE in a Docker container, however, when I run sudoedit -s 'AAAAAAAAAAAA\' I get vim opened. I cannot understand why. Could you please help me? I am running Ubuntu 18.04 and. sudo1.9.5p1 (the version before the patch)
kudos liveoverflow! this channel is a goldmine!!...i bet another hacker is there, after watching liveoverflow, is now crafting a mac exploit....Apple is giving decent bounty for serious exploits....
I feel like that argv solution you gave for Fuzz was WAAAAAAY overcomplicated... Why would you not just write a quick shell script that reads fuzz from stdin to a file, so that you can pass the `cat` of that file as an arg??
My guess: allocating a variable length buffer is often for strings. Strings lengths need to be adjusted for the \0 byte at the end, not doing that is a traditional security problem. Here this is not needed, so the programmer used an adjustment of +0 as documentation for 'I thought about adjusting, no error here'.
I love your videos, however I feel you kinda diminish a lot the achievement of the guys that found the exploit by saying things like "it's luck", or "I could almost have find it" etc
Doas is the better one anyway, sudo is full of redundant features that a regular user won't use anyway. You could warrant it's use in some server / production environment, with many people having different privileges.
I fully switched to doas because of this vulnerability. I use Duncaen's port OpenDoas entirely because he sounds smart and won a flamewar with a different port dev
Already well over 20 years ago I aliased please to sudo. Mainly for self-protection: on a university server sudo would notify system administrators that a student (me) 'accidently' tried sudo. And I was logged into my own linux machine an the uni system in two windows that looked very much the same. At uni, please told me politely that I shouldnt use that. At home, please would do sudo XD
ahh yesI remember this one. I was on the toilet reading my google feed, coming across an article mentioning it. Aftwards I'd hit sudo apt update and there was an update ready for the sudo program already. I had only updated about 3-4 hours ago, so I was amazed the patch followed me reading the article so quickly :D
Great walkthrough and analysis!! I really appreciate the care you took in explaining this from discovery and going slowly into the analysis for an infosec noob like myself 👍
Kind of got guilt tripped into watching this video but I am SO GLAD I did. There's so much content on CTF's and basic content and I think it's a struggle going from guaranteed exploitable challenges to real world, humongous code bases looking for bugs that could or could not be there. The idea of taking a CVE and trying to go from step 0 to 0 day is perfect, genius even. I can't wait for your new videos and will definitely be looking for a CVE to research myself. You've definitely outdone yourself this time! Thanks so much!!!
This was very informative. Consider doing a video like this in a way that it could be presented to an non-c/c++ developer. I'd love to present this video to my coworkers. While I understand c/c++, our development is java and .net and i would need to explain ASLR and heaps and the other hard core tech stuff. However, I think they would benefit from knowing the lengths to which hackers can go to exploit something like this and that tools like AFL can be used for good or evil.
It's hard to explain it because Java doesn't use pointers, so for the most part if you're using Java, buffer overflows won't happen, at least unless there's a bug in the virtual machine code you're running on. Java won't let you read/write past the bounds of a string in your actual code, so bugs like this really can't happen there. Really this stuff is mostly a C/C++ thing, because those languages have very unsafe string implementations.
Pretty much the reason doas was made, the complexity of sudo has (as with most software) been known to introduce bugs and exploits. Real problem with sudo is that its never really been very unix in philosophy, "Do one thing, and do it very well." Sudo really shouldn't have been given control over the kernel/userspace permissions itself honestly in first place, (and as it stands it does so many things that it could be handled separately that you can't honestly call it unix) optimally it would only and purely elevate a process to another user, default being the admin (or root) user.
This is a genius series idea - I have wanted to see something like this for a long time. The high level stuff is great, but a more in depth version would be good - one where you actually work through the steps, how you're figuring out getting past the various challenges. That might be more work, so maybe a patreon feature? If you want to take it further, maybe try going after allocated but undisclosed CVEs that have been patched. Covering how to attack unknown exploits via source diffing (or binary diffing) would be amazing.
I suspected this kind of deep-dive takes ages to produce. The two weeks of research on the KNOWN bug, I am not even surprised! ;) I don't even want to know how many decades would it take for me to discover the vulnerability in the first place! ;) Thanks for the great video! 11/10 - will watch it again! (note the integer overflow) ;)
For Mac, I don't have "sudoedit" by default, so wouldn't that bypass the whole thought about trying to run this on Mac? I thought we needed sudoedit in order to get in that interesting sudo 'mode' to be exploited? At 18:10 we see the use of "/tmp/sudoedit" meaning the attacker would need to have an already compromised system, and be able to write a file in /tmp/ to attempt privilege escalation. At that point, there are easier ways, like writing a malicious python script in /tmp/ and gaining privileges from that, right? This just doesn't seem to be worth the squeeze on Mac. So feasibility on a Mac: very very improbable I do see a "/usr/sbin/visudo" Mach-O binary on my Mac. Perhaps that would be a better place to start looking for a more realistic approach.
