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