I'll never forget the first time I saw Code Red in our lab. I had a FreeBSD server that I used for various things which was running apache. I came into the lab one morning and saw there were these strange errors in the system logs. I called the IT department and advised them of what I was seeing and I was basically told to get lost - I was a contractor at the time. I escalated this to my boss who escalated it to his boss then all shit hit the fan. Fun times. BTW, this was in a giant healthcare organisation with a presence across the globe.
Good video, clear explanation. As a mainframe assembler programmer from the 80s I was surprised by the C functions that made assumptions around 'looking for' e.g. a 'string terminating character' and not insisting on somewhat more control over what you were doing. Later when using C myself I discovered how easy it could be to get in a mess. Definitely a good and well-presented video, thank you. While I was already very familiar with the exploit (I've been in cyber security >15 years) this was a smooth and clear description. The more people aware of these elementary exploits the better.
Thanks for the kind words! If you have any cool language experience that would apply to our Primes project, please check it out on Github! I'd love to see a System/360 assembler version that we can run in an emulator!
The standard C library has some issues with these unchecked string buffer access and the varying convention of putting source or target as first argument. Long time ago I had to solve mysterious crashes in an application and it had these unsafe string buffer access all over the place. Any serious programmer would have made a safe string struct wrapper or use C++.
Me too. Moving from 1990s MVS/ESA to x86 I was shocked at the amount of blind trust placed in other code and the incoming data. gets() is the classic example--ouch! I ended up writing my own functions for almost everything, and then my own compiler (long story). I like the idea of trying primes on S/360. For anyone unaware, the "TK4-" Hercules install with MVS 3.8 is literally TurnKey.
I began in Unit Record Equipment, 407s etc then moved to 1401, 360, 370, 4300 series, then S390. I have written millions of lines of code in mainframe assembler and even some micro code on a 360/30. I built my own microcomputer utilizing IBM Op codes and EBCDIC so i could test my code before getting valuable actual machine time to test. Once I got my code running on the mainframe I crashed the program by implementing an invalid Op code from the front panel. I got a core dump, then corrected my source code to reflect proper operation. I then was fascinated by the Intel 8080 and built another machine using this and the S-100 bus where I could obtain I/o cards etc. I made my own front panel as well. The whole stack pointer and very limited registers left me puzzled as to why they didnt adopt tried and true technology of IBM. I trained COBOL programmers how to read core dumps as well. And even got COBOL to dynamically call other COBOL programs. Something that IBM said could never be done. I also got mainframes to talk to another using the 3270 protocol, again something IBM said was not possible (later they developed Bisynchronis Pass Thru or BPT) this allowed applications to talk to another application directly using STD COBOL under CICS. I LOVE mainframe assembly programming and consider INTELs x86 model a toy that wants to play in a grown up world . What i could do in 32k of memory could not even be dreamed of in C or C++
@@rty1955 Sounds as though you had some fun over the years! From my POV, x86 suffers from compatibility going all the way back to its roots with the 4-bit 4004. x64 is a lot cleaner, and if we can just exterminate every null-terminated string I'll be happy :-)
As an admin, during this time, I remember people freaking out when this happened. Within the government space almost nothing was properly patched, so it is a small miracle that Code Red wasn't worse. As for patching, Microsoft's buggy patches were as much to blame as the worm itself. When a new critical patch came out, the game of chicken started. From Tuesday through the Weekend you would watch newsgroups and forums to see if this patch would take down your servers. If you were lucky you had a bare metal server clone you could test the patch on and see if it broke your company software. This was the era where being an admin meant you not only managed the servers, but you wrote the business software and managed the database.... full stack started at bare metal back then.
in reality Microsoft patches are still rather buggy and the only patches i ever ran while using windows were security. any other patches went by the wayside until a week after and sometimes more to make sure they didn't break shit.
@@KaziiTheAvali_inactive Currently a sysadmin, and can confirm we do updates on the FIRST Tuesday of each month, 1 week before patch Tuesday. This is to make sure the updates have had about 3 weeks to get all their shit re-patched with OOB updates.
You should research the old Burroughs MCP tagged memory implementation and none of this would not happened. Your C program would have gotten a run time Segmented Array error as soon as the buffer length was exceeded and the program killed.
I have been really enjoying your channel. The last 96 seconds of this video are gold, I like that you don't take yourself so serious and are able to show the outtakes. Keep up the good work. Story 10/10 would recommend.
Well this certainly brings back some memories! I've worked in the field since 1995 (currently at MS as a digital forensics investigator.) I recently found your channel and really enjoy it. I run a security-focused channel and I can certainly appreciate the amount of time you put into making this content, especially with the high production value.
Glad you like them! If you've ideas for other topics, please do share, as I enjoy doing them! The bloopers are hit or miss, depends how it went that day, so sometimes I don't include them!
Love the direction you're headed with these types of videos, Dave! Might be a fun time to pivot to ROP-based exploits if you have any examples you think would be worthy enough to cover. :)
I bet a LOT of Unix admins got very used to processing the DEFAULT.IDA requests out of their logs! Of course I guess even the properly patched Windows guys would too.
Was this the one which tried to scan a specific port? I remember checking the addresses showing up in my firewall log for the backdoor. I could use 2 or 3 of those (i got a lot more entries in the log). I placed a readme file in their rootdir about the backdoor.
I was in University at the time, and we were all called in for the weekend, which we spent scanning the network looking for people running web servers and then making sure they were patched. In several cases, this meant breaking into offices which had somehow been re-keyed to not use the building master that we were issued as admin staff. Good times.
This is by far the best explanation of how buffer overruns work. When I first encountered such things, I felt it was a bit of "black magic", until I saw the updated source that fixes such things. It took me a great while to understand the details because the patch was only explained in terms of the fix: to perform bounds checking on a buffer. Obviously the reason for such vagueness is to prevent exploits from spewing everywhere. Thanks for the deep-dive into how all this works....and, hopefully as you said, people will "not use their powers for evil" ;).
Hitting up a 7-11 at 2AM to resupply with Code Red. Made mention to the clerk the stuff seems a bit on the addictive side. He mentions he goes through a case every few days. My health tanked shortly thereafter.
Most content creators who discuss this stuff would have said '...the stack is more complicated that this for several reasons', ending there and moving on. You, on the other hand, have just made me a very happy man. As soon as I heard 'Firstly,...' I knew you were going to detail why its more complicated which is exactly why I am now subscribed. Love to learn and you're a great teacher and story teller!
Yours is the only channel for which I consistently leave a like. I like the way you honestly express your motivation and then include a simple please. Also I literally like almost all of your videos.
I'm not a developer, coder or anything related to IT except I look after my own business systems and have coded in the past and am old enough to have been around for most of these stories :-) You're easy to listen to Dave, I enjoy the background.
I missed this when it came out. This was a really good explanation of the buffer overflow exploit. My software experience is limited (I'm mostly a hardware guy) but I programmed in assembler and BCPL in the 80s and a little C in the 90s. I understood pretty much all of this. Thank you.
I really like your videos like this where you tell a story and explain how something happened. I especially like the ones where you track down inside information of what was actually said or done by the people that said or did it. It's a extra bonus when examples, such as the buffer overflow demonstration, are presented like this video.
My God. I discovered this series by accident and I’m glad I did. I haven’t written a line of code for a couple of decades but this sure takes me back to my roots (pun intended). I was, at one time, quite proficient in C/C++ and assembler. There was a time when we had no choice but to write and maintain our own drivers for new hardware on some platforms. I go back to the time when all our programs had to be written in 32K overlays and manually swapped to execute. I’m fascinated by the idea that techniques I used back in the day will still work 30 years later.
Wow, was just thinking of researching something along these lines. Thanks, Dave! Now i can properly enjoy my Friday evening. Let me grab a cold one, Cheers!
Fascinating. Thank you Dave! Back in the days before file storage services like OneDrive, Dropbox, Google Drive etc. I used the IIS function of my home PC to save files from my work laptop as I traveled. I had a static IP on an early DSL line, so it was pretty convenient. Somehow; someone managed to get my IIS password. They didn't install malware, but they did uploaded several massive password-protected RAR archives which were subsequently downloaded many times, using all the bandwidth of the connection. I still don't know how they got into the server, but it was frustrating. I never figured out the contents of the archives, but I expect they were pirated movies or pirated software of some type.
Your blooper reel on this one makes me feel extremely seen; I don't Make Videos or anything but the way I talk to myself anytime I'm alone while I'm just doing whatever is a LOT like that, lol. Been really enjoying your channel & learning some interesting stuff as well! Thanks for sharing such a cool assortment of information here :3
I enjoyed watching your bloopers at the end of the video and presenting them in B&W was an extra nice touch. I hope you'll consider doing this in all of your new videos too
Your code was a concise and perfect example of what can happen with a buffer overflow. It brought back early-90s memories of unintentional buffer overflows, when my code would cause my DOS machine to beep (ASCII 07, I believe) and display blinking characters. Ah, the good old days. :)
Dave, I love your podcasts and most importantly your edits at the end! I laugh at each edit and wonder how you ever geta podcast completed! Keep it up!
This is such a fantastic video, both entertaining and educational. I work mostly with embedded systems which lack a lot of the protections a full blown OS and a lot of static analysis tools provide. More and more embedded systems are being connected to the internet each day and I think we will see them experience many of the exploits that have been protected against, on servers and desktops decades ago. It's videos like these I share with many embedded Devs to hopefully help them understand and protect their code against attacks like this while maintaining lean code bases. Thank you!
We all need you as our wise teacher. I feel real respect for you, and yes, I loved your software when it was fresh back in the day. A Russian software developer here. Get me right, I believe we engineers can still live in our creative world where borders and politics do not exist.
This is one of my favorite videos on this site so far. A little over my head initially. Please do more of these with similar explanations as to the buffer overrun explanation. I tried to get into similar stuff like this a long ago using the SoftIce debugger however couldn't find a replacement (with the same ease and power) for this after windows xp.
Dave, not only have you had a hand in creating many useful and well-used features of popular operating systems, you're a great storyteller too. Keep making good content.
I really like your stories! I was a nerdy kid in a small farm town the 90s. I dreamed of computers but had little access. So learning what was actually going on at the time is very satisfying. Thank you
I appreciate you showing a basic buffer overflow without overrunning the buffer into the heap or heap smashing. Still gets the point across with out allowing for system wide access. Although I suppose since code red already had system access they didn’t have to heap smash just execute the payload.
Hi Dave love the channel I’d be really interested in hearing you explain more low level computing concepts for example someone mentioned a hook to me the other day and even after reading up on it I’m still somewhat confused
Thanks! I'd love to show how Windows Hooks work, they're cool. I once wrote a "Task Recorder" app called WinMonkey that set various hooks and then recorded everything you did, so it could play it back as a macro. I got it to about 99.5% reliable, which I deemed a "tech support nightmare" so I never released it! But I got plenty of experience. Long story short, you write a DLL with an entry point called "MyWindowsHook() in it". If you set a global hook, when you do so, your dll is loaded into EVERY windows process immediately. I assume threadattach runs for every thread, etc... Then your DLL is called whenever the thing you've hooked happens. Let's say it's a keyboard hook. So every time anyone presses a key, every windows process calls their "MyWindowsHook()" function in your DLL. But each is loaded separately into each process, and they can't see each other. When I did it, I created a C++ template for a shared memory object that could be seen by all instances, and I remember that being complicated to write (sempahores, mutexes, etc) but handy to use! It's been a lot of years, I'd have to look back, but I think you can hook down to the Get/Peek message level... so you can inspect and/or modify any and every windows message sent or received by any process. It's an immense amount of power, and a real bitch to debug when you make a mistake!
This is awesome. Absolutely love the idea of covering viruses and bugs through history, and showing how they worked. Please make more of these! Great work Dave!
This virus still stands as one of my biggest technology nightmares. I work for a large ISP and our CMTS's (cable modem routers) couldn't keep up with the number of new sessions that were being created by our customer's infected Windows machines - effectively taking our entire network down for days. We learned how to find the signature of infected machines on our network, shut down each one manually, and tried to contact the customer to beg them to patch their machine. The problem is, the customers couldn't download the update from MS because we shut their access down due to the virus! So we had to open them back up, one by one, until enough of our customers patched to break the session-overrun log jam. Once we got things under control, I remember me and my colleagues installing fresh versions of Windows, plugging them into the Internet with no firewall/protection, and they would be infected with code red in literally seconds. It was a terrible virus. Thanks Microsoft.
I love these trips down memory lane. When Code Red hit I had been using Linux for a few yers already. I recall watching millions of hits on my Apache server at home from Code Red. I then found a request on the net that was crafted to target such a buffer overrun. Of course I could not resist trying it on some random servers. Soon I found I had a directory listing and access to some server or other. At which point I thought better of that game and backed out.
I was involved with cleaning up a few servers hit with Code Red. Wasn't a fun experience. Thanks for the clear explanation of how malicious payloods are delivered. :)
For how common these attacks are, there is drought of videos that do even half this well explaining. Thanks for demonstrating. Also, the blooper real is a nice touch
I love this channel man, I’ve been super interested lately about low level programming along with just interesting software engineering concepts such as your quake video. I have never heard of you before yesterday but as a cs student your skill set is something I strive to achieve. Thanks for the videos
Hey Dave - Enjoying your vids serves to make me wish even more I actually understood even a small bit of the details. I've probably got about 10 years on you, and even considering attempting to learn enough to grasp the bits mostly makes me need a nap. Regardless, fascinating and entertaining. Thanks! ... DT
I remember this exploit very well! I also remember the month the whole company focused on nothing but a search-and-destroy mission to find exploitable buffer overruns and other security enhancements (February 2002 IIRC), resulting in XPSP2. There were a lot of long hours on the IE team that month. Have you thought about doing a video on the Trustworthy Computing initiative?
Pretty interesting. I already knew about the stack and that putting too many things into unsafe functions could result in access to wrong addresses but so far I haven't been able to figure out how this would be utilized to inject malware. Thanks for the video.
This was one of my first informal lessons in computing being heavily involved with MUDs back in the day. They were all poorly coded out-of-the-box and much fun/headaches could be had depending on whether you were an owner or user. Pretty much any place there was text input (it was all text), you could bet it's length wasn't checked. Segmentation faults a plenty!
I worked for a very large tech company in the early '00s when this happened. At this company, Code Red itself did far less damage than the overreaction of the IT group, who were overzealous, turning off ethernet ports to any system running IIS and hampering anyone's ability to get any real work done. To make matters worse, the IT group declared victory and patted themselves on the back in an internal online article, to which (being this was an engineering company) all of the software and hardware engineers responded with thousands of angry blog posts in response, demanding they resign in shame for not matching the response to the threat.
A very insidious side effect of code red was that infected machines attempt to set up thousands of connections per second. I was working for a tiny ISP at the time, back then very few routers did TCP handshaking in hardware (even if they did promise hardware routing or layer 3 switching as Cisco called it) and this meant that our carrier grade router's CPU was inundate with connection set up and tear down tasks.
Can you believe that's the ONLY instance of anyone EVER saying "Use your powers for good" on TV that I could find? I thought it'd be common, but Archer is the only one!
This reminds me of my college assembly project. My project overwrote parts of my professors OS because of a math error on my part. I did get a passing grade because the project did most of what it was supposed to, where other's projects wouldn't even run. Good times.
WOOOW DAVE YOUR ABILITY TO COMMUNACATE SUCH COMPLEX PROCCESS AND FUNCTIONS HAVE BEEN TO THE LIKE THAT IVE NEVER SEEN DONE SO ELIQUENTLY AND SO GRACEFULLY IM TRULY IN GREAT ADMERATION OF YOU AND ALL OF YOUR ABILITIES THAT IM NOW A TRUE FOLLOWER OF ALL OF YOUR MASTERPEICES AND I WISH TO EVER BE JUST A FRACTION OF WHAT YOUVE BECOME AND A POSITIVE LEADER AND A TRUE ROLE MODEL FOR MANY GENARATIONS TO COME MY BROTHER... THANK YOU FOR ALL THAT YOUVE DONE FOR THE GREATER GOOD FOR ALL OF HUMANITY WITH ALL OF YOUR GREAT KNOWLEDGE THAT YOU SHARED!!!
Some years ago I "slowed" a buffer overflow that caused a program to crash by declaring an 8 kB char array (giving the overflow to have some space to mess with). I never found the cause of the buffer overflow. That is the ugliest "solution" I've made... but it worked ;)
The first buffer overflow exploit I wrote was back in 2002 for the Cisco VPN client under Linux giving instant root privileges, developed and exploited under Gentoo Linux and also by-passed the additional security measures they implemented back in the day and was filed under CVE: 2002-1447.
I enjoyed your video very much, even if it went right over my head, due only to my ignorance. Still very interesting and well put together. Hopefully one day I will be able to follow along properly. Keep up the good work!!!
I remember Code Red. It targeted Microsoft's IIS web server. My internet was so slow because everyone on my local cable modem ISP was infected and swamping the bandwidth for everyone. After examining some of those PC's that were attacking I found hundreds of freshly imaged corporate PC's all with IIS enabled by default on workstations. What sort of IT worker would do that? A very bad one. A white hat released a perl script that would run on Apache and it would automatically use the worms own backdoor to remove the infection and patch the IIS server. Wherever this was deployed, it greatly reduced the traffic jam caused by Code Red. The name of this Perl script? ICE as inspired by William Gibson's Neuromancer. In the 1984 cyberpunk fiction, ICE was an automated technology which stood for Intrusion Countermeasures Electronics. Since everyone was jacked into VR hacking away and surfing the net. ICE could potentially fry an attackers rig or perhaps their brain.
you are kinda relaxed for a guy who worked hand in hand with people creating all that flawed and bugged software that made all those viral epidemics possible
I'll never forget the first time I saw Code Red in our lab. I had a FreeBSD server that I used for various things which was running apache. I came into the lab one morning and saw there were these strange errors in the system logs. I called the IT department and advised them of what I was seeing and I was basically told to get lost - I was a contractor at the time. I escalated this to my boss who escalated it to his boss then all shit hit the fan. Fun times. BTW, this was in a giant healthcare organisation with a presence across the globe.
FDA
@@Wok_Agenda what does this have to do with the FDA
Good video, clear explanation. As a mainframe assembler programmer from the 80s I was surprised by the C functions that made assumptions around 'looking for' e.g. a 'string terminating character' and not insisting on somewhat more control over what you were doing. Later when using C myself I discovered how easy it could be to get in a mess. Definitely a good and well-presented video, thank you. While I was already very familiar with the exploit (I've been in cyber security >15 years) this was a smooth and clear description. The more people aware of these elementary exploits the better.
Thanks for the kind words! If you have any cool language experience that would apply to our Primes project, please check it out on Github! I'd love to see a System/360 assembler version that we can run in an emulator!
The standard C library has some issues with these unchecked string buffer access and the varying convention of putting source or target as first argument. Long time ago I had to solve mysterious crashes in an application and it had these unsafe string buffer access all over the place. Any serious programmer would have made a safe string struct wrapper or use C++.
Me too. Moving from 1990s MVS/ESA to x86 I was shocked at the amount of blind trust placed in other code and the incoming data. gets() is the classic example--ouch!
I ended up writing my own functions for almost everything, and then my own compiler (long story).
I like the idea of trying primes on S/360.
For anyone unaware, the "TK4-" Hercules install with MVS 3.8 is literally TurnKey.
I began in Unit Record Equipment, 407s etc then moved to 1401, 360, 370, 4300 series, then S390. I have written millions of lines of code in mainframe assembler and even some micro code on a 360/30.
I built my own microcomputer utilizing IBM Op codes and EBCDIC so i could test my code before getting valuable actual machine time to test.
Once I got my code running on the mainframe I crashed the program by implementing an invalid Op code from the front panel. I got a core dump, then corrected my source code to reflect proper operation.
I then was fascinated by the Intel 8080 and built another machine using this and the S-100 bus where I could obtain I/o cards etc. I made my own front panel as well. The whole stack pointer and very limited registers left me puzzled as to why they didnt adopt tried and true technology of IBM.
I trained COBOL programmers how to read core dumps as well. And even got COBOL to dynamically call other COBOL programs. Something that IBM said could never be done.
I also got mainframes to talk to another using the 3270 protocol, again something IBM said was not possible (later they developed Bisynchronis Pass Thru or BPT) this allowed applications to talk to another application directly using STD COBOL under CICS.
I LOVE mainframe assembly programming and consider INTELs x86 model a toy that wants to play in a grown up world .
What i could do in 32k of memory could not even be dreamed of in C or C++
@@rty1955 Sounds as though you had some fun over the years!
From my POV, x86 suffers from compatibility going all the way back to its roots with the 4-bit 4004.
x64 is a lot cleaner, and if we can just exterminate every null-terminated string I'll be happy :-)
I love the sinister intro followed by that cheerful and glorious smile and salute with "Hey I'm Dave"
As an admin, during this time, I remember people freaking out when this happened. Within the government space almost nothing was properly patched, so it is a small miracle that Code Red wasn't worse. As for patching, Microsoft's buggy patches were as much to blame as the worm itself. When a new critical patch came out, the game of chicken started. From Tuesday through the Weekend you would watch newsgroups and forums to see if this patch would take down your servers. If you were lucky you had a bare metal server clone you could test the patch on and see if it broke your company software. This was the era where being an admin meant you not only managed the servers, but you wrote the business software and managed the database.... full stack started at bare metal back then.
in reality Microsoft patches are still rather buggy and the only patches i ever ran while using windows were security. any other patches went by the wayside until a week after and sometimes more to make sure they didn't break shit.
@@KaziiTheAvali_inactive Currently a sysadmin, and can confirm we do updates on the FIRST Tuesday of each month, 1 week before patch Tuesday. This is to make sure the updates have had about 3 weeks to get all their shit re-patched with OOB updates.
Glorious patch Tuesday, breaking forensic software every month without fail.
You should research the old Burroughs MCP tagged memory implementation and none of this would not happened. Your C program would have gotten a run time Segmented Array error as soon as the buffer length was exceeded and the program killed.
I have been really enjoying your channel. The last 96 seconds of this video are gold, I like that you don't take yourself so serious and are able to show the outtakes. Keep up the good work. Story 10/10 would recommend.
Thanks much!
Me being a retired "Fork Bomb" coder, I loved this video.
Just badly written code, and that happens, not sure hosting service/compile farms too happy about that.
Well this certainly brings back some memories! I've worked in the field since 1995 (currently at MS as a digital forensics investigator.) I recently found your channel and really enjoy it. I run a security-focused channel and I can certainly appreciate the amount of time you put into making this content, especially with the high production value.
These are terrific accounts, *please* keep them coming! The addition of bloopers is a nice touch.
Glad you like them! If you've ideas for other topics, please do share, as I enjoy doing them! The bloopers are hit or miss, depends how it went that day, so sometimes I don't include them!
Love the direction you're headed with these types of videos, Dave! Might be a fun time to pivot to ROP-based exploits if you have any examples you think would be worthy enough to cover. :)
Agreed. Would love to see it.
Heh heh, I see what you did there 😆
The code red worm was filling my Linux web log drive partitions for months and years afterwards! Thanks, Dave for the great explainer piece to camera!
I bet a LOT of Unix admins got very used to processing the DEFAULT.IDA requests out of their logs! Of course I guess even the properly patched Windows guys would too.
Even years afterwards, I would see Code Red requests in my Linux access log
Was this the one which tried to scan a specific port? I remember checking the addresses showing up in my firewall log for the backdoor. I could use 2 or 3 of those (i got a lot more entries in the log). I placed a readme file in their rootdir about the backdoor.
@@kylestubblefield3404 nicely done sir!!
I was in University at the time, and we were all called in for the weekend, which we spent scanning the network looking for people running web servers and then making sure they were patched. In several cases, this meant breaking into offices which had somehow been re-keyed to not use the building master that we were issued as admin staff.
Good times.
This is by far the best explanation of how buffer overruns work. When I first encountered such things, I felt it was a bit of "black magic", until I saw the updated source that fixes such things. It took me a great while to understand the details because the patch was only explained in terms of the fix: to perform bounds checking on a buffer. Obviously the reason for such vagueness is to prevent exploits from spewing everywhere. Thanks for the deep-dive into how all this works....and, hopefully as you said, people will "not use their powers for evil" ;).
Mountain Dew Code Red also fueled most of my late night studying sessions in college. Stuff was great.
Hitting up a 7-11 at 2AM to resupply with Code Red. Made mention to the clerk the stuff seems a bit on the addictive side. He mentions he goes through a case every few days.
My health tanked shortly thereafter.
@@quintessenceSL I drank so much I became allergic to red food coloring.
As I recall, when Code Red happened the Canadian version of Code Red wasn't caffeinated
Most content creators who discuss this stuff would have said '...the stack is more complicated that this for several reasons', ending there and moving on. You, on the other hand, have just made me a very happy man. As soon as I heard 'Firstly,...' I knew you were going to detail why its more complicated which is exactly why I am now subscribed. Love to learn and you're a great teacher and story teller!
Thanks mate for this, as a hobbyist programmer it's always interesting to see the full power of the debugger in an interesting and engaging way.
Yours is the only channel for which I consistently leave a like. I like the way you honestly express your motivation and then include a simple please. Also I literally like almost all of your videos.
I love your channel! My career spans from 1977 to 2010. I lived through most of what you discuss!
After all these years…. I still double check my targets, but I yell under my breath “FIRE!!!!” Love your content. Thank you for all you do.
I'm not a developer, coder or anything related to IT except I look after my own business systems and have coded in the past and am old enough to have been around for most of these stories :-)
You're easy to listen to Dave, I enjoy the background.
I missed this when it came out. This was a really good explanation of the buffer overflow exploit. My software experience is limited (I'm mostly a hardware guy) but I programmed in assembler and BCPL in the 80s and a little C in the 90s. I understood pretty much all of this. Thank you.
I really like your videos like this where you tell a story and explain how something happened. I especially like the ones where you track down inside information of what was actually said or done by the people that said or did it. It's a extra bonus when examples, such as the buffer overflow demonstration, are presented like this video.
You editing has really improved, it is very entertaining. And the content is even better.
Keep up the good work!
My God. I discovered this series by accident and I’m glad I did. I haven’t written a line of code for a couple of decades but this sure takes me back to my roots (pun intended). I was, at one time, quite proficient in C/C++ and assembler. There was a time when we had no choice but to write and maintain our own drivers for new hardware on some platforms. I go back to the time when all our programs had to be written in 32K overlays and manually swapped to execute. I’m fascinated by the idea that techniques I used back in the day will still work 30 years later.
Wow, was just thinking of researching something along these lines. Thanks, Dave! Now i can properly enjoy my Friday evening. Let me grab a cold one, Cheers!
Have fun!
I don't know much about low level stuff, so seeing the memory addresses like that, and the EBP being overwritten was really cool
Fascinating. Thank you Dave!
Back in the days before file storage services like OneDrive, Dropbox, Google Drive etc. I used the IIS function of my home PC to save files from my work laptop as I traveled. I had a static IP on an early DSL line, so it was pretty convenient. Somehow; someone managed to get my IIS password. They didn't install malware, but they did uploaded several massive password-protected RAR archives which were subsequently downloaded many times, using all the bandwidth of the connection. I still don't know how they got into the server, but it was frustrating. I never figured out the contents of the archives, but I expect they were pirated movies or pirated software of some type.
Your blooper reel on this one makes me feel extremely seen; I don't Make Videos or anything but the way I talk to myself anytime I'm alone while I'm just doing whatever is a LOT like that, lol.
Been really enjoying your channel & learning some interesting stuff as well! Thanks for sharing such a cool assortment of information here :3
I enjoyed watching your bloopers at the end of the video and presenting them in B&W was an extra nice touch. I hope you'll consider doing this in all of your new videos too
Your code was a concise and perfect example of what can happen with a buffer overflow. It brought back early-90s memories of unintentional buffer overflows, when my code would cause my DOS machine to beep (ASCII 07, I believe) and display blinking characters. Ah, the good old days. :)
I remember when the ASCII BEL character (07) rang an actual bell.
It really is interesting to see a programmer's perspective on vulnerabilities rather than just hearing people reporting on it.
Dave, I love your podcasts and most importantly your edits at the end! I laugh at each edit and wonder how you ever geta podcast completed! Keep it up!
This is such a fantastic video, both entertaining and educational.
I work mostly with embedded systems which lack a lot of the protections a full blown OS and a lot of static analysis tools provide. More and more embedded systems are being connected to the internet each day and I think we will see them experience many of the exploits that have been protected against, on servers and desktops decades ago.
It's videos like these I share with many embedded Devs to hopefully help them understand and protect their code against attacks like this while maintaining lean code bases.
Thank you!
We all need you as our wise teacher. I feel real respect for you, and yes, I loved your software when it was fresh back in the day. A Russian software developer here. Get me right, I believe we engineers can still live in our creative world where borders and politics do not exist.
This is one of my favorite videos on this site so far. A little over my head initially. Please do more of these with similar explanations as to the buffer overrun explanation. I tried to get into similar stuff like this a long ago using the SoftIce debugger however couldn't find a replacement (with the same ease and power) for this after windows xp.
Very well explained man! Always a pleasure to watch these videos!
Glad you like them!
Dave, not only have you had a hand in creating many useful and well-used features of popular operating systems, you're a great storyteller too. Keep making good content.
I really like your stories! I was a nerdy kid in a small farm town the 90s. I dreamed of computers but had little access. So learning what was actually going on at the time is very satisfying. Thank you
I appreciate you showing a basic buffer overflow without overrunning the buffer into the heap or heap smashing. Still gets the point across with out allowing for system wide access. Although I suppose since code red already had system access they didn’t have to heap smash just execute the payload.
Its good to watch someone that actually knows what they are talking about.
This is a great explanation. Possibly the best I've ever seen.Thank you.
I loved the blooper part. Man, makes me feel so much better about recording shorts. I always have a foot in my mouth as soon as the camera is rolling.
I loved this video, please do more like these. The small code demo was great :)
More to come!
The beginning of the video was so intriguing I would probably watch a full video just you explaining it like that xo
Hi Dave love the channel I’d be really interested in hearing you explain more low level computing concepts for example someone mentioned a hook to me the other day and even after reading up on it I’m still somewhat confused
Thanks! I'd love to show how Windows Hooks work, they're cool. I once wrote a "Task Recorder" app called WinMonkey that set various hooks and then recorded everything you did, so it could play it back as a macro. I got it to about 99.5% reliable, which I deemed a "tech support nightmare" so I never released it! But I got plenty of experience.
Long story short, you write a DLL with an entry point called "MyWindowsHook() in it". If you set a global hook, when you do so, your dll is loaded into EVERY windows process immediately. I assume threadattach runs for every thread, etc... Then your DLL is called whenever the thing you've hooked happens. Let's say it's a keyboard hook. So every time anyone presses a key, every windows process calls their "MyWindowsHook()" function in your DLL. But each is loaded separately into each process, and they can't see each other. When I did it, I created a C++ template for a shared memory object that could be seen by all instances, and I remember that being complicated to write (sempahores, mutexes, etc) but handy to use!
It's been a lot of years, I'd have to look back, but I think you can hook down to the Get/Peek message level... so you can inspect and/or modify any and every windows message sent or received by any process. It's an immense amount of power, and a real bitch to debug when you make a mistake!
This is awesome. Absolutely love the idea of covering viruses and bugs through history, and showing how they worked. Please make more of these! Great work Dave!
Loved learning about how the heap stack works on a deep level! The information on the worm was the cherry on top.
This virus still stands as one of my biggest technology nightmares. I work for a large ISP and our CMTS's (cable modem routers) couldn't keep up with the number of new sessions that were being created by our customer's infected Windows machines - effectively taking our entire network down for days. We learned how to find the signature of infected machines on our network, shut down each one manually, and tried to contact the customer to beg them to patch their machine. The problem is, the customers couldn't download the update from MS because we shut their access down due to the virus! So we had to open them back up, one by one, until enough of our customers patched to break the session-overrun log jam. Once we got things under control, I remember me and my colleagues installing fresh versions of Windows, plugging them into the Internet with no firewall/protection, and they would be infected with code red in literally seconds. It was a terrible virus. Thanks Microsoft.
Great video Dave, I for one appreciate your dedication to the art of programming and this channel.
I love these trips down memory lane. When Code Red hit I had been using Linux for a few yers already. I recall watching millions of hits on my Apache server at home from Code Red. I then found a request on the net that was crafted to target such a buffer overrun. Of course I could not resist trying it on some random servers. Soon I found I had a directory listing and access to some server or other. At which point I thought better of that game and backed out.
Great content! I learned a lot from this. You show examples without going overboard and do a great job with the explanations. Please, keep it up!
Great description of how a buffer overrun works! Thanks Dave
I was involved with cleaning up a few servers hit with Code Red. Wasn't a fun experience. Thanks for the clear explanation of how malicious payloods are delivered. :)
Love the outtakes at the end of the video And the content of the video is amazing
For how common these attacks are, there is drought of videos that do even half this well explaining. Thanks for demonstrating.
Also, the blooper real is a nice touch
Glad you enjoyed it!
I love this channel man, I’ve been super interested lately about low level programming along with just interesting software engineering concepts such as your quake video. I have never heard of you before yesterday but as a cs student your skill set is something I strive to achieve. Thanks for the videos
Hey Dave - Enjoying your vids serves to make me wish even more I actually understood even a small bit of the details. I've probably got about 10 years on you, and even considering attempting to learn enough to grasp the bits mostly makes me need a nap. Regardless, fascinating and entertaining.
Thanks! ... DT
The bloopers are great lol, keep up the good work mate!
Thanks Dave that was a fun episode! … like the bloopers too 😊
I remember this exploit very well! I also remember the month the whole company focused on nothing but a search-and-destroy mission to find exploitable buffer overruns and other security enhancements (February 2002 IIRC), resulting in XPSP2. There were a lot of long hours on the IE team that month. Have you thought about doing a video on the Trustworthy Computing initiative?
Top vid. I always enjoy listening to folks who actually know what they are talking about.
Hey Dave, brilliant video again! I so wish you could have been my mentor when I worked at Microsoft!!! Keep up the good work!
Dave: "As you can see, my channel is still fairly small."
Me who is subscribed to classical music channels which are 10 years old with
Probably my favorite video of yours. Keep it up.
Wow, thanks!
I must say, I do enjoy me some bloopers at the end lol. Thanks for sharing!
thank you for your time and always a pleasure to watch your videos keep up the ace work 🙂
Wow, am I ever glad I took that assembly course. I’m surprised at how much sense this makes to me.
Pretty interesting. I already knew about the stack and that putting too many things into unsafe functions could result in access to wrong addresses but so far I haven't been able to figure out how this would be utilized to inject malware. Thanks for the video.
Can't believe a former Microsoft programmer is ending up making RUclips videos, how cool is that. I did live in the Win95 era.
This was one of my first informal lessons in computing being heavily involved with MUDs back in the day. They were all poorly coded out-of-the-box and much fun/headaches could be had depending on whether you were an owner or user. Pretty much any place there was text input (it was all text), you could bet it's length wasn't checked. Segmentation faults a plenty!
haha that sounds like a good time
I don't know why I listened to 25min of a foreign language gibberish, but for some reason, I feel compelled to learn to code.
I worked for a very large tech company in the early '00s when this happened. At this company, Code Red itself did far less damage than the overreaction of the IT group, who were overzealous, turning off ethernet ports to any system running IIS and hampering anyone's ability to get any real work done. To make matters worse, the IT group declared victory and patted themselves on the back in an internal online article, to which (being this was an engineering company) all of the software and hardware engineers responded with thousands of angry blog posts in response, demanding they resign in shame for not matching the response to the threat.
Oh my goodness your visuals are amazing! 🤩 What camera do you use?
Thank you for this thoughtful and entertaining look at Code Red. I've watched several of your other videos and love them all. Cheers.
Excellent explanation! I loved the story telling parts as well.
Watched the whole video, thanks Dave, you're awesome. Take my sub and like! :)
Great video Dave - not going to pretend that I fully understood all of this but very interesting nonetheless. Thanks mate :)
Strong Rod Serling for the intro. That was fun.
A very insidious side effect of code red was that infected machines attempt to set up thousands of connections per second. I was working for a tiny ISP at the time, back then very few routers did TCP handshaking in hardware (even if they did promise hardware routing or layer 3 switching as Cisco called it) and this meant that our carrier grade router's CPU was inundate with connection set up and tear down tasks.
This is absolutely fascinating, great video!
Amazing video as always! Hi from Italy ^^
I always appreciate a good Archer reference.
Can you believe that's the ONLY instance of anyone EVER saying "Use your powers for good" on TV that I could find? I thought it'd be common, but Archer is the only one!
@@DavesGarage Well with a bit of hair gel you could pass for Krieger :P
@@DavesGarage Bob's Burgers S4E16, Deadpool, Jimmy Neutron movie, Paw Patrol movie, there's lots :D
Awesome video Dave. Very informative.
Glad you enjoyed it! Trying to strike a balance of "real technical info" without scaring too many away!
This reminds me of my college assembly project. My project overwrote parts of my professors OS because of a math error on my part. I did get a passing grade because the project did most of what it was supposed to, where other's projects wouldn't even run. Good times.
Hilarious 😂
Thanks for the great story. One of my favorite books from around that time was The Cuckoo's Egg by Clifford Stoll.
Awesome Presentation, Informative and entertaining. Someone buy that Man a beer.
WOOOW DAVE YOUR ABILITY TO COMMUNACATE SUCH COMPLEX PROCCESS AND FUNCTIONS HAVE BEEN TO THE LIKE THAT IVE NEVER SEEN DONE SO ELIQUENTLY AND SO GRACEFULLY IM TRULY IN GREAT ADMERATION OF YOU AND ALL OF YOUR ABILITIES THAT IM NOW A TRUE FOLLOWER OF ALL OF YOUR MASTERPEICES AND I WISH TO EVER BE JUST A FRACTION OF WHAT YOUVE BECOME AND A POSITIVE LEADER AND A TRUE ROLE MODEL FOR MANY GENARATIONS TO COME MY BROTHER... THANK YOU FOR ALL THAT YOUVE DONE FOR THE GREATER GOOD FOR ALL OF HUMANITY WITH ALL OF YOUR GREAT KNOWLEDGE THAT YOU SHARED!!!
very nice explanation of how to actually get code to run through a buffer overflow exploit :)
Like the content very much like the outtakes even better
Very entertaining yet informative! Great stuff.
Love the out-takes :)
Some years ago I "slowed" a buffer overflow that caused a program to crash by declaring an 8 kB char array (giving the overflow to have some space to mess with). I never found the cause of the buffer overflow. That is the ugliest "solution" I've made... but it worked ;)
The first buffer overflow exploit I wrote was back in 2002 for the Cisco VPN client under Linux giving instant root privileges, developed and exploited under Gentoo Linux and also by-passed the additional security measures they implemented back in the day and was filed under CVE:
2002-1447.
Great video Dave. Entertaining and informative. Keep them coming.
Thanks again Dave for explaining this in an understandable format :) Loved it!!!
Love this kind of story Dave. More please.
I enjoyed your video very much, even if it went right over my head, due only to my ignorance. Still very interesting and well put together. Hopefully one day I will be able to follow along properly. Keep up the good work!!!
I remember Code Red. It targeted Microsoft's IIS web server. My internet was so slow because everyone on my local cable modem ISP was infected and swamping the bandwidth for everyone. After examining some of those PC's that were attacking I found hundreds of freshly imaged corporate PC's all with IIS enabled by default on workstations. What sort of IT worker would do that? A very bad one. A white hat released a perl script that would run on Apache and it would automatically use the worms own backdoor to remove the infection and patch the IIS server. Wherever this was deployed, it greatly reduced the traffic jam caused by Code Red. The name of this Perl script? ICE as inspired by William Gibson's Neuromancer. In the 1984 cyberpunk fiction, ICE was an automated technology which stood for Intrusion Countermeasures Electronics. Since everyone was jacked into VR hacking away and surfing the net. ICE could potentially fry an attackers rig or perhaps their brain.
I'm new to your channel. I'm no CS savant but I love what I've seen. This is my sixth video in my binge watching adventure. :)
Welcome aboard!
I'm new to your channel but i love your vids. Specially the stories from the ms office 😂 the outro wins on this one though xD
you are kinda relaxed for a guy who worked hand in hand with people creating all that flawed and bugged software that made all those viral epidemics possible
I respect you and your work. Thank you, Dave, for making such great content and sharing such fascinating information!