Zum Inhalt springen
L

Das Video kommt von YouTube: erst beim Abspielen verbindet sich die Seite mit YouTube (Google).

Race Conditions - CompTIA Security+ SY0-701 - 2.3

Professor Messer4:58 242.572 Aufrufe veröffentlicht Auf YouTube

Das Wichtigste aus dem Video

Tipp auf eine Zeit – das Video springt genau dorthin.

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

Zum Nachlesen

Time-of-Check-to-Time-of-Use-ProblemAllgemein wird damit eine Form der Wettlaufsituation (Race Condition) bezeichnet, bei der der Zeitraum zwischen der Überprüfung eines Systemzustandes (Time … WettlaufsituationEine Wettlaufsituation, aus dem Englischen auch Race Condition (deutsch Wettlauf-Bedingung) oder Race Hazard (deutsch Wettlauf-Risiko), mitunter auch …