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