Kwetsbaarheid in Valve-games was uit te buiten door te fraggen

De Source-sdk van Valve bevatte een ernstige kwetsbaarheid die tot het uitvoeren van code op clients en servers van games kon leiden, na bijvoorbeeld het neerschieten van een speler. Valve heeft zijn games in juni een patch gegeven, maar mods zijn waarschijnlijk nog kwetsbaar.

Het gaat om een buffer overflow-kwetsbaarheid die verband houdt met de functie die de Source-sdk opvraagt bij het verwerken van 'ragdoll'-modeldata. Onder andere bij het fraggen van een speler verwerkt de software deze gegevens. Door een regel langer dan 256 karakters te voeden, kan de buffer van een tokenfunctie overvol raken.

De Source-engine maakt het daarnaast mogelijk externe content zoals geluiden en textures in maps te laden. Beveiligingsbedrijf One Up Security slaagde erin een speciaal vervaardigd ragdoll-model in een map te verpakken die het originele model verving na het fraggen, om zo de buffer overflow te veroorzaken. Binnen een dag na de melding bij Valve, in juni, bracht het gamebedrijf patches uit voor Source-games als CS:GO, Team Fortress 2, Portal 2, Left 4 Dead 2 en Half-Life 2: Deathmatch.

Modificaties van Source-games zijn waarschijnlijk nog wel kwetsbaar. One Up Security heeft een patch uitgebracht die makers van die games kunnen gebruiken om het lek te dichten. Het bedrijf wacht een maand met het vrijgeven van een proof-of-concept, om de gamemakers de tijd te geven hun software bij te werken.

One Up Security adviseert verder aslr toe passen op uitvoerbare bestanden en games in een sandbox te draaien om te voorkomen dat toegang tot belangrijke systeemfuncties verkregen wordt.

Reacties (22)

[Gdelaat]

Ik vraag me soms af of zulke dingen wel ooit getest wordt? Ik heb zo veel spellen gezien waar fouten in zitten dat je gemakkelijk kon verhelpen..

ik speelde nog laatst een spel (Line of Sight) waar je de map uit kon glitchen. de developers dachten het te fixen met ontzichtbare dozen te plaatsen op die plek, maar ze maakte het alleen maar erger (dus niet getest of het werkte)

[gijsbertb]

Je vraagt je serieus af of dit soort dingen ooit getest worden. Bij deze het antwoord: "Ja".
Je bugmelding van een ander spel gaat ook over iets totaal anders dan wat hier het geval is.

De bug bij Valve:
Blijkbaar word er iets vanaf de client(jouw speelcomputer) naar valve gestuurd. echter kun je dus ook gewoon veels te veel info mee terugsturen waarbij het "veels te veel" klakkeloos ergens neerkomt waardoor het ook bijvoorbeeld een .exe bestand kan zijn wat vervolgens van binnenuit(dus op de server van Valve) iets doet. Niet handig natuurlijk.. Blijkbaar had er een check moeten zitten op het max aantal karakters wat terug ontvangen werd. Echter betekent dit wel dat er nu dus miljoenen keren(er spelen nogal wat mensen) een extra check(zijn er niet teveel tekens?) gedaan moet worden. Het is dus een afweging tussen performance en betrouwbaarheid.
Mocht je "dit soort dingen" willen testen dan praat je er dus over dat je elke mogelijke API call wil gaan testen p zaken als overflows, dat is best een hele opgave. Ik denk dat ze dat al zeer sterk doen en deze is er tussendoor geglipt.


De bug in Line of Sight:
Glitches hebben veelal te maken met een single floating point waar het karakter in het spel omheen word gerenderd. Aan de hand van dit punt kan worden bepaald of er een collision is met een muur o.i.d. Maar bij 2 muren die bij elkaar komen houd vector-technisch de ene muur op, en begint de andere. Als je punt dus oneindig klein is (het is een punt zonder omvang, een vertice) dan kan hij er doorheen glippen. Om dit te voorkomen moet je dus een bepaalde afstand afdwingen tot dit soort punten, lastige berekening(performance..)

Al met al een hele goed zet van Valve om zo vlot te reageren op een melding(het raakte hen ook direct, dat scheelt ) Ook stoer dat een beveiligingsbedrijf op dit soort lastig-controleerbare zaken test en dit netjes doorgeeft aan Valve(zullen ze vast een zakcentje o.i.i.g. exposure voor krijgen)

[robvanwijk]

Echter betekent dit wel dat er nu dus miljoenen keren(er spelen nogal wat mensen) een extra check(zijn er niet teveel tekens?) gedaan moet worden. Het is dus een afweging tussen performance en betrouwbaarheid.

Nonsense, de controle of de ene integer (lengte data) kleiner-of-gelijk is aan een andere integer (lengte buffer) is de eenvoudigste operatie die mogelijk is. Je kunt de processor zelfs meteen de hint meegeven "meestal gaat dit goed", zodat je (in het normale geval) niet eens een mispredict penalty hebt (dat levert automatisch wel een mispredict op als de bug / exploit wel optreedt, maar die is ten eerste extreem klein, ten tweede extreem zeldzaam en ten derde is de performance van code die alleen uitgevoerd wordt als een bug / exploit optreedt niet heel relevant).

Daarnaast kwam ik (stom toeval) gister deze voordracht tegen, Tony Hoare over Null References. Als de naam je niks zegt: ten eerste: foei! Hij is de uitvinder van QuickSort, structured programming en winnaar van de Turing Award ("de Nobelpijs voor de informatica"). De kern van dat verhaal gaat over iets heel anders, maar in het begin vertelt ie dat ze op een 2 kHz (dat is 0,000002 GHz) CPU niet één maar twee van dat soort checks deden. Niet bij elk ontvangen netwerkpakketje, maar bij elke toegang (zowel lezen als schrijven) van een array. Dat is een operatie die ontelbaar veel vaker voorkomt dan waar we het hier over hebben, op een computer die letterlijk miljoenen keren trager is (en slechts één core heeft en één thread tegelijk uit kan voeren). In hun situatie was de afweging al dat de extra betrouwbaarheid (en dat ging alleen over bugs, niet eens over exploits!) het waard was om een beetje performance in te leveren. Dan kan ik niet anders concluderen dat dit geval een no-brainer is: checken!

Mocht je "dit soort dingen" willen testen dan praat je er dus over dat je elke mogelijke API call wil gaan testen p zaken als overflows, dat is best een hele opgave. Ik denk dat ze dat al zeer sterk doen en deze is er tussendoor geglipt.

Dat is inderdaad veel werk. En het heeft het nadeel dat elke test heeft: ook al vindt je geen bugs, dat betekent niet dat er geen bugs zijn. Dat gezegd hebbende: er zijn speciale programma's die dit grotendeels automatiseren (google maar eens op "fuzzing").

En nee, ik denk niet dat ze hier al op testen; een buffer van 256 is erg klein, elke fatsoenlijke test kijkt ten minste wat er gebeurt als je meer dan 256 bytes in elk veld gooit (en eigenlijk ook meer dan 64 kB). Ik zou nog enig begrijp hebben voor het missen van een buffer overflow in een veld dat wordt verwerkt met een lengte van 32 bit (oftewel: bug als er meer dan 4 GB langskomt), maar deze zou door elke serieuze test gevonden moeten worden.

[Reactie gewijzigd door robvanwijk op 22 juli 2024 19:51]

[rboerdijk]

" Echter betekent dit wel dat er nu dus miljoenen keren(er spelen nogal wat mensen) een extra check(zijn er niet teveel tekens?) gedaan moet worden"

Er is zo ongeveer niets snellers dan een if-statement (een paar miljoen extra if-statements maakt echt helemaal niets uit)... een simpele check op een waarde kan gene reden zijn om performance boven veiligheid te stellen... Dit soort dingen is echter gemakkelijk te missen in een codebase van een paar honderduizend tot enkele miljoenen regels code.

Let wel: Het kan natuurlijk zijn dat de code _in_ een if-statement zeer duur is, maar in dit geval gaat het om een check om daarna niets te doen met ongeldige data.

[Reactie gewijzigd door rboerdijk op 22 juli 2024 19:51]

[Raymond Deen]

Zo ongeveer regel 1 bij API calls: vertrouw nooit de input die je van de aanroeper krijgt als API!!

Dit geldt natuurlijk ook bij web services en een pagina's met formulieren, of andere web apps...

[Dwarrelegel]

Er zit wel een groot verschil tussen wat jij hier noemt en waar het bericht over gaat. In het bericht gaat het over de mogelijkheid om code op servers en clients te laten uitvoeren. Het gevolg zou dus bijvoorbeeld installatie van malware op servers en computers van spelers kunnen zijn.

Dat is wel een stapje erger dan dat jij uit een map clipped. Zeker vervelend voor de speler, of de andere spelers die je vervolgens onzichtbaar kan doodschieten maar dit heeft normaal gesproken geen gevolgen buiten het spel.

[Vexxon]

Ik zou zeggen ontwikkel zelf eens een simpele applicatie en geef het aan drie gebruikers.
Je zal opkijken hoeveel bugs zij vinden.

[kwakzalver]

Een nette en snelle afhandeling van One Up (1 maand wachten) en Valve (binnen 1 maand een update uitbrengen).
Hier kunnen anderen nog wat van leren.

Ook netjes dat One Up een constructieve feedback geeft. Da's toch weer positieve reclame voor zo'n bedrijf.

Wat Valve betreft. Een buffer overflow kan toch echt niet meer deze tijd. Dat is domweg slordig.

[Raventhorn]

Wat Valve betreft. Een buffer overflow kan toch echt niet meer deze tijd. Dat is domweg slordig.

De Source Engine is al weer een jaar of 13 oud, en zelf een doorontwikkeling van de GoldSrc engine. (de engine van de oorspronkelijke Half-Life, welke nu oud genoeg is om bier te mogen drinken; welke zelf ook weer een doorontwikkeling is van de engine achter Quake... etc...)
Dat de engine nu nog een update krijgt is vrij uitzonderlijk, en ik vermoed vrijwel volledig vanwege de aanhoudende populariteit van zowel DotA als CS:GO.

Daarmee wil ik het niet goed praten, maar het is ook weer niet alsof de engine gloednieuw is of zo...
Verbaast me eerder dat deze 'bug' zo lang verstopt is gebleven.

[Reactie gewijzigd door Raventhorn op 22 juli 2024 19:51]

[Blokker_1999]

We blijven mensen, en mensen maken fouten. Ook analysetools zijn niet zaligmakend maar slechts een hulpmiddel.

[OddesE]

Wat Valve betreft. Een buffer overflow kan toch echt niet meer deze tijd. Dat is domweg slordig.

Ik zou zeggen loop eens door de issue lijst van Firefox of Chromium. Je schrikt je kapot. Buffer overflows en crashes door het volgen van pointers met invalid waardes zijn aan de orde van de dag. En zo'n bug is in potentie een exploit. Nadeel van C/C++ he.

[Pinkys Brain]

Waar in C(++) word geprogrammeerd zijn er buffer overflows.

[robvanwijk]

Valve (binnen 1 maand een update uitbrengen).

Nog beter zelfs:

Binnen een dag na de melding bij Valve, in juni, bracht het gamebedrijf patches uit

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Hier kunnen anderen nog wat van leren.

Daar ben ik het dan weer wel mee eens. Niet alleen vanwege de snelheid van de fix en het fixen van stokoude code, ik zou al blij zijn als iedereen een voorbeeld nam aan het überhaupt reageren op meldingen en niet proberen het op andere partijen af te schuiven.

[Reactie gewijzigd door robvanwijk op 22 juli 2024 19:51]

[robvanwijk]

Sowieso is deze bug eerder officieus op een borrel oid door iemand van dat bedrijf bij iemand van valve gemeld. Dat gok ik redelijk zeker ondanks dat het met een regel code te verhelpen is.

Waar heb je het over...!?
Ja, het is één regel code (mogelijk op een (klein) aantal plaatsen) om het te fixen. Maar waar haal je vandaan dat het officieus gemeld is; zelfs al zou dat zo zijn, wat is de relevantie daarvan; wat heeft de complexiteit van de fix te maken met de manier waarop de bug gemeld is?

[Accretion]

Wellicht een extra karakter in je code:
strncpy i.p.v strcpy (oke, strncopy neemt meer argumenten, dus wel iets meer karakters).

Ga er maar vanuit dat als ze wisten dat iemand random code kan uitvoeren op hun servers, ze daar iets tegen zouden doen.

https://stackoverflow.com...strncpy-instead-of-strcpy

[Origin64]

Je kunt wel meer dingen doen op valve servers. Tijdje terug was het nog mogelijk een complete cheat te leveren via valve servers dmv de steam workshop.

[dasiro]

een buffer die overvol raakt? Als je dan toch wil goochelen met engels termen in de titel, schrijf dan ineens overal consequent buffer overflow

[Origin64]

Hoe wil je buffer goed vertalen dan? Stootkussen?

[WollenTrui]

Ik ben iig blij dat Valve spellen nog steeds actief onder de loep genomen worden door beveiligingsonderzoekers (en ik hoop dat er nog vele bij komen). Ik was altijd al enigszins bezorgd dat games over het algemeen minder goed nagekeken worden op beveiligingsproblemen omdat games complex zijn, door veel indie bedrijven ontwikkeld worden en geen WhatsApp of iDeal zijn oid.

[MISTERAMD]

Vroeger maakte men spellen en testen men die spellen. Als het spel uitspeelbaar was, werd het uitgebracht. Pas nadien vond iemand een bug, meerdere bugs of exploits waardoor het spel nog altijd uitspeelbaar was, maar waarin lekken werden uitgebuit om dingen te doen die het spel soms in een slecht daglicht zette. De dag vandaag word er meer tijd in gestoken om die bugs en exploits zo veel mogelijk te verhelpen, maar van tijd tot tijd word er een bug of exploit gevonden die de uitgever zo snel mogelijk wil herstellen. Het is nu eenmaal de normale gang van zaken. Vroeger was men te dom en speelde men gewoon het spel. Tegenwoordig koopt men vaak het spel, enkel om bugs en exploits te vinden en om hieraan sommen geld te krijgen. Harde realiteit, als je dat niet kan afleiden uit al datgene dat er al is gebeurd uit het verleden tot en met nu, dan heb je geslapen onder een steen. Ik koop spellen voor ontspanning, ik hou mij niet bezig met bugs en exploits te zoeken, wegens tijdgebrek.