WEBVTT 1 00:00:00.040 --> 00:00:03.879 Okay, imagine this. You're just browsing online, you know, checking 2 00:00:03.879 --> 00:00:07.559 your bank balance, maybe buying something, completely oblivious that a 3 00:00:07.599 --> 00:00:10.320 hacker is slipping in through some tiny crack in the software, 4 00:00:11.160 --> 00:00:14.400 just ready to take control. That's the world we're diving 5 00:00:14.400 --> 00:00:19.239 into today, this fascinating, kind of unnerving realm of software exploits. 6 00:00:19.320 --> 00:00:22.039 It really is like a hidden world, you know, operating 7 00:00:22.120 --> 00:00:25.000 right there beneath the surface of everything we do digitally. 8 00:00:25.399 --> 00:00:28.039 And just like you wouldn't walk into some I don't know, 9 00:00:28.199 --> 00:00:32.280 dangerous city without at least understanding the risks, you really 10 00:00:32.320 --> 00:00:35.159 need to know the threats out there online and how 11 00:00:35.159 --> 00:00:36.520 to protect yourself right right. 12 00:00:36.439 --> 00:00:39.159 And that's where this book, Writing Security Tools and Exploits 13 00:00:39.159 --> 00:00:42.119 comes in. This is by Vincent lou and Villliosopov. It 14 00:00:42.159 --> 00:00:45.520 seems like the ultimate guide to this underground world. 15 00:00:45.600 --> 00:00:48.799 Oh absolutely, It's like a masterclass in both you know, 16 00:00:48.920 --> 00:00:52.000 offense and d defense. It lays bare all the tactics 17 00:00:52.039 --> 00:00:54.240 that hackers use and then shows the strategies we can 18 00:00:54.320 --> 00:00:55.119 use to counter them. 19 00:00:55.280 --> 00:00:59.119 One thing that really struck me in the introduction was 20 00:00:59.159 --> 00:01:01.960 this idea that even a tiny error in code, like 21 00:01:02.119 --> 00:01:05.159 one character out of place, you know, in millions of 22 00:01:05.200 --> 00:01:07.760 lines give me a vulnerability? Is that really all it takes? 23 00:01:07.959 --> 00:01:11.799 It's true. Yeah, these vulnerabilities are like like cracks in 24 00:01:11.840 --> 00:01:14.879 a fortress wall. They might seem small, but they give 25 00:01:15.239 --> 00:01:18.239 just enough leverage, you know, for the attacker to break through. 26 00:01:18.280 --> 00:01:20.920 And they're way more common than you might think. Table 27 00:01:20.959 --> 00:01:23.000 one point one in the book. It shows exactly how 28 00:01:23.000 --> 00:01:25.760 common these vulnerabilities are, you know, in different software. 29 00:01:25.799 --> 00:01:28.359 Wow, I'm looking at that table now. Server applications seem 30 00:01:28.400 --> 00:01:32.400 particularly vulnerable. Nearly sixty percent of reported vulnerabilities back in 31 00:01:32.439 --> 00:01:34.760 two thousand and two were found in servers. 32 00:01:35.519 --> 00:01:37.640 It's a bit unsettling considering how much we rely on 33 00:01:37.680 --> 00:01:38.400 service these days. 34 00:01:38.439 --> 00:01:41.079 It's a constant arms race, you know. As developers build 35 00:01:41.079 --> 00:01:44.519 more complex software, more and more vulnerabilities emerge. But the 36 00:01:44.519 --> 00:01:48.400 thing is, by understanding how exploits actually work, it gives 37 00:01:48.480 --> 00:01:52.719 us a huge advantage. It's like learning the attackers' playbooks 38 00:01:52.719 --> 00:01:55.719 so we can anticipate their moves. Okay, so let's unpack 39 00:01:55.719 --> 00:01:58.920 that playbook a little. What exactly is and exploit and 40 00:01:59.000 --> 00:02:01.599 how does it relate to to this thing called a 41 00:02:01.640 --> 00:02:02.560 buffer overflow? 42 00:02:03.000 --> 00:02:06.719 So an exploit is basically the code that takes advantage 43 00:02:06.760 --> 00:02:07.680 of a vulnerability. 44 00:02:08.199 --> 00:02:08.759 You know, it's the. 45 00:02:08.719 --> 00:02:12.520 Actual attack itself. The buffer overflow is the vulnerability, the 46 00:02:12.560 --> 00:02:14.759 weakness that makes the attack even possible. 47 00:02:14.840 --> 00:02:17.560 So the buffer overflow is the open door, and the 48 00:02:17.639 --> 00:02:19.479 exploit is the burglar sneaking in. 49 00:02:19.719 --> 00:02:21.560 Yeah, that's a pretty good way to put it. A 50 00:02:21.560 --> 00:02:24.800 buffer overflow happens when a program tries to put more 51 00:02:24.879 --> 00:02:27.840 data into a storage area than it can hold. It's 52 00:02:27.879 --> 00:02:31.280 like trying to stuff a whole wardrobe into like a 53 00:02:31.400 --> 00:02:33.759 tiny suitcase. You know, things are going to spill out 54 00:02:34.120 --> 00:02:35.639 and it causes big problems. 55 00:02:35.719 --> 00:02:38.280 Okay, starting to see the connection here. So the exploit 56 00:02:38.439 --> 00:02:40.360 uses this overflow to get into the system. 57 00:02:40.479 --> 00:02:43.759 But how well, that's where things get pretty interesting. Imagine 58 00:02:43.759 --> 00:02:46.520 the system's memory like a really organized city, right with 59 00:02:46.560 --> 00:02:49.319 different areas for storing data and running code. When a 60 00:02:49.360 --> 00:02:52.319 buffer overflows, it's like this sudden flood that spills into 61 00:02:52.319 --> 00:02:56.159 other areas, maybe damaging important buildings or even like changing 62 00:02:56.199 --> 00:02:57.280 street signs. 63 00:02:57.199 --> 00:02:59.159 Changing street signs. What do you mean by that? 64 00:02:59.240 --> 00:03:02.360 Well, think of stream signs as like instructions, you know, 65 00:03:02.560 --> 00:03:05.080 they tell the program where to go next. By messing 66 00:03:05.120 --> 00:03:08.840 with the overflow, an attacker can actually rewrite these signs 67 00:03:09.240 --> 00:03:12.199 redirecting the program to run their own malicious code, like 68 00:03:12.280 --> 00:03:15.080 hijacking a trunk and forcing it to go somewhere else entirely. 69 00:03:15.639 --> 00:03:17.680 So it's not just about like crashing the system, it's 70 00:03:17.680 --> 00:03:20.240 about taking control of the whole thing. Yeah, but how 71 00:03:20.240 --> 00:03:24.840 do they actually write this malicious code? What tools they 72 00:03:24.879 --> 00:03:25.439 even use? 73 00:03:25.800 --> 00:03:29.560 It's all about speaking the computer's language, which is assembly code. 74 00:03:29.560 --> 00:03:33.240 It's like the raw machine level code. It directly controls 75 00:03:33.280 --> 00:03:36.919 the hardware, and the malicious code they inject is called 76 00:03:37.039 --> 00:03:37.919 shell code. 77 00:03:38.120 --> 00:03:39.879 Shell code, what's so special about that? 78 00:03:40.000 --> 00:03:43.439 Think of shell codes like, ugh, the attackers remote control. 79 00:03:43.639 --> 00:03:45.960 It's a small but powerful piece of code that, once 80 00:03:45.960 --> 00:03:48.639 it's injected, allows them to control your system from far 81 00:03:48.680 --> 00:03:52.080 away access files, maybe steal your data, or even use 82 00:03:52.080 --> 00:03:53.479 your computer to attack others. 83 00:03:53.599 --> 00:03:57.199 That's not good. But why use assembly language? Isn't that 84 00:03:57.280 --> 00:03:59.719 like really low level programming? 85 00:04:00.039 --> 00:04:03.159 It is, but that's why it's so powerful for attackers 86 00:04:03.199 --> 00:04:07.199 and defenders. Assembly language gives you like total control over 87 00:04:07.240 --> 00:04:10.199 the system hardware, allows you to manipulate memory and run 88 00:04:10.199 --> 00:04:12.240 commands at the most basic level. 89 00:04:12.360 --> 00:04:16.920 So it's like having root access to the system's control panel. 90 00:04:16.759 --> 00:04:19.959 Exactly, and to make things Even harder hackers will often 91 00:04:20.040 --> 00:04:23.160 encode their shell code to avoid detection. You know, it's 92 00:04:23.160 --> 00:04:26.399 like hiding a secret message inside a seemingly normal text. 93 00:04:26.759 --> 00:04:29.600 That's what encoding does. It disguises the code makes it 94 00:04:29.600 --> 00:04:30.920 harder for security to find. 95 00:04:31.079 --> 00:04:34.000 Lever but sneaky. So we've got our building blocks here, 96 00:04:34.360 --> 00:04:37.439 assembly language and shell code. But how do they actually 97 00:04:38.399 --> 00:04:41.639 use these to exploit a system, like specifically through a 98 00:04:41.680 --> 00:04:42.519 buffer overflow? 99 00:04:42.639 --> 00:04:46.040 Okay, So picture the program's memory like a stack of flights. 100 00:04:46.120 --> 00:04:48.480 Each plate is a function, call or data. When a 101 00:04:48.480 --> 00:04:50.480 function is called, a new plate goes on top, and 102 00:04:50.519 --> 00:04:53.639 when it's done, the plate's removed. This nice and organized 103 00:04:53.680 --> 00:04:56.439 stack is where the buffer overflow causes all the trouble. 104 00:04:56.639 --> 00:04:58.800 Okay, so how does the overflow actually happen? 105 00:04:58.920 --> 00:05:03.480 So imagine imagine a program that asks you for your name, right, 106 00:05:03.800 --> 00:05:06.199 it sets aside some space in memory to store it. 107 00:05:06.519 --> 00:05:08.839 That space is like a plate on the stack. Now, 108 00:05:08.879 --> 00:05:12.399 if someone enters a name that's longer than the allocated space, 109 00:05:12.399 --> 00:05:14.360 it's like piling way too much food on that plate. 110 00:05:14.639 --> 00:05:17.759 It spills over, potentially messing up the plates below it. 111 00:05:18.160 --> 00:05:20.800 So the extra data spills over into other parts of memory. 112 00:05:21.040 --> 00:05:22.279 What kind of damage can it do. 113 00:05:23.120 --> 00:05:25.600 The most important piece of information that can be overwritten 114 00:05:25.920 --> 00:05:28.920 is a return address. It's like a note on each 115 00:05:28.959 --> 00:05:31.519 plate telling the weight which table it goes back to. 116 00:05:31.839 --> 00:05:35.560 If an attacker changes this address, they can redirect the 117 00:05:35.560 --> 00:05:37.199 program to their malicious code. 118 00:05:37.399 --> 00:05:40.319 So it's like changing the destination on a package. Instead 119 00:05:40.319 --> 00:05:42.120 of going to the right place, it ends up with 120 00:05:42.120 --> 00:05:45.839 the attacker. That's wild. But how do they even know 121 00:05:45.839 --> 00:05:46.439 where to send it? 122 00:05:46.480 --> 00:05:50.160 That's where understanding, oh process memory maps comes in. It's 123 00:05:50.199 --> 00:05:52.360 like having a map of the city showing where each 124 00:05:52.439 --> 00:05:55.519 thing is. Attackers need this map to find the exact 125 00:05:55.560 --> 00:05:57.319 locations and memory they want to target. 126 00:05:57.720 --> 00:06:00.360 So they need another layout of the system's memory to 127 00:06:00.399 --> 00:06:01.560 make their attacks work. 128 00:06:01.759 --> 00:06:04.800 Yeah, exactly. And these maps are different for different operating 129 00:06:04.839 --> 00:06:08.399 systems like Linux or Windows. It's like having different maps 130 00:06:08.399 --> 00:06:10.000 for different cities. You've got to have the right one 131 00:06:10.040 --> 00:06:10.519 to get around. 132 00:06:10.680 --> 00:06:13.879 This is getting complex, but I see how these pieces 133 00:06:13.879 --> 00:06:17.639 fit together. Now the exploit, the buffer overflow, shell code, 134 00:06:17.800 --> 00:06:20.600 and now these memory maps. It's like a delicate but 135 00:06:20.839 --> 00:06:24.879 dangerous puzzle where everything has to be perfect for the 136 00:06:24.879 --> 00:06:25.800 attack to succeed. 137 00:06:26.199 --> 00:06:28.279 That's a good way to think about it, and We've 138 00:06:28.319 --> 00:06:30.480 really just scratched the surface here. When it comes to 139 00:06:30.519 --> 00:06:33.360 stack overflows. There's a lot of nuances and techniques, but 140 00:06:33.439 --> 00:06:37.399 the main takeaway is this understanding how these attacks work 141 00:06:37.959 --> 00:06:39.959 is the first step to protecting ourselves. 142 00:06:40.040 --> 00:06:43.360 Okay, so we've conquered the stack, but I'm guessing there 143 00:06:43.360 --> 00:06:47.240 are other ways to corrupt memory, right, and the other 144 00:06:47.360 --> 00:06:49.000 vulnerabilities lurking out there. 145 00:06:49.279 --> 00:06:51.800 You're absolutely right. The book also talks about heap corruption, 146 00:06:52.199 --> 00:06:54.439 which is a whole different beast. It's like a different 147 00:06:54.480 --> 00:06:58.040 part of our memory city, with its own layout and weaknesses. 148 00:06:58.120 --> 00:06:59.920 Deep corruption. What's that all about? 149 00:07:00.120 --> 00:07:02.759 Think of the heap as like a giant warehouse, right, 150 00:07:02.800 --> 00:07:05.199 where programs can ask for storage as they need it. 151 00:07:05.199 --> 00:07:08.560 It's way more dynamic and unpredictable than the stack, and 152 00:07:08.839 --> 00:07:11.560 just like the stack, it can be vulnerable to these overflows. 153 00:07:11.560 --> 00:07:14.319 So attackers can target the heap too. But how's that 154 00:07:14.360 --> 00:07:16.759 different from exploiting the sack? 155 00:07:16.920 --> 00:07:20.560 It gets really complicated. The heap is managed in like chunks, 156 00:07:21.120 --> 00:07:25.639 and attackers try to manipulate those chunks to overwrite important data, 157 00:07:25.680 --> 00:07:28.519 similar to stack overflows, but the techniques are different. 158 00:07:28.639 --> 00:07:29.839 Sounds tricky, it is. 159 00:07:30.120 --> 00:07:34.600 Heap overflows are known for being oh inconsistent and much 160 00:07:34.600 --> 00:07:38.160 harder to exploit than stack overflows. But don't worry, we'll 161 00:07:38.199 --> 00:07:39.879 get into the details in the next part of our 162 00:07:39.920 --> 00:07:41.879 deep dive. We'll look at how the heap works, what 163 00:07:41.920 --> 00:07:45.279 makes it vulnerable, and how attackers exploit those weaknesses. 164 00:07:45.360 --> 00:07:47.279 I'm ready, this is fascinating. Before we move on, I 165 00:07:47.319 --> 00:07:50.120 gotta ask, Yeah, how common are these attacks in the 166 00:07:50.160 --> 00:07:55.160 real world. Are we talking like theoretical threats or is 167 00:07:55.160 --> 00:07:57.120 this stuff actually happening every day? 168 00:07:57.439 --> 00:08:00.879 Oh, these attacks are happening constantly. In fact, some of 169 00:08:00.879 --> 00:08:03.680 the biggest data breaches and cyber attacks you hear about 170 00:08:04.040 --> 00:08:09.480 often involve exploits targeting memory corruption, including stack and heap overflows. 171 00:08:09.759 --> 00:08:11.399 So this isn't just academic stuff. 172 00:08:11.439 --> 00:08:13.519 This is the real deal, absolutely, and that's why it's 173 00:08:13.560 --> 00:08:16.480 also important to understand these ideas, not just for developers 174 00:08:16.959 --> 00:08:20.319 but for everyone who uses technology. The more we know 175 00:08:20.399 --> 00:08:23.519 about how these attacks work, the better we can protect ourselves. 176 00:08:23.600 --> 00:08:27.920 All Right, so we've explored those treacherous stack overflows. Now 177 00:08:27.959 --> 00:08:30.680 let's head into this shadowy world of heap corruption. You 178 00:08:30.720 --> 00:08:33.279 were saying before that the heap is like, yeah, a 179 00:08:33.320 --> 00:08:36.759 massive warehouse for dynamic memory allocation. What does that even mean? 180 00:08:37.240 --> 00:08:40.240 It's all about flexibility really. Unlike the stack, which is 181 00:08:40.279 --> 00:08:43.320 more like like a neat pantry with those shelves already 182 00:08:43.360 --> 00:08:45.159 set up, right, the heap is more like a self 183 00:08:45.159 --> 00:08:48.600 storage place where programs can you know, rent different sized 184 00:08:48.679 --> 00:08:49.840 units whenever they need them. 185 00:08:50.039 --> 00:08:54.080 So it's more chaotic, yeah, unpredictable. 186 00:08:53.600 --> 00:08:57.240 Then the stack, yeah, exactly. And it's this dynamic nature 187 00:08:57.320 --> 00:09:00.720 that makes managing the heap so much more complex and 188 00:09:00.879 --> 00:09:04.759 as a result, more vulnerable. The book actually goes into 189 00:09:04.879 --> 00:09:08.919 how the heap works, focusing on functions like malik, calk, 190 00:09:08.960 --> 00:09:09.519 and realic. 191 00:09:09.639 --> 00:09:12.080 Right. Those are the functions that programs use to interact 192 00:09:12.120 --> 00:09:14.720 with the heap, right, like placing an order for one 193 00:09:14.720 --> 00:09:16.279 of those storage units exactly. 194 00:09:16.279 --> 00:09:20.200 Malik is basically like requesting a unit of a specific size. 195 00:09:20.360 --> 00:09:22.679 Klik is similar, but it also asks for the unit 196 00:09:22.720 --> 00:09:25.240 to be you know, cleaned out and set to zero 197 00:09:25.440 --> 00:09:28.159 like getting a freshly painted room. And realic is like 198 00:09:28.240 --> 00:09:30.600 asking to change the size of your unit, you know, 199 00:09:30.639 --> 00:09:33.480 maybe make it bigger for more stuff or smaller to 200 00:09:33.519 --> 00:09:34.279 save some space. 201 00:09:34.759 --> 00:09:37.000 Okay, so where do the vulnerabilities fitting with all this? 202 00:09:37.120 --> 00:09:40.000 Is it like stack overflows where attackers just try to 203 00:09:40.039 --> 00:09:41.639 cram too much data into a space. 204 00:09:41.720 --> 00:09:45.000 The basic cause is similar, yeah, overflowing those buffers, manipulating 205 00:09:45.000 --> 00:09:47.679 the data structures, but the way it's done on the 206 00:09:47.720 --> 00:09:50.679 heap is different. It's not just about overflowing one buffer, 207 00:09:50.720 --> 00:09:54.080 it's about exploiting the whole system that manages the heap itself. 208 00:09:54.360 --> 00:09:56.639 The book keeps mentioning something called dunalik. 209 00:09:57.159 --> 00:10:00.080 Want think of demolic as like the manager of this 210 00:10:00.399 --> 00:10:04.759 self storage place. It's a common way to implement heat memory, 211 00:10:05.039 --> 00:10:08.320 and it's what the Linux glip heap management is based on. 212 00:10:08.440 --> 00:10:10.240 It keeps track of all the units, knows which ones 213 00:10:10.279 --> 00:10:12.639 are being used, which are free, and how much space 214 00:10:12.720 --> 00:10:13.120 is left. 215 00:10:13.360 --> 00:10:16.840 So it's the one organizing and giving out space on 216 00:10:16.879 --> 00:10:17.919 the heap exactly. 217 00:10:18.120 --> 00:10:21.559 And Demolic tries to be efficient. It consolidates free space, 218 00:10:21.679 --> 00:10:24.360 like merging empty units to make bigger blocks. It's kind 219 00:10:24.360 --> 00:10:27.399 of like tidying up the whole facility, you know, making 220 00:10:27.399 --> 00:10:29.000 sure there's enough room for new customers. 221 00:10:29.559 --> 00:10:31.679 So that sounds like a good thing. Being efficient is 222 00:10:31.840 --> 00:10:36.440 usually good, but you're making it sound like like this 223 00:10:36.480 --> 00:10:38.000 is where vulnerabilities top up. 224 00:10:38.039 --> 00:10:41.360 See that's the interesting thing about security. Sometimes those well 225 00:10:41.360 --> 00:10:44.639 intentioned features can be exploited. In the case of Demolk, 226 00:10:44.720 --> 00:10:51.759 this consolidation process can be manipulated well. By carefully crafting 227 00:10:51.799 --> 00:10:55.919 their input, attackers can make these fake memory chunks right 228 00:10:55.960 --> 00:10:58.799 there in the heap. It's like forging a rental agreement 229 00:10:59.399 --> 00:11:02.480 for unit that doesn't even exist, and then they trigger 230 00:11:02.519 --> 00:11:07.440 the consolidation, tricking Dulmalik into merging these fake chunks with 231 00:11:07.519 --> 00:11:08.080 real ones. 232 00:11:08.159 --> 00:11:10.600 So it's like, yeah, creating a ghost unit and then 233 00:11:10.600 --> 00:11:13.519 causing this chain reaction that messes up the whole facility. 234 00:11:13.600 --> 00:11:16.720 Yeah, that's a great analogy. And during this, during this 235 00:11:16.919 --> 00:11:21.080 merging chaos, attackers can overwrite those critical pointers, those street 236 00:11:21.120 --> 00:11:22.960 signs we talked about earlier, the ones that tell the 237 00:11:22.960 --> 00:11:24.320 program where to go in memory. 238 00:11:24.440 --> 00:11:27.519 So they're hijacking the program by messing with the organization 239 00:11:27.559 --> 00:11:30.840 of the heat. That's ye, incredibly clever, but also a bit. 240 00:11:30.759 --> 00:11:33.559 Scary it is, And to make things even harder, the 241 00:11:33.639 --> 00:11:36.960 layout and behavior of the heat can change aliqally depending 242 00:11:37.000 --> 00:11:40.039 on the heat manager, the operating system, even the compiler 243 00:11:40.080 --> 00:11:40.600 that's used. 244 00:11:40.679 --> 00:11:43.360 It's like, eh, each self storage place has its own 245 00:11:43.399 --> 00:11:46.559 quirks and weaknesses, making it harder to find one exploit 246 00:11:46.600 --> 00:11:47.279 that works. 247 00:11:47.039 --> 00:11:52.279 Everywhere precisely, heapoverflows are notorious for being inconsistent and tougher 248 00:11:52.320 --> 00:11:56.279 to exploit than those stack overflows. They often need, you know, 249 00:11:56.919 --> 00:11:59.519 a really deep understanding of the target system and a 250 00:11:59.559 --> 00:12:00.639 lot of and error. 251 00:12:01.159 --> 00:12:05.039 This is getting into some pretty advanced hacking stuff. But 252 00:12:05.080 --> 00:12:06.399 before we go to deep, but I want to bring 253 00:12:06.399 --> 00:12:08.399 it back to our listeners for a sec. Why should 254 00:12:08.440 --> 00:12:11.440 they care about this heat corruption? How does it affect 255 00:12:11.480 --> 00:12:12.759 them in their everyday lives. 256 00:12:13.000 --> 00:12:15.559 That's a great question and is important to connect these 257 00:12:15.559 --> 00:12:18.799 ideas to the real world. You know, heap corruption vulnerabilities 258 00:12:18.840 --> 00:12:22.600 can affect all sorts of software, from web browsers and 259 00:12:22.639 --> 00:12:27.080 email clients to operating systems and critical infrastructure. 260 00:12:27.120 --> 00:12:31.320 So any software that uses dynamic memory allocation is potentially 261 00:12:31.320 --> 00:12:31.679 at risk. 262 00:12:31.759 --> 00:12:35.440 Yeah, exactly, And when these vulnerabilities are exploited, the consequences 263 00:12:35.480 --> 00:12:39.279 can be pretty severe, ranging from data breaches and system 264 00:12:39.320 --> 00:12:43.000 crashes to denial of service attacks and even remote code 265 00:12:43.039 --> 00:12:46.039 execution where the attacker gets full control of your system. 266 00:12:46.440 --> 00:12:49.519 That's definitely something to worry about. So while heat exploitation 267 00:12:49.639 --> 00:12:52.720 might be more complex than stack overflows, it's no less. 268 00:12:52.600 --> 00:12:55.799 Dangerous, absolutely, and it really highlights how important it is 269 00:12:56.080 --> 00:13:01.600 to have secure coding practices, robust input valid and to 270 00:13:01.759 --> 00:13:05.559 use security tools to find and fix these vulnerabilities. But 271 00:13:05.639 --> 00:13:08.159 before we dive into those defensive strategies, there's another type 272 00:13:08.159 --> 00:13:11.320 of vulnerability we should talk about format string attacks. 273 00:13:11.480 --> 00:13:17.240 Format string attacks those sound a bit more subtle. What 274 00:13:17.279 --> 00:13:18.080 are those all about? 275 00:13:18.240 --> 00:13:21.519 They are more subtle, yeah, but no less dangerous. Format 276 00:13:21.559 --> 00:13:24.799 string attacks take advantage of the way certain functions handle output, 277 00:13:25.200 --> 00:13:27.120 like the print OFFF function. 278 00:13:27.240 --> 00:13:30.759 And see it's familiar if that function used to to 279 00:13:30.799 --> 00:13:33.039 show text on the screen, right, like the classic Hello 280 00:13:33.120 --> 00:13:34.039 World cosipe. 281 00:13:34.120 --> 00:13:36.039 It's used in tons of programs, and the way it 282 00:13:36.039 --> 00:13:37.879 works is you give it a format string that says 283 00:13:37.879 --> 00:13:40.120 how you want the output to look, using these special 284 00:13:40.200 --> 00:13:43.440 characters called format specifiers. 285 00:13:42.840 --> 00:13:45.480 Like using percents to put in some text for percents 286 00:13:45.480 --> 00:13:45.879 of put in. 287 00:13:45.799 --> 00:13:48.840 A number exactly. And the vulnerability happens when a program 288 00:13:48.919 --> 00:13:51.879 doesn't check user input properly. That's being used as the 289 00:13:51.919 --> 00:13:53.919 format string and a function like print OFFF. 290 00:13:54.159 --> 00:13:57.320 So if an attacker can control that format string, they 291 00:13:57.360 --> 00:14:01.840 can mess with the output of the program. Is that 292 00:14:01.879 --> 00:14:02.840 the main danger. 293 00:14:02.519 --> 00:14:05.559 Here, It's actually much more serious than that, by carefully 294 00:14:05.639 --> 00:14:09.399 crafting that format string, attackers can force the program to 295 00:14:09.519 --> 00:14:13.600 read or even write data to specific memory locations. 296 00:14:13.679 --> 00:14:15.240 We hold on, how is that even possible? 297 00:14:15.240 --> 00:14:18.759 It's just like text, right, It's all about how Print 298 00:14:19.000 --> 00:14:22.600 and functions like it interpret that format string. They expect 299 00:14:22.639 --> 00:14:26.200 the string to be followed by, you know, a certain 300 00:14:26.240 --> 00:14:28.600 number of arguments the data that needs to be formatted 301 00:14:28.600 --> 00:14:31.600 and displayed. But if an attacker gives a format string 302 00:14:31.960 --> 00:14:35.200 without those expected arguments, the function just starts grabbing whatever 303 00:14:35.240 --> 00:14:39.039 it can from the stack, potentially revealing sensitive information. 304 00:14:39.279 --> 00:14:43.600 So it's like print is blindly grabbing ingredients hoping to 305 00:14:43.600 --> 00:14:45.799 find what it needs, and the attacker gets to control 306 00:14:45.799 --> 00:14:46.279 what's in there. 307 00:14:46.360 --> 00:14:48.639 Yeah, that's a great way to picture it. And by 308 00:14:48.720 --> 00:14:52.480 using certain format specifiers like percent send to print those 309 00:14:52.519 --> 00:14:55.519 hexadecimal values, an attacker can go through the stack leaking 310 00:14:55.559 --> 00:14:59.039 stuff like passwords, encryption keys, even other pieces of code. 311 00:14:59.240 --> 00:15:03.679 Sneaky, But how do they actually write data to memory 312 00:15:04.399 --> 00:15:05.440 using a format string. 313 00:15:05.840 --> 00:15:08.639 That's where the percent format specifier comes in. It's not 314 00:15:08.799 --> 00:15:11.399 that well known, but it lets you write the number 315 00:15:11.399 --> 00:15:15.080 of characters printed so far to a memory address pointed 316 00:15:15.120 --> 00:15:16.039 to by an argument. 317 00:15:16.200 --> 00:15:19.159 So if the attacker controls that format string. They can 318 00:15:19.240 --> 00:15:22.120 use three tamed percent to overwrite a specific memory address 319 00:15:22.559 --> 00:15:24.799 with a value that's based on how many characters were 320 00:15:24.799 --> 00:15:25.360 printed before. 321 00:15:25.559 --> 00:15:28.279 Exactly. It's like this hidden weapon in the print arsenal, 322 00:15:28.600 --> 00:15:30.600 and the book has a great example of how an 323 00:15:30.639 --> 00:15:33.240 attacker can use this to change a variable's value on 324 00:15:33.279 --> 00:15:37.120 the stack, potentially changing how the program behaves or even 325 00:15:37.159 --> 00:15:38.559 taking over its control flow. 326 00:15:38.679 --> 00:15:40.519 That's a good wle. It's not just about crashing the 327 00:15:40.519 --> 00:15:43.559 program anymore. It's about controlling it at such a granular. 328 00:15:43.200 --> 00:15:46.200 Level exactly, the possibilities are pretty much endless. The book 329 00:15:46.200 --> 00:15:50.279 even touches on more advanced techniques like overwriting the global 330 00:15:50.279 --> 00:15:54.159 offset table or goot to hijack function calls. 331 00:15:54.279 --> 00:15:55.159 GOT what's that? 332 00:15:55.480 --> 00:15:58.080 Think of the GOT as the phone book for the program. 333 00:15:58.360 --> 00:16:00.879 It stores the addresses of all the functions the program 334 00:16:00.960 --> 00:16:02.840 needs to call, like you know, looking up a number 335 00:16:02.840 --> 00:16:03.399 to make a call. 336 00:16:03.559 --> 00:16:06.720 Okay, So it's a directory of like yeah, important functions. 337 00:16:06.320 --> 00:16:10.519 Exactly, And by overwriting entries in that directory, an attacker 338 00:16:10.639 --> 00:16:14.080 can redirect those function calls to their own malicious code. 339 00:16:14.120 --> 00:16:16.360 It's like changing the phone number in the book. So 340 00:16:16.399 --> 00:16:18.879 when the program tries to call a function, it ends 341 00:16:18.960 --> 00:16:21.960 up calling the attackers code instead, so they're like. 342 00:16:21.960 --> 00:16:25.639 Uh yeah, rewiring the program's communication system precisely. 343 00:16:25.799 --> 00:16:29.879 And this level of control shows why knowing assembly language 344 00:16:29.879 --> 00:16:32.879 is so powerful for both attackers and defenders. It's the 345 00:16:33.000 --> 00:16:36.679 key to understanding and manipulating these low level mechanics. 346 00:16:37.240 --> 00:16:39.600 This is getting really deep into how a program works. 347 00:16:40.080 --> 00:16:43.440 But I see how dangerous these formats string vulnerabilities can be. 348 00:16:43.720 --> 00:16:45.559 That are like these hidden traps just waiting. 349 00:16:46.000 --> 00:16:48.200 They are, And the scary part is they can be 350 00:16:48.279 --> 00:16:51.759 hiding in code that seems perfectly normal. Any program that 351 00:16:51.879 --> 00:16:55.480 uses user input to make a format string is potentially vulnerable, 352 00:16:55.559 --> 00:16:55.759 so we. 353 00:16:55.799 --> 00:16:58.639 Got to be careful. Developers need to be really careful 354 00:16:58.879 --> 00:17:01.519 about how they handle you or input and how they 355 00:17:01.600 --> 00:17:02.519 use functions like print. 356 00:17:02.720 --> 00:17:06.039 Absolutely, but format string attacks aren't the only type of 357 00:17:06.079 --> 00:17:09.960 vulnerability out there. The book also talks about things like 358 00:17:10.079 --> 00:17:13.720 race conditions and TCPIP vulnerability. 359 00:17:13.880 --> 00:17:15.039 Race conditions what are those? 360 00:17:15.240 --> 00:17:19.160 Imagine a program where two parts of the code are 361 00:17:19.200 --> 00:17:21.519 running at the same time, like two runners in a race, right, 362 00:17:21.519 --> 00:17:24.240 They're both trying to access the same resource. A race 363 00:17:24.279 --> 00:17:27.279 condition happens when the outcome depends on which one wins. 364 00:17:27.319 --> 00:17:31.759 So it's all about like timing and unpredictable behavior exactly. 365 00:17:32.160 --> 00:17:35.759 Attackers try to manipulate the timing to make the program 366 00:17:35.799 --> 00:17:38.799 do something based on information that's outdated or wrong. It's 367 00:17:38.799 --> 00:17:40.759 like tripping one of the runners, so the other one 368 00:17:40.799 --> 00:17:42.079 wins even if they shouldn't have. 369 00:17:42.200 --> 00:17:45.799 So it's about causing like chaos and confusion within the 370 00:17:45.799 --> 00:17:46.720 program precisely. 371 00:17:46.759 --> 00:17:48.920 And the book gives an example of a race condition 372 00:17:49.400 --> 00:17:53.759 in the sun mail program where an attacker exploited a 373 00:17:53.880 --> 00:17:57.039 double free heap corruption bug because of a race condition 374 00:17:57.119 --> 00:17:58.279 with a signal. 375 00:17:57.920 --> 00:18:00.720 Handle is not a core part of a lot of 376 00:18:00.759 --> 00:18:01.960 email systems. 377 00:18:01.559 --> 00:18:04.039 It is, and that's what makes these vulnerabilities so dangerous. 378 00:18:04.079 --> 00:18:06.599 They can affect critical software that we use every day. 379 00:18:06.799 --> 00:18:09.880 Okay, so what about these TCPIP vulnerabilities? What are those? 380 00:18:10.200 --> 00:18:16.000 Those are vulnerabilities that target weaknesses in the TCPIP protocols, 381 00:18:16.160 --> 00:18:17.880 which is, you know, the foundation of the Internet. 382 00:18:18.039 --> 00:18:20.599 So attacks that target, yes, the very structure of the 383 00:18:20.599 --> 00:18:21.359 Internet exactly. 384 00:18:21.400 --> 00:18:25.119 A classic example is the land attack, which takes advantage 385 00:18:25.119 --> 00:18:29.359 of how tcpsyn packets are handled by sending a especially 386 00:18:29.400 --> 00:18:32.519 made packet with the target's own IP address. As both 387 00:18:32.559 --> 00:18:38.279 source and destination. The attacker can cause a denial of service. 388 00:18:38.400 --> 00:18:41.519 Denial of service they're trying to like crash the system. 389 00:18:41.720 --> 00:18:45.480 Yeah, precisely by flooding the target with these bad packets. 390 00:18:45.519 --> 00:18:48.480 They overload it and make it unavailable to legitimate users. 391 00:18:48.640 --> 00:18:53.400 So we've got memory corruption, format string attacks, race conditions, 392 00:18:53.480 --> 00:18:57.160 TCPIP vulnerabilities. It's like a whole arsenal of attack vectors. 393 00:18:57.359 --> 00:18:58.880 Still overwhelming, honestly, it can be. 394 00:18:59.000 --> 00:19:01.400 Yeah, but remember, oh, our knowledge is power. Now that 395 00:19:01.440 --> 00:19:04.000 you understand how these attacks work, we can start building 396 00:19:04.039 --> 00:19:06.519 up our defenses, and that's what we'll explore in the 397 00:19:06.559 --> 00:19:08.160 next part of our deep dive. We'll look at the 398 00:19:08.200 --> 00:19:11.000 strategies and tools that can help us protect ourselves from 399 00:19:11.039 --> 00:19:11.599 these slads. 400 00:19:11.880 --> 00:19:14.920 I'm ready for it. Let's build those defenses, all right. 401 00:19:14.960 --> 00:19:19.039