WEBVTT 1 00:00:00.110 --> 00:00:01.920 In this lesson, we will learn 2 00:00:01.920 --> 00:00:05.010 about memory-related vulnerabilities. 3 00:00:05.010 --> 00:00:08.520 Memory-related vulnerabilities refer to flaws 4 00:00:08.520 --> 00:00:11.400 in how an application handles memory, 5 00:00:11.400 --> 00:00:15.870 potentially allowing attackers to execute malicious code, 6 00:00:15.870 --> 00:00:19.800 cause crashes, or leak sensitive information. 7 00:00:19.800 --> 00:00:24.420 Memory-related vulnerabilities include deprecated functions, 8 00:00:24.420 --> 00:00:29.420 unsafe memory utilization, overflows, race conditions, 9 00:00:29.550 --> 00:00:33.840 and time of check to time of use vulnerabilities. 10 00:00:33.840 --> 00:00:37.680 Deprecated functions are older, insecure functions 11 00:00:37.680 --> 00:00:39.390 that are still in use. 12 00:00:39.390 --> 00:00:41.760 The use of deprecated functions can lead 13 00:00:41.760 --> 00:00:45.720 to unsafe memory utilization and expose a system 14 00:00:45.720 --> 00:00:49.170 to vulnerabilities like buffer overflows. 15 00:00:49.170 --> 00:00:52.568 In a buffer overflow attack, an attacker overflows 16 00:00:52.568 --> 00:00:56.880 a memory buffer to overwrite adjacent memory, 17 00:00:56.880 --> 00:01:00.240 and over overflow attack can lead to the execution 18 00:01:00.240 --> 00:01:03.056 of arbitrary code, allowing the attacker 19 00:01:03.056 --> 00:01:07.110 to take control of the system, corrupt data 20 00:01:07.110 --> 00:01:09.930 or crash the application entirely. 21 00:01:09.930 --> 00:01:12.900 Overflows and unsafe memory usage 22 00:01:12.900 --> 00:01:16.410 often create opportunities for race conditions. 23 00:01:16.410 --> 00:01:19.260 A race condition occurs when the timing 24 00:01:19.260 --> 00:01:23.400 of operations is manipulated to exploit the system. 25 00:01:23.400 --> 00:01:26.760 Specifically, a race condition can occur 26 00:01:26.760 --> 00:01:28.710 when two processes attempt 27 00:01:28.710 --> 00:01:31.778 to modify the same data concurrently leading 28 00:01:31.778 --> 00:01:34.421 to unpredictable results, such 29 00:01:34.421 --> 00:01:39.360 as a financial transaction being processed twice. 30 00:01:39.360 --> 00:01:44.040 A specific type of race condition is a time of check to time 31 00:01:44.040 --> 00:01:45.870 of use condition. 32 00:01:45.870 --> 00:01:49.920 To exploit a time of check to time of use vulnerability, 33 00:01:49.920 --> 00:01:52.860 an attacker may change the system's state 34 00:01:52.860 --> 00:01:55.950 between the time the system checks a condition 35 00:01:55.950 --> 00:01:59.160 and the time it uses the result leading 36 00:01:59.160 --> 00:02:01.470 to unexpected behavior. 37 00:02:01.470 --> 00:02:04.740 Let's learn more about deprecated functions, 38 00:02:04.740 --> 00:02:09.480 unsafe memory utilization, overflows, race conditions, 39 00:02:09.480 --> 00:02:13.140 and time of check to time of use vulnerabilities. 40 00:02:13.140 --> 00:02:16.470 First, we have deprecated functions. 41 00:02:16.470 --> 00:02:19.740 Deprecated functions are functions or commands 42 00:02:19.740 --> 00:02:22.500 in programming languages or libraries 43 00:02:22.500 --> 00:02:25.380 that are no longer recommended for use 44 00:02:25.380 --> 00:02:27.720 and often lack the security features 45 00:02:27.720 --> 00:02:30.150 of their modern counterparts. 46 00:02:30.150 --> 00:02:34.080 These functions may still work within the application, 47 00:02:34.080 --> 00:02:36.171 but are outdated, meaning they don't 48 00:02:36.171 --> 00:02:39.090 meet current security standards. 49 00:02:39.090 --> 00:02:42.240 Developers keep deprecated functions around 50 00:02:42.240 --> 00:02:44.430 for compatibility reasons, 51 00:02:44.430 --> 00:02:48.120 but over time, these functions should be removed 52 00:02:48.120 --> 00:02:51.360 from programming libraries altogether. 53 00:02:51.360 --> 00:02:56.010 In software security, deprecated functions become a problem 54 00:02:56.010 --> 00:02:59.400 because they often lack protection mechanisms such 55 00:02:59.400 --> 00:03:03.900 as input, validation, or memory safety, which can lead 56 00:03:03.900 --> 00:03:05.850 to injection attacks. 57 00:03:05.850 --> 00:03:07.170 For example, 58 00:03:07.170 --> 00:03:10.950 in the C programming language, functions like gets () 59 00:03:10.950 --> 00:03:15.030 for reading strings do not have built-in buffer size 60 00:03:15.030 --> 00:03:19.620 checks potentially leading to buffer overflow attacks. 61 00:03:19.620 --> 00:03:22.290 In contrast, modern alternatives 62 00:03:22.290 --> 00:03:25.050 like fgets () allows developers 63 00:03:25.050 --> 00:03:29.850 to specify buffer size, reducing the overflow risk. 64 00:03:29.850 --> 00:03:34.110 Second, we have unsafe memory utilization. 65 00:03:34.110 --> 00:03:39.000 Unsafe memory utilization occurs when an application fails 66 00:03:39.000 --> 00:03:43.350 to manage memory correctly leading to vulnerabilities such 67 00:03:43.350 --> 00:03:46.890 as buffer overflows, and memory leaks. 68 00:03:46.890 --> 00:03:48.521 A memory leak is a condition 69 00:03:48.521 --> 00:03:52.710 in which a program continuously allocates memory 70 00:03:52.710 --> 00:03:55.691 without releasing it, eventually exhausting all 71 00:03:55.691 --> 00:03:58.728 available memory and causing the application 72 00:03:58.728 --> 00:04:02.700 or system to slow down or crash. 73 00:04:02.700 --> 00:04:07.089 One of the biggest dangers of unsafe memory utilization is 74 00:04:07.089 --> 00:04:10.825 that it can grant attackers access to critical areas 75 00:04:10.825 --> 00:04:13.170 in memory, allowing them 76 00:04:13.170 --> 00:04:17.400 to execute arbitrary code, escalate privileges 77 00:04:17.400 --> 00:04:20.515 or access sensitive information, usually 78 00:04:20.515 --> 00:04:24.660 through overflow attacks, which will be discussed next. 79 00:04:24.660 --> 00:04:28.534 To protect against unsafe memory practices, developers 80 00:04:28.534 --> 00:04:33.534 should implement strict memory checks, validate user input, 81 00:04:33.570 --> 00:04:35.760 and use programming languages 82 00:04:35.760 --> 00:04:38.640 that manage memory more securely. 83 00:04:38.640 --> 00:04:40.170 Additionally, tools 84 00:04:40.170 --> 00:04:43.260 like Address Space Layout Randomization 85 00:04:43.260 --> 00:04:46.179 and Data Execution Protection can help reduce 86 00:04:46.179 --> 00:04:50.010 the effectiveness of memory based attacks. 87 00:04:50.010 --> 00:04:53.610 Address Space Layout Randomization randomizes 88 00:04:53.610 --> 00:04:56.760 the memory addresses used by the system 89 00:04:56.760 --> 00:05:01.050 and application processes, making it harder for attackers 90 00:05:01.050 --> 00:05:04.620 to predict where to inject malicious code. 91 00:05:04.620 --> 00:05:09.570 Next, Data Execution Protection prevents executable code 92 00:05:09.570 --> 00:05:12.420 from running in certain areas of memory 93 00:05:12.420 --> 00:05:16.020 that should only store data blocking attacks 94 00:05:16.020 --> 00:05:18.960 that attempt to execute harmful instructions 95 00:05:18.960 --> 00:05:21.360 from these protected regions. 96 00:05:21.360 --> 00:05:25.050 Together, Address Space Layout Randomization, 97 00:05:25.050 --> 00:05:28.380 and Data Execution Protection add layers 98 00:05:28.380 --> 00:05:31.380 of protection against memory exploits 99 00:05:31.380 --> 00:05:34.110 by disrupting common attack patterns 100 00:05:34.110 --> 00:05:37.380 and restricting executable permissions. 101 00:05:37.380 --> 00:05:40.200 Third, we have overflows. 102 00:05:40.200 --> 00:05:42.900 Let's discuss overflow vulnerabilities 103 00:05:42.900 --> 00:05:47.900 in two categories, buffer overflows and integer overflows. 104 00:05:48.750 --> 00:05:52.080 A buffer overflow occurs when a program tries 105 00:05:52.080 --> 00:05:56.370 to store data outside the designated memory range 106 00:05:56.370 --> 00:05:59.640 or "buffer" allocated by the code. 107 00:05:59.640 --> 00:06:02.370 Think of a buffer like a cup designated 108 00:06:02.370 --> 00:06:05.610 to hold only 16 ounces of liquid. 109 00:06:05.610 --> 00:06:09.543 If you pour in 20 ounces, the cup overflows spilling 110 00:06:09.543 --> 00:06:11.730 onto the table. 111 00:06:11.730 --> 00:06:15.150 Here, the cup represents the memory buffer 112 00:06:15.150 --> 00:06:17.638 and any excess data spills out 113 00:06:17.638 --> 00:06:21.270 of the buffer potentially causing disruptions 114 00:06:21.270 --> 00:06:23.880 or even security breaches. 115 00:06:23.880 --> 00:06:27.090 For instance, storing a 10 digit phone number 116 00:06:27.090 --> 00:06:30.660 in a buffer meant only for eight digits would cause 117 00:06:30.660 --> 00:06:34.980 the last two digits to overflow into adjacent memory, 118 00:06:34.980 --> 00:06:37.500 corrupting the data that is stored there. 119 00:06:37.500 --> 00:06:42.180 Attackers exploit this overflow effect to manipulate memory 120 00:06:42.180 --> 00:06:45.690 and potentially execute malicious commands. 121 00:06:45.690 --> 00:06:47.910 To fully understand this, we need 122 00:06:47.910 --> 00:06:50.760 to see how a program manages memory. 123 00:06:50.760 --> 00:06:53.550 When a program launches, it reserves an area 124 00:06:53.550 --> 00:06:57.780 of memory called the stack, which stores essential data 125 00:06:57.780 --> 00:07:01.050 like the return address for function calls. 126 00:07:01.050 --> 00:07:03.840 If an attacker overfills this stack, 127 00:07:03.840 --> 00:07:06.630 they can overwrite the return address 128 00:07:06.630 --> 00:07:09.720 with one pointing to their malicious code. 129 00:07:09.720 --> 00:07:12.870 This manipulation is called stack smashing 130 00:07:12.870 --> 00:07:16.316 and often involves a technique called a NOP 131 00:07:16.316 --> 00:07:21.180 or NOP Slide where attackers fill the stacks with NOPs 132 00:07:21.180 --> 00:07:24.390 where NOP stands for no operation 133 00:07:24.390 --> 00:07:27.150 and is interpreted as do nothing. 134 00:07:27.150 --> 00:07:29.640 The NOP instructions create a path 135 00:07:29.640 --> 00:07:32.730 or a slide that directs program control 136 00:07:32.730 --> 00:07:34.770 to the attacker's code. 137 00:07:34.770 --> 00:07:37.710 An integer overflow on the other hand, 138 00:07:37.710 --> 00:07:40.950 occurs when a mathematical result exceeds 139 00:07:40.950 --> 00:07:43.830 the storage capacity of its variable. 140 00:07:43.830 --> 00:07:47.700 Unlike buffer overflows, integer overflows happen 141 00:07:47.700 --> 00:07:51.030 within a variables designated range. 142 00:07:51.030 --> 00:07:53.370 For example, a storage space 143 00:07:53.370 --> 00:07:57.630 with only two digits caps out at the number 99, 144 00:07:57.630 --> 00:08:01.410 so adding 90 and 17 would produce an answer 145 00:08:01.410 --> 00:08:05.700 of 107, which is too large for the variable. 146 00:08:05.700 --> 00:08:08.760 This overflow typically causes the value 147 00:08:08.760 --> 00:08:10.248 to wrap around, changing, 148 00:08:10.248 --> 00:08:15.030 for instance, a positive number into a negative number. 149 00:08:15.030 --> 00:08:17.580 Attackers can use integer overflows 150 00:08:17.580 --> 00:08:20.850 to alter buffer boundaries, potentially leading 151 00:08:20.850 --> 00:08:23.430 to buffer overflow attacks. 152 00:08:23.430 --> 00:08:27.360 Preventing these vulnerabilities requires boundary checks 153 00:08:27.360 --> 00:08:29.670 and secure coding practices, 154 00:08:29.670 --> 00:08:32.970 including choosing suitable variable sizes 155 00:08:32.970 --> 00:08:36.210 and validating all data inputs. 156 00:08:36.210 --> 00:08:39.240 Fourth, we have race conditions. 157 00:08:39.240 --> 00:08:42.720 A race condition is a software vulnerability 158 00:08:42.720 --> 00:08:44.092 that occurs when the outcome 159 00:08:44.092 --> 00:08:48.150 of executing processes depends on the timing 160 00:08:48.150 --> 00:08:50.820 and order of certain events, 161 00:08:50.820 --> 00:08:55.710 but those events do not execute as the developer intended. 162 00:08:55.710 --> 00:08:58.950 Essentially, this means the system is racing 163 00:08:58.950 --> 00:09:01.200 to complete multiple processes 164 00:09:01.200 --> 00:09:05.580 at the same time leading to unpredictable results 165 00:09:05.580 --> 00:09:08.280 if an attacker interferes with the timing 166 00:09:08.280 --> 00:09:10.380 of these operations. 167 00:09:10.380 --> 00:09:13.770 For instance, if a legitimate user action 168 00:09:13.770 --> 00:09:16.470 and an attacker's action are processed 169 00:09:16.470 --> 00:09:18.990 at the same time, the attacker 170 00:09:18.990 --> 00:09:22.050 may get their request executed first, 171 00:09:22.050 --> 00:09:25.830 exploiting the race condition to achieve their goal. 172 00:09:25.830 --> 00:09:29.720 Race conditions commonly occur when multiple threads attempt 173 00:09:29.720 --> 00:09:34.530 to access or modify shared resources simultaneously 174 00:09:34.530 --> 00:09:37.200 without proper synchronization. 175 00:09:37.200 --> 00:09:38.640 A well-known example 176 00:09:38.640 --> 00:09:43.110 of a race condition exploit is the Dirty COW vulnerability, 177 00:09:43.110 --> 00:09:45.417 a privilege escalation attack on Linux 178 00:09:45.417 --> 00:09:50.130 and Android systems discovered in 2016. 179 00:09:50.130 --> 00:09:53.970 Dirty COW exploited a flaw in the Linux copy 180 00:09:53.970 --> 00:09:57.570 on write mechanism, a memory management function, 181 00:09:57.570 --> 00:10:01.140 allowing attackers to escalate their privileges 182 00:10:01.140 --> 00:10:04.560 by turning read only access to files 183 00:10:04.560 --> 00:10:08.280 into write access, despite system protections. 184 00:10:08.280 --> 00:10:12.870 This exploit was particularly dangerous as it left no traces 185 00:10:12.870 --> 00:10:17.040 in system logs making it difficult to detect. 186 00:10:17.040 --> 00:10:21.101 So race conditions like Dirty COW can affect various 187 00:10:21.101 --> 00:10:26.101 resources including memory management systems, databases, 188 00:10:26.160 --> 00:10:28.110 and file systems. 189 00:10:28.110 --> 00:10:30.480 To defend against race conditions, 190 00:10:30.480 --> 00:10:34.320 developers can implement proper synchronization techniques 191 00:10:34.320 --> 00:10:37.620 such as locking mechanisms to control access 192 00:10:37.620 --> 00:10:40.912 to shared resources, and ensure events occur 193 00:10:40.912 --> 00:10:43.680 in the intended sequence. 194 00:10:43.680 --> 00:10:47.100 Fifth and last, we have a time of check 195 00:10:47.100 --> 00:10:49.830 to time of use vulnerability. 196 00:10:49.830 --> 00:10:50.950 This specific type 197 00:10:50.950 --> 00:10:54.510 of race condition occurs when there is a delay 198 00:10:54.510 --> 00:10:58.410 between an applications, a verification of a resource, 199 00:10:58.410 --> 00:11:03.030 which is the check, and its subsequent use of that resource, 200 00:11:03.030 --> 00:11:04.650 which is the use. 201 00:11:04.650 --> 00:11:09.000 During this gap, if the resource or data is modified, 202 00:11:09.000 --> 00:11:12.270 it may no longer meet the original requirements 203 00:11:12.270 --> 00:11:17.010 or security checks established at the time of verification. 204 00:11:17.010 --> 00:11:20.730 This can allow attackers to exploit the delay 205 00:11:20.730 --> 00:11:24.360 to manipulate data, bypass security checks, 206 00:11:24.360 --> 00:11:26.940 or gain unauthorized access. 207 00:11:26.940 --> 00:11:29.610 For example, consider a system where 208 00:11:29.610 --> 00:11:33.660 a user requests permission to edit a file. 209 00:11:33.660 --> 00:11:37.950 The application checks if the user has the right permissions 210 00:11:37.950 --> 00:11:39.840 to access that file. 211 00:11:39.840 --> 00:11:43.710 This is the check, and then allows them to open 212 00:11:43.710 --> 00:11:47.340 or modify the file, this is the use. 213 00:11:47.340 --> 00:11:51.270 In a time of check to time of use attack, an attacker 214 00:11:51.270 --> 00:11:54.810 with lower privileges could time their request 215 00:11:54.810 --> 00:11:59.220 to replace the target file with another sensitive file 216 00:11:59.220 --> 00:12:01.230 after the permission check, 217 00:12:01.230 --> 00:12:03.990 but before the system grants access. 218 00:12:03.990 --> 00:12:07.045 As a result, they may gain unauthorized access 219 00:12:07.045 --> 00:12:10.920 to files they otherwise wouldn't be able to modify. 220 00:12:10.920 --> 00:12:12.596 To mitigate time of check to time 221 00:12:12.596 --> 00:12:16.620 of use vulnerabilities, developers can use locks 222 00:12:16.620 --> 00:12:19.230 and mutexes to control access 223 00:12:19.230 --> 00:12:22.140 to resources during processing. 224 00:12:22.140 --> 00:12:25.950 A mutex, which is short for Mutual Exclusion, 225 00:12:25.950 --> 00:12:27.660 is a locking mechanism 226 00:12:27.660 --> 00:12:30.579 that ensures only one thread can access 227 00:12:30.579 --> 00:12:35.579 a particular code section at any time, reducing the risk 228 00:12:35.760 --> 00:12:39.090 of concurrent execution errors that could lead 229 00:12:39.090 --> 00:12:41.100 to a race condition. 230 00:12:41.100 --> 00:12:44.520 Additionally, many database systems offer 231 00:12:44.520 --> 00:12:49.350 resource locking mechanisms to prevent simultaneous actions. 232 00:12:49.350 --> 00:12:53.850 For example, SharePoint locks files when a user checks them 233 00:12:53.850 --> 00:12:57.690 out for editing, allowing other users to view 234 00:12:57.690 --> 00:12:59.820 but not edit the file. 235 00:12:59.820 --> 00:13:01.578 This maintains version control 236 00:13:01.578 --> 00:13:04.830 and prevents conflicting edits. 237 00:13:04.830 --> 00:13:09.176 Similarly, locks and mute can prevent simultaneous access 238 00:13:09.176 --> 00:13:13.020 to records or critical code sections. 239 00:13:13.020 --> 00:13:18.020 So remember, memory-related vulnerabilities are weaknesses 240 00:13:18.570 --> 00:13:22.440 in how applications manage and protect memory, 241 00:13:22.440 --> 00:13:24.240 often allowing attackers 242 00:13:24.240 --> 00:13:28.170 to cause system crashes, access sensitive data, 243 00:13:28.170 --> 00:13:30.510 or execute harmful code. 244 00:13:30.510 --> 00:13:33.930 Common memory vulnerabilities include the use 245 00:13:33.930 --> 00:13:38.250 of deprecated functions, unsafe memory utilization, 246 00:13:38.250 --> 00:13:42.360 overflows race conditions, and time of check to time 247 00:13:42.360 --> 00:13:44.310 of use vulnerabilities. 248 00:13:44.310 --> 00:13:48.420 Deprecated functions are outdated code elements 249 00:13:48.420 --> 00:13:51.330 that lack modern security features, 250 00:13:51.330 --> 00:13:53.670 making applications vulnerable 251 00:13:53.670 --> 00:13:56.550 to attacks like buffer overflows. 252 00:13:56.550 --> 00:14:01.178 Next, unsafe memory utilization occurs when applications 253 00:14:01.178 --> 00:14:05.670 fail to properly manage memory allocation leading 254 00:14:05.670 --> 00:14:07.800 to conditions like memory leaks 255 00:14:07.800 --> 00:14:11.460 and buffer overflows, where attackers can gain access 256 00:14:11.460 --> 00:14:15.360 to critical data or introduce malicious code. 257 00:14:15.360 --> 00:14:18.150 Next overflows allow attackers 258 00:14:18.150 --> 00:14:21.444 to manipulate memory in harmful ways, such 259 00:14:21.444 --> 00:14:25.770 as in a buffer overflow, where attackers push data 260 00:14:25.770 --> 00:14:29.250 beyond the buffer's boundary, potentially altering 261 00:14:29.250 --> 00:14:33.210 adjacent memory or allowing code execution, 262 00:14:33.210 --> 00:14:35.520 or in an integer overflow, 263 00:14:35.520 --> 00:14:38.310 which involves exceeding the storage capacity 264 00:14:38.310 --> 00:14:41.670 of a variable and can wrap data values 265 00:14:41.670 --> 00:14:45.155 or change memory boundaries creates additional openings 266 00:14:45.155 --> 00:14:47.010 for exploits. 267 00:14:47.010 --> 00:14:51.690 Next, race conditions emerge when processes compete 268 00:14:51.690 --> 00:14:54.870 to access or modify shared resources 269 00:14:54.870 --> 00:14:57.780 without proper synchronization leading 270 00:14:57.780 --> 00:15:02.296 to unpredictable outcomes when attackers exploit the timing 271 00:15:02.296 --> 00:15:04.710 of those processes. 272 00:15:04.710 --> 00:15:06.750 Finally, a specific type 273 00:15:06.750 --> 00:15:09.960 of a race condition is called a time of check 274 00:15:09.960 --> 00:15:12.120 to time of use vulnerability. 275 00:15:12.120 --> 00:15:15.390 This occurs when an attacker manipulates data 276 00:15:15.390 --> 00:15:18.480 after the system verifies a condition, but 277 00:15:18.480 --> 00:15:21.990 before it executes an intended action, 278 00:15:21.990 --> 00:15:26.190 allowing unauthorized access or data manipulation. 279 00:15:26.190 --> 00:15:30.780 Overall, mitigating these vulnerabilities requires careful 280 00:15:30.780 --> 00:15:35.460 code practices, such as using secure, updated functions, 281 00:15:35.460 --> 00:15:38.370 employing memory validation techniques, 282 00:15:38.370 --> 00:15:42.060 and implementing synchronization methods like locks 283 00:15:42.060 --> 00:15:46.923 and mutexes to control resource access and timing.