Race Conditions - CompTIA Security+ SY0-701 - 2.3
Professor Messer
https://www.youtube.com/watch?v=MKptc1lPSw8

Transkript (automatisch erstellt)

0:01 A race condition is when two events happen at nearly the same time with an application,
0:07 and the application doesn't take into account that these two conditions may be operating simultaneously.
0:13 This is something application developers commonly check when they're building their application.
0:18 But there may be times when a combination of different events inside the application might have an unexpected outcome.
0:24 And this would be the textbook example of a race condition. One common type of a race condition is a TOCTOU.
0:32 This is a Time-Of-Check to Time-Of-Use attack. This means the application is going
0:37 to check the system to retrieve information that may be stored. And then after it retrieves that information,
0:43 it may perform a particular function with that value. But sometimes, there's another process
0:49 that occurs behind the scenes between the time when you've checked the system for the value
0:54 and you're actually using that particular value. And if you don't take into account that that value might
0:59 change without you knowing it, you've run into a race condition.
1:04 Let's look at a practical example of a race condition where you have two users that are moving dollars
1:10 between two different accounts. There's user 1 and user 2.
1:14 And the two accounts are Account A and Account B. The race condition that you're going to see here
1:19 is one that was created because the application developer takes deposits that are put into the account
1:25 and has them immediately updated in the application. But if someone withdraws money from an account,
1:32 that information may not be immediately updated in the ledger.
1:35 Let's see how this would play out if the two users are transferring information
1:40 from one account to another. We'll start with two accounts, Account A and Account B,
1:44 and both have a starting account value of $100. User 1 is going to transfer $50 from Account A
1:51 to Account B. User 1 is going to check the balance and see that Account A is $100 and Account B has $100.
2:00 User 2 is also going to check the balance and see that both of the balances are indeed at $100.
2:06 So far, everything is working as you would expect. Now user 1 is going to add $50 to Account B. Because deposits
2:13 are updated immediately, we know that Account A has $100, and Account B, with an extra $50 in it, has a $150 value.
2:23 Now user 2 is going to perform the same function. They're going to add $50 to Account B.
2:28 And when they do that, because this deposit is represented immediately, we now have Account A with $100
2:35 and Account B with $200. And again, everything is still working exactly as expected.
2:41 Now user 1 is going to remove $50 from Account A. From user 1's perspective, Account A now has $50 and Account B has $200.
2:50 Now user 2 is going to perform the same transaction and remove $50 from Account A. Because these withdrawals are
2:58 not updated immediately for all users, from user 2's perspective, Account A has $50
3:04 and Account B has $200. This is the step where the race condition really occurs.
3:09 Because the application is not immediately taken into account any withdrawals, the final ending account value
3:15 for user 2 is going to have Account A as $50 and Account B as $200 when, in reality, Account A should
3:22 have $0. These types of race conditions can
3:26 occur anywhere the application is not taking into account one of these many different events
3:31 that can occur. In 2004, we saw a race condition occur on the planet Mars
3:37 with the Mars rover Spirit. There's a safety mechanism within the rover where
3:41 it will reboot itself if it recognizes that a fatal error has occurred.
3:46 And in the case of Mars rover, the problem that was occurring was with the file system itself.
3:52 So during this reboot process, the rover recognizes that there's a file system error,
3:56 and its programming knows that it should be rebooting itself to correct this.
4:00 It reboots itself and runs into exactly the same file system error again.
4:05 And we effectively have a reboot loop. In this example, the developers were
4:09 able to send additional code to the rover to bypass this particular error and get
4:14 the rover back up and running. And it seems appropriate that we should have a race condition
4:18 that occurs inside of a car. And indeed, we had one during Pwn2Own in Vancouver 2023
4:26 with a Tesla Model 3. This TOCTOU attack took advantage
4:30 of a vulnerability in the Tesla of its infotainment system that you could access through Bluetooth.
4:36 They were able to elevate privileges to be the root user of the infotainment system.
4:41 And this allowed the attackers to earn a $100,000 US prize, and they keep the Tesla.