Wat is een race-condition?

Een race-condition is een technische term voor wanneer twee opdrachten worden gegeven op (vrijwel) hetzelfde moment, waardoor de ontvanger in de war raakt welke opdracht eerst komt. Het klassieke voorbeeld hiervan is een bank. Bij een bank is het van uiterst belang dat afschriften en inkomsten op de juiste volgorde aankomen. Wanneer dit niet het geval is kan het voorkomen dat de klant onterecht negatief staat, of een groter probleem voor de bank; dat er kan worden betaald met geld dat niet bestaat.

Hoe dit werkt:

Wanneer een computerprogramma een opdracht krijgt moet deze vaak meerdere verschillende kleinere opdrachten uitvoeren. Neem als voorbeeld jouw online bankieren app, waarop je een overschrijving wilt doen naar een bedrijf. Deze online bankieren app zal (ongeveer) de volgende kleinere stappen maken:

• de app checkt of je bent verbonden met internet, en ook inderdaad bent ingelogd
• de app checkt of de server van de bank (welke de overschrijvingen regelt) online is
• de app checkt of je voldoende saldo op je rekening hebt (door dit op te vragen aan de server)
• en tot slot wacht de app op verificatie dat de overschrijving gemachtigd is

In het verleden verliepen deze stappen achter elkaar, wachtend tot de volgende stap gezet was. Dat was fijn voor het overzicht en voor oudere computers (en maakte een race-injectie een stuk lastiger), maar was vooral ook erg traag. Zo moest het programma wachten bij elke micro-opdracht tot deze was voltooid. Tegenwoordig zijn de apps zo complex geworden dat dit gewoon niet meer haalbaar is, je zou een eeuwigheid moeten wachten tot een website is geladen.

Met de opkomst van cpu's met meerdere cores (versimpeld: meerdere kleinere rekenmachines in een) konden deze grotere apps met gemak worden geladen, door deze in stukken te hakken. In plaats van het gehele recept door een core te laten maken, kunnen er nu twee cores de groentes snijden, een het water opzetten en nog een de tafel al vast dekken. Ideaal, en in de huidige wereld noodzakelijk. Deze manier van werken wordt ook wel multi threading genoemd (waar een thread een sub-opdracht is).

Groot nadeel; door meerdere onderdelen tegelijk uit te laten voeren verlies je soms de structuur en volgorde. Nu is dat in de meeste gevallen geen probleem; of je nu eerst de tekst of de afbeelding laadt maakt weinig verschil. Maar bij grotere programma's en belangrijke programma's zoals een bankoverschrijving maakt dit wel degelijk uit.

Een truc die door hackers werd gebruikt in de periode van overgang was om een eigen opdracht (thread) in de mix te gooien. Zo werd er bijvoorbeeld een extra thread gemaakt na dat het saldo was goedgekeurd welke een extra overdracht maakte. Of werd er zelfs door twee accounts naast elkaar te race-injecten gezorgd dat beide accounts oneindig elkaar konden opwaarderen.

Programma's die hier kwetsbaar voor zijn kunnen zo al vrij snel opdrachten uitvoeren welke ver buiten het bedoelde gebruik liggen. Waarmee winst (financieel of data technisch) kan worden gemaakt voor de hacker, of het programma kan worden beschadigd.

Waarom dit nog steeds een probleem is in software:

Zoals kort benoemd in het stuk hierboven is de race-condition zoals wij deze nu kennen mogelijk gemaakt door verbeteringen in technologie. Deze wereld staat zeker nog niet stil. Het omgekeerde, we maken steeds betere computers, nu ook met oog op de eerste niet commerciële supercomputers. En kunstmatige intelligentie vormt een steeds groter wordend deel van ons leven. Zowel de ai welke code schrijven voor grote bedrijven (LLM's) als de ai welke wordt ontwikkeld om systemen te hacken. We kunnen dus eigenlijk stellen dat dit probleem alleen maar groter aan het worden is.

De problemen die een organisatie hieruit kan ervaren:

Zoals je kan indenken is het nooit fijn voor een ontwikkelaar of projectleider wanneer een programma niet exact doet wat de bedoeling was. Maar voor bedrijven vormt een race-condition ook daadwerkelijk een reëel risico. Zo kan een race-condition bij programma's ontwikkeld door of voor het bedrijf zorgen voor de volgende risico's:

• imagoschade
• financiële schade
• black-outs van het programma en de hiervan afhankelijke programma's
• data verlies of diefstal
• oneigenlijke toegang
• in robotica gevallen: risico's voor de veiligheid van personeel

Wat hieraan te doen:

Het grote probleem is, je kan de ontwikkeling van betere en snellere computers niet tegengaan, dus je zal nooit een programma volledig onschendbaar kunnen maken voor dit soort aanvallen of storingen. Wat je wel kan doen, en waar het eigenlijk altijd bij begint is het bewust maken van jouzelf en jouw team over de risico's die horen bij het ontwikkelen en accepteren van nieuwe software, waaronder race-conditions. Daarnaast zijn hier een aantal praktische tips:

• zorg dat belangrijke berekeningen (zoals authenticaties) altijd via een server gaan
• zorg dat tijdzones juist staan ingesteld
• blokkeer apparaten welke onjuiste tijdsinstellingen hebben of veel verzoeken tegelijk sturen
• zorg dat belangrijke berekeningen aan de client kant een vaste volgorde hebben
• zorg dat code injecties zoals XSS tegengehouden worden
• zorg dat programma's nooit beheerrechten hebben over het apparaat of de server
• en houdt goede logs bij welke continu worden gemonitord voor verdacht verkeer

Belangrijk om te weten, je zult hierbij altijd de afweging moeten maken tussen gebruikersgemak (waaronder snelheid) en veiligheid. Een product dat onschendbaar is maar onbruikbaar is weegt even slecht als een product dat zijn kwetsbaarheden deelt met heel de wereld. In het geval van race-conditions betekend dat soms genoegen nemen met een iets kwetsbaarder product nu, de kennis nemen tot hoe deze kwetsbaarheden te mitigeren, en wanneer de technologie zo ver is de mitigerende handelingen uitvoeren. Dat is een perfect voorbeeld van hoe een goede producteigenaar omgaat met acceptabel-risico.

Behoefte om te sparren over race-conditions binnen jouw ontwikkelde of aangenomen software? Neem dan contact met ons op.