1
00:00:00,090 --> 00:00:00,960
In this lesson,

2
00:00:00,960 --> 00:00:02,610
we're going to talk about race conditions

3
00:00:02,610 --> 00:00:05,070
and the vulnerabilities associated with them.

4
00:00:05,070 --> 00:00:07,590
Now, what exactly is a race condition?

5
00:00:07,590 --> 00:00:10,200
Well, a race condition is a software vulnerability

6
00:00:10,200 --> 00:00:11,670
that occurs when the resulting outcome

7
00:00:11,670 --> 00:00:13,290
from the execution processes

8
00:00:13,290 --> 00:00:14,850
is directly dependent on the order

9
00:00:14,850 --> 00:00:16,440
and timing of certain events,

10
00:00:16,440 --> 00:00:18,450
and those events failed to execute in the order

11
00:00:18,450 --> 00:00:20,460
and timing intended by the developer.

12
00:00:20,460 --> 00:00:22,380
Now, essentially, this is a complicated way

13
00:00:22,380 --> 00:00:25,140
of saying that the computer is unexpectedly trying to race

14
00:00:25,140 --> 00:00:27,900
itself in the processing of certain types of data.

15
00:00:27,900 --> 00:00:30,390
For example, if you're trying to do something legitimately

16
00:00:30,390 --> 00:00:32,009
and the attacker's trying to do something malicious

17
00:00:32,009 --> 00:00:33,300
at the same time,

18
00:00:33,300 --> 00:00:34,710
they might be able to get their request

19
00:00:34,710 --> 00:00:36,060
in right before yours,

20
00:00:36,060 --> 00:00:37,050
so they could take advantage

21
00:00:37,050 --> 00:00:39,660
of a race condition vulnerability in the program's code

22
00:00:39,660 --> 00:00:42,690
to run their processes before you can run yours.

23
00:00:42,690 --> 00:00:44,130
Race condition vulnerabilities

24
00:00:44,130 --> 00:00:45,570
are found when there are multiple threads

25
00:00:45,570 --> 00:00:48,300
attempting to write to a particular variable or object

26
00:00:48,300 --> 00:00:51,420
at the same memory location at the same time.

27
00:00:51,420 --> 00:00:53,970
Now, one of the ways this can happen is by a dereference

28
00:00:53,970 --> 00:00:56,850
or no pointer dereference exploit being exploited

29
00:00:56,850 --> 00:00:58,740
to trigger that race condition.

30
00:00:58,740 --> 00:01:01,080
Dereferencing is a software vulnerability

31
00:01:01,080 --> 00:01:02,580
that occurs when the code attempts to remove

32
00:01:02,580 --> 00:01:04,349
the relationship between a pointer

33
00:01:04,349 --> 00:01:05,880
and the thing that that pointer was pointing

34
00:01:05,880 --> 00:01:07,620
to inside of your memory.

35
00:01:07,620 --> 00:01:09,720
Dereferencing will break the reference pairing

36
00:01:09,720 --> 00:01:10,620
between the pointer

37
00:01:10,620 --> 00:01:12,120
and the thing that was pointing to in memory,

38
00:01:12,120 --> 00:01:14,370
and this allows changes to the location of memory

39
00:01:14,370 --> 00:01:17,070
or the variable that contains that memory location.

40
00:01:17,070 --> 00:01:19,080
Now race conditions are difficult to detect

41
00:01:19,080 --> 00:01:21,060
and mitigate in our modern networks.

42
00:01:21,060 --> 00:01:24,660
The Dirty COW exploit was extremely popular back in 2016,

43
00:01:24,660 --> 00:01:26,580
that's an excellent example of a race condition

44
00:01:26,580 --> 00:01:28,140
that was being exploited.

45
00:01:28,140 --> 00:01:29,670
COW is actually an acronym

46
00:01:29,670 --> 00:01:31,800
and it stands for "Copy On Write".

47
00:01:31,800 --> 00:01:33,330
In the Dirty Cow Exploit,

48
00:01:33,330 --> 00:01:35,940
the Linux operating systems and some Android devices

49
00:01:35,940 --> 00:01:38,550
were being exploited to allow a local privilege escalation

50
00:01:38,550 --> 00:01:41,340
to occur by exploiting a race condition vulnerability

51
00:01:41,340 --> 00:01:43,320
based on the implementation of the programming

52
00:01:43,320 --> 00:01:44,970
for the copy on write function

53
00:01:44,970 --> 00:01:46,680
that was used inside of the Kernel's memory

54
00:01:46,680 --> 00:01:47,970
management system.

55
00:01:47,970 --> 00:01:50,370
Now because a race condition existed in this code,

56
00:01:50,370 --> 00:01:52,290
if the attacker used the right timing,

57
00:01:52,290 --> 00:01:54,360
they could exploit the copy and write mechanism

58
00:01:54,360 --> 00:01:56,310
to turn the read-only mapping of a file

59
00:01:56,310 --> 00:01:57,900
into a write mapping.

60
00:01:57,900 --> 00:02:00,240
This would allow the attacker to have escalated privileges

61
00:02:00,240 --> 00:02:01,950
because they can now write to a file

62
00:02:01,950 --> 00:02:03,870
even though they're only supposed to have read access

63
00:02:03,870 --> 00:02:05,160
to that file.

64
00:02:05,160 --> 00:02:07,260
Now, what made this exploit even more dangerous

65
00:02:07,260 --> 00:02:08,699
is that it was difficult to detect

66
00:02:08,699 --> 00:02:10,020
because it didn't even leave anything

67
00:02:10,020 --> 00:02:11,400
inside of the system logs

68
00:02:11,400 --> 00:02:12,990
to let you know that it was happening.

69
00:02:12,990 --> 00:02:15,330
And this is why race conditions are so dangerous,

70
00:02:15,330 --> 00:02:16,770
because they often happen outside

71
00:02:16,770 --> 00:02:19,830
of the normally logged processes on a given system.

72
00:02:19,830 --> 00:02:22,230
While the Dirty COW vulnerability allows a race condition

73
00:02:22,230 --> 00:02:23,970
against the memory management system,

74
00:02:23,970 --> 00:02:26,340
race conditions can also be used against databases

75
00:02:26,340 --> 00:02:28,020
and file systems too.

76
00:02:28,020 --> 00:02:30,120
When race conditions are used to exploit a database

77
00:02:30,120 --> 00:02:31,170
or file system,

78
00:02:31,170 --> 00:02:32,580
they're generally going to take the form

79
00:02:32,580 --> 00:02:33,930
of either a time-of-check,

80
00:02:33,930 --> 00:02:34,763
time-of-use,

81
00:02:34,763 --> 00:02:36,990
or time-of-evaluation vulnerability.

82
00:02:36,990 --> 00:02:39,720
Now, first we have a Time-of-Check vulnerability,

83
00:02:39,720 --> 00:02:41,190
a time-of-check vulnerability,

84
00:02:41,190 --> 00:02:43,350
also known as a TOC vulnerability,

85
00:02:43,350 --> 00:02:45,030
is a type of race condition that occurs

86
00:02:45,030 --> 00:02:47,910
when an application checks the state of a system resource,

87
00:02:47,910 --> 00:02:49,680
such as a file or database record,

88
00:02:49,680 --> 00:02:51,900
and then makes a decision based on that check.

89
00:02:51,900 --> 00:02:53,880
But then an attacker is able to manipulate

90
00:02:53,880 --> 00:02:54,990
the state of the resource

91
00:02:54,990 --> 00:02:57,870
before the application's operation actually occurs.

92
00:02:57,870 --> 00:02:58,740
For example,

93
00:02:58,740 --> 00:03:01,500
an application might check if a user has sufficient funds

94
00:03:01,500 --> 00:03:03,360
before initiating a bank transfer.

95
00:03:03,360 --> 00:03:05,610
However, if there's a significant time gap

96
00:03:05,610 --> 00:03:07,290
between the time that the check occurs

97
00:03:07,290 --> 00:03:09,120
and the actual money transfer happens,

98
00:03:09,120 --> 00:03:11,700
the attacker could potentially initiate multiple transfers

99
00:03:11,700 --> 00:03:12,900
in that time window,

100
00:03:12,900 --> 00:03:15,450
which could end up overdrawing your bank account.

101
00:03:15,450 --> 00:03:18,120
Second, we have a Time-of-Use vulnerability.

102
00:03:18,120 --> 00:03:19,680
Now a time-of-use vulnerability

103
00:03:19,680 --> 00:03:21,750
known as a TOU vulnerability,

104
00:03:21,750 --> 00:03:22,980
is a type of race condition

105
00:03:22,980 --> 00:03:24,870
that occurs when an attacker can change the state

106
00:03:24,870 --> 00:03:27,270
of a system resource between the time it is checked

107
00:03:27,270 --> 00:03:28,740
and the time it is used.

108
00:03:28,740 --> 00:03:30,960
This is similar to the time of check vulnerability,

109
00:03:30,960 --> 00:03:33,690
but it focuses more on the time that the resource is used

110
00:03:33,690 --> 00:03:36,270
instead of focusing on the time that the check conducted.

111
00:03:36,270 --> 00:03:39,210
Third, we have a Time-of-Evaluation vulnerability.

112
00:03:39,210 --> 00:03:41,280
Now a time-of-evaluation vulnerability,

113
00:03:41,280 --> 00:03:43,320
also known as a TOE Vulnerability,

114
00:03:43,320 --> 00:03:44,700
is a type of race condition

115
00:03:44,700 --> 00:03:47,220
that involves the manipulation of data or resources

116
00:03:47,220 --> 00:03:48,300
during a time window

117
00:03:48,300 --> 00:03:51,150
when a system is making a decision or evaluation.

118
00:03:51,150 --> 00:03:54,390
For example, the attacker might manipulate inputs being used

119
00:03:54,390 --> 00:03:56,820
inside of a calculation to cause incorrect results

120
00:03:56,820 --> 00:03:58,440
to be used instead.

121
00:03:58,440 --> 00:04:00,180
To protect against a race condition,

122
00:04:00,180 --> 00:04:01,890
you can use locks and mutexes

123
00:04:01,890 --> 00:04:04,770
to lock resources while a process is being run.

124
00:04:04,770 --> 00:04:07,560
Now, a mutex is simply a mutually exclusive flag

125
00:04:07,560 --> 00:04:09,720
that acts as a gatekeeper to a section of code,

126
00:04:09,720 --> 00:04:12,240
so only one thread can be processed at a time

127
00:04:12,240 --> 00:04:14,370
and this helps prevent race conditions from occurring

128
00:04:14,370 --> 00:04:16,649
because we're not going to have that concurrent execution

129
00:04:16,649 --> 00:04:17,880
of the code or function

130
00:04:17,880 --> 00:04:19,800
because of that mutex being there.

131
00:04:19,800 --> 00:04:21,450
Now, most databases have a method

132
00:04:21,450 --> 00:04:22,890
that can be used to lock a resource

133
00:04:22,890 --> 00:04:24,540
while it's being processed.

134
00:04:24,540 --> 00:04:26,610
For example, if you've ever used SharePoint at work

135
00:04:26,610 --> 00:04:28,590
to access a particular file for editing,

136
00:04:28,590 --> 00:04:30,300
it actually puts a lock on that file

137
00:04:30,300 --> 00:04:31,860
so that other people can read the file

138
00:04:31,860 --> 00:04:32,850
while you're editing it,

139
00:04:32,850 --> 00:04:35,040
but nobody else can check the file out for editing

140
00:04:35,040 --> 00:04:36,570
while you have it in use.

141
00:04:36,570 --> 00:04:38,610
This prevents two users from changing the file

142
00:04:38,610 --> 00:04:39,630
at the same time

143
00:04:39,630 --> 00:04:42,510
and helps us to maintain version control over our files.

144
00:04:42,510 --> 00:04:44,820
This same concept is used when locking a record

145
00:04:44,820 --> 00:04:46,560
in a database or using a mutex

146
00:04:46,560 --> 00:04:48,540
to lock out the execution or function

147
00:04:48,540 --> 00:04:49,860
of a particular part of the code

148
00:04:49,860 --> 00:04:51,870
until the other threat is completed.

149
00:04:51,870 --> 00:04:54,690
Overall, the use of locks and mutexes works pretty well

150
00:04:54,690 --> 00:04:56,070
to prevent race conditions,

151
00:04:56,070 --> 00:04:58,770
but sometimes they can cause a deadlock to occur.

152
00:04:58,770 --> 00:05:01,050
Now, a deadlock occurs when a lock takes effect,

153
00:05:01,050 --> 00:05:02,790
but the process that the lock is waiting for

154
00:05:02,790 --> 00:05:03,623
is terminated,

155
00:05:03,623 --> 00:05:05,820
crashes or simply doesn't finish properly,

156
00:05:05,820 --> 00:05:07,770
which causes the lock to never be removed

157
00:05:07,770 --> 00:05:10,860
from the resource even though the processing was completed.

158
00:05:10,860 --> 00:05:11,850
When this occurs,

159
00:05:11,850 --> 00:05:14,250
the system or code can lose access to the resource

160
00:05:14,250 --> 00:05:17,190
until the lock is overridden or manually removed.

161
00:05:17,190 --> 00:05:18,420
To prevent dead locking,

162
00:05:18,420 --> 00:05:20,220
it's important that you properly design and test

163
00:05:20,220 --> 00:05:23,250
any locks or mutexes that you're using inside of your code

164
00:05:23,250 --> 00:05:24,870
to prevent a race condition.

165
00:05:24,870 --> 00:05:27,660
So remember, a race condition is a software vulnerability

166
00:05:27,660 --> 00:05:29,880
that occurs when the resulting outcome from the execution

167
00:05:29,880 --> 00:05:32,220
processes is directly dependent on the order

168
00:05:32,220 --> 00:05:33,690
and timing of certain events,

169
00:05:33,690 --> 00:05:35,970
and those events failed to execute in the order

170
00:05:35,970 --> 00:05:37,920
and timing intended by the developer.

171
00:05:37,920 --> 00:05:39,660
There are three main types of race conditions

172
00:05:39,660 --> 00:05:41,730
that you might come across in the real world,

173
00:05:41,730 --> 00:05:43,530
including a time-of-check vulnerability,

174
00:05:43,530 --> 00:05:44,880
a time-of-use vulnerability,

175
00:05:44,880 --> 00:05:47,280
and a time-of-evaluation vulnerability.

176
00:05:47,280 --> 00:05:49,830
All these race conditions can have serious implications

177
00:05:49,830 --> 00:05:51,270
on the security and reliability

178
00:05:51,270 --> 00:05:53,130
of your software applications.

179
00:05:53,130 --> 00:05:54,450
Finally, it's important to remember

180
00:05:54,450 --> 00:05:55,650
that to prevent a race condition

181
00:05:55,650 --> 00:05:57,150
from being successfully used,

182
00:05:57,150 --> 00:05:58,830
you need to mitigate these vulnerabilities

183
00:05:58,830 --> 00:06:01,173
by using mutexes or resource locks.