1 00:00:00,190 --> 00:00:01,740 Race Conditions. 2 00:00:01,740 --> 00:00:04,520 In this lesson, we're going to talk about race conditions 3 00:00:04,520 --> 00:00:06,880 and the vulnerabilities associated with them. 4 00:00:06,880 --> 00:00:09,960 Now, what exactly is a race condition? 5 00:00:09,960 --> 00:00:12,510 Well, a race condition is a software vulnerability 6 00:00:12,510 --> 00:00:14,030 that occurs when the resulting outcome 7 00:00:14,030 --> 00:00:16,770 from execution processes is directly dependent 8 00:00:16,770 --> 00:00:19,090 on the order and timing of certain events. 9 00:00:19,090 --> 00:00:21,380 And those events failed to execute in the order 10 00:00:21,380 --> 00:00:23,630 and timing intended by the developer. 11 00:00:23,630 --> 00:00:25,970 Now, that's a really funky way of saying that 12 00:00:25,970 --> 00:00:29,320 basically, the computer is trying to race itself. 13 00:00:29,320 --> 00:00:31,840 So, if you're trying to do something legitimately 14 00:00:31,840 --> 00:00:34,210 and the attacker is trying to do something at the same time 15 00:00:34,210 --> 00:00:36,130 and they can get in before you, 16 00:00:36,130 --> 00:00:38,860 they have now taken advantage of this race condition 17 00:00:38,860 --> 00:00:41,800 to be able to run their thing before you can run yours. 18 00:00:41,800 --> 00:00:43,870 And this is a very specific case. 19 00:00:43,870 --> 00:00:46,610 When we start talking about a race condition vulnerability, 20 00:00:46,610 --> 00:00:48,940 this is found when there are multiple threads attempting 21 00:00:48,940 --> 00:00:52,020 to write a variable or object at the same memory location 22 00:00:52,020 --> 00:00:53,430 at the same time. 23 00:00:53,430 --> 00:00:55,190 Now, one of the ways this can happen is by 24 00:00:55,190 --> 00:00:58,080 a dereference or a no-pointer dereference exploit 25 00:00:58,080 --> 00:01:01,270 that's being exploited that can trigger this race condition. 26 00:01:01,270 --> 00:01:03,010 Now, when we talk about dereferencing, 27 00:01:03,010 --> 00:01:05,480 this is a software vulnerability that occurs when the code 28 00:01:05,480 --> 00:01:08,200 attempts to remove the relationship between a pointer 29 00:01:08,200 --> 00:01:11,330 and the thing that that pointer is pointing to in memory. 30 00:01:11,330 --> 00:01:13,340 This is why it's called dereferencing, 31 00:01:13,340 --> 00:01:15,970 because we're dereferencing or breaking apart 32 00:01:15,970 --> 00:01:18,280 the pointer and the thing it's pointing to. 33 00:01:18,280 --> 00:01:21,900 Now, race conditions are difficult to detect and mitigate. 34 00:01:21,900 --> 00:01:24,330 In fact, this is one of the things that actually is used 35 00:01:24,330 --> 00:01:26,650 by attackers to try to evade any virus, 36 00:01:26,650 --> 00:01:29,100 because if you can race in and get there 37 00:01:29,100 --> 00:01:30,810 before the antivirus can take hold, 38 00:01:30,810 --> 00:01:32,770 it doesn't realize you're doing something wrong. 39 00:01:32,770 --> 00:01:35,140 And so there is a lot of examples in the past 40 00:01:35,140 --> 00:01:35,973 of this happening. 41 00:01:35,973 --> 00:01:38,970 One of the most common ones was actually in 2016, 42 00:01:38,970 --> 00:01:40,840 and it's known as Dirty COW. 43 00:01:40,840 --> 00:01:43,620 Now, Dirty COW is a great example of a race condition 44 00:01:43,620 --> 00:01:46,240 that was used to exploit a computer vulnerability. 45 00:01:46,240 --> 00:01:47,460 Now, when I talk about COW, 46 00:01:47,460 --> 00:01:48,620 I'm not really talking about a cow 47 00:01:48,620 --> 00:01:50,120 like you see here on the screen. 48 00:01:50,120 --> 00:01:53,340 The COW actually stands for Copy On Write. 49 00:01:53,340 --> 00:01:56,880 Now, this exploit affected Linux operating systems in 2016, 50 00:01:56,880 --> 00:01:58,420 including some Android versions, 51 00:01:58,420 --> 00:02:00,130 because it's based on Linux. 52 00:02:00,130 --> 00:02:03,100 The exploit would cause a local privilege escalation bug 53 00:02:03,100 --> 00:02:04,120 that could be exploited through 54 00:02:04,120 --> 00:02:05,820 this race condition vulnerability 55 00:02:05,820 --> 00:02:07,150 because of the implementation 56 00:02:07,150 --> 00:02:09,140 of the programming for Copy On Write 57 00:02:09,140 --> 00:02:11,940 that was using the kernel's memory management system. 58 00:02:11,940 --> 00:02:13,990 Now, because this race condition exists, 59 00:02:13,990 --> 00:02:17,180 with the right timing, a local attacker could exploit 60 00:02:17,180 --> 00:02:20,210 the copy on write mechanism to turn the read-only mapping 61 00:02:20,210 --> 00:02:22,450 of a file into a writing mapping. 62 00:02:22,450 --> 00:02:24,810 And therefore, they now had privilege escalation 63 00:02:24,810 --> 00:02:26,930 because they could write to a file where they only 64 00:02:26,930 --> 00:02:28,750 were supposed to have read access. 65 00:02:28,750 --> 00:02:30,500 Now, because this was a race condition, 66 00:02:30,500 --> 00:02:33,060 it was hard to detect because it didn't even leave anything 67 00:02:33,060 --> 00:02:35,810 inside the system's log to let you know what happened. 68 00:02:35,810 --> 00:02:39,350 And so, this again is why race conditions are so dangerous. 69 00:02:39,350 --> 00:02:42,240 Now, race conditions can also be used against databases 70 00:02:42,240 --> 00:02:43,170 and file systems. 71 00:02:43,170 --> 00:02:45,560 They don't have to just be used against some kind of 72 00:02:45,560 --> 00:02:48,050 an operating system kernel or memory. 73 00:02:48,050 --> 00:02:50,730 Now, when race conditions are used to exploit a database 74 00:02:50,730 --> 00:02:51,970 or a file system, 75 00:02:51,970 --> 00:02:54,700 generally, they're going to take the form of a time of check 76 00:02:54,700 --> 00:02:56,650 to time of use vulnerability. 77 00:02:56,650 --> 00:02:59,290 Now, when we talk about a time of check to time of use, 78 00:02:59,290 --> 00:03:01,510 this is a potential vulnerability that occurs when there's 79 00:03:01,510 --> 00:03:03,950 a change between when the app checked a resource 80 00:03:03,950 --> 00:03:07,100 and when the app actually is going to use the resource. 81 00:03:07,100 --> 00:03:10,550 So essentially, this vulnerability will make the change 82 00:03:10,550 --> 00:03:13,170 invalidate the check that was already made. 83 00:03:13,170 --> 00:03:14,390 Think about it this way, 84 00:03:14,390 --> 00:03:17,310 if the attacker can identify the time the check happened 85 00:03:17,310 --> 00:03:19,380 and then do something before it was used, 86 00:03:19,380 --> 00:03:20,610 that's a race condition, 87 00:03:20,610 --> 00:03:23,430 they can then manipulate the data after it's been checked, 88 00:03:23,430 --> 00:03:25,370 but before it was used by the application, 89 00:03:25,370 --> 00:03:27,780 and therefore, cause some kind of an issue. 90 00:03:27,780 --> 00:03:30,600 For example, let's say I had an ecommerce store, 91 00:03:30,600 --> 00:03:33,150 and I had a shopping cart, and you go onto Amazon 92 00:03:33,150 --> 00:03:35,390 for instance, let's say they program this horribly. 93 00:03:35,390 --> 00:03:37,540 You go to Amazon, you put a bunch of stuff in your cart, 94 00:03:37,540 --> 00:03:39,230 but you never bothered to check out. 95 00:03:39,230 --> 00:03:41,640 You put down your phone, you come back the next day, 96 00:03:41,640 --> 00:03:42,970 you pick up the phone and see you still have 97 00:03:42,970 --> 00:03:44,440 all these things in your cart. 98 00:03:44,440 --> 00:03:46,590 So, you go there and you finish your purchase. 99 00:03:46,590 --> 00:03:48,920 Well, if Amazon didn't go back and actually check 100 00:03:48,920 --> 00:03:50,450 that those things were still in stock 101 00:03:50,450 --> 00:03:52,130 and that the price hasn't changed, 102 00:03:52,130 --> 00:03:55,380 then this would be a time of check to time of use issue 103 00:03:55,380 --> 00:03:57,770 because they checked it when you put it into the cart, 104 00:03:57,770 --> 00:04:00,360 but then you're using it when you check out of the cart. 105 00:04:00,360 --> 00:04:02,560 And so that time difference is an issue. 106 00:04:02,560 --> 00:04:04,040 So, what you'll see is most things, 107 00:04:04,040 --> 00:04:05,500 especially with ecommerce, 108 00:04:05,500 --> 00:04:07,600 they're going to do a final check when you try to pay, 109 00:04:07,600 --> 00:04:09,580 and they're going to say, do we still have it in stock? 110 00:04:09,580 --> 00:04:11,300 And is it still the same price? 111 00:04:11,300 --> 00:04:13,140 This can help prevent this time of check 112 00:04:13,140 --> 00:04:14,640 to time of use issue. 113 00:04:14,640 --> 00:04:16,470 Now, how else can you prevent race conditions 114 00:04:16,470 --> 00:04:18,810 in time of check to time of use issues? 115 00:04:18,810 --> 00:04:21,270 Well, the first thing you could do is develop applications 116 00:04:21,270 --> 00:04:24,230 to not process things sequentially, if possible. 117 00:04:24,230 --> 00:04:26,160 So, if I have to do something and it takes 118 00:04:26,160 --> 00:04:27,770 a certain amount of sequences, 119 00:04:27,770 --> 00:04:30,240 do I have to do them all going from one, two, 120 00:04:30,240 --> 00:04:32,430 three, four, five, and take those steps? 121 00:04:32,430 --> 00:04:34,500 Or can I do things in parallel? 122 00:04:34,500 --> 00:04:36,210 Anytime I can do things in parallel, 123 00:04:36,210 --> 00:04:37,630 that's going to decrease the amount of time 124 00:04:37,630 --> 00:04:39,370 that things are in sequence, and that's going to limit 125 00:04:39,370 --> 00:04:41,810 the ability for a race condition to occur. 126 00:04:41,810 --> 00:04:43,700 The second thing we can think about is implementing 127 00:04:43,700 --> 00:04:45,520 a locking mechanism within the app 128 00:04:45,520 --> 00:04:47,800 to provide exclusive access to that resource. 129 00:04:47,800 --> 00:04:50,080 And a lot of ecommerce stores will do this. 130 00:04:50,080 --> 00:04:52,440 For instance, if you go into Amazon and you put something 131 00:04:52,440 --> 00:04:54,980 in your cart, they will give you exclusive access to that, 132 00:04:54,980 --> 00:04:56,260 maybe four or five minutes. 133 00:04:56,260 --> 00:04:57,890 If you don't buy it within five minutes, 134 00:04:57,890 --> 00:04:59,200 they're going to take it out of your cart, 135 00:04:59,200 --> 00:05:01,100 or they're going to allow it to be open in the store 136 00:05:01,100 --> 00:05:02,730 so somebody else can buy it. 137 00:05:02,730 --> 00:05:03,810 But during that five minutes, 138 00:05:03,810 --> 00:05:05,027 they put a lock on that product and say, 139 00:05:05,027 --> 00:05:07,750 "This one is reserved for Jason. He has it in his cart. 140 00:05:07,750 --> 00:05:09,920 And if he checks out within five minutes, he can have it." 141 00:05:09,920 --> 00:05:11,510 You'll see this a lot with movie theater tickets 142 00:05:11,510 --> 00:05:12,343 or concert tickets. 143 00:05:12,343 --> 00:05:13,900 Because there's a limited supply, 144 00:05:13,900 --> 00:05:15,580 they will give you a certain time to check out, 145 00:05:15,580 --> 00:05:18,110 and during that time, you hold onto that ticket. 146 00:05:18,110 --> 00:05:20,170 Now, that's an example for physical products, 147 00:05:20,170 --> 00:05:21,600 but even inside your database, 148 00:05:21,600 --> 00:05:22,990 there can be things like that. 149 00:05:22,990 --> 00:05:25,510 For instance, if you ever use SharePoint to work on files 150 00:05:25,510 --> 00:05:27,000 across an organization, 151 00:05:27,000 --> 00:05:29,750 they use this type of a locking system for their database. 152 00:05:29,750 --> 00:05:32,100 If you take a file, you will check out that file. 153 00:05:32,100 --> 00:05:33,040 You make those changes, 154 00:05:33,040 --> 00:05:35,800 then you check the file back in, that removes the lock. 155 00:05:35,800 --> 00:05:37,670 Now, other people can have access to it 156 00:05:37,670 --> 00:05:38,890 to make those changes. 157 00:05:38,890 --> 00:05:40,830 During that time, people can read the file, 158 00:05:40,830 --> 00:05:41,980 they just can't write to the file 159 00:05:41,980 --> 00:05:44,450 because you have exclusive lock access on it. 160 00:05:44,450 --> 00:05:46,950 And that's a good way to prevent a race condition.