Valve dicht tien jaar oude kwetsbaarheid in Steam

Steam bleek een kwetsbaarheid te bevatten die al zeker tien jaar in alle softwareclients zat. Met de tot juli vorig jaar relatief eenvoudig uit te buiten kwetsbaarheid was het uitvoeren van code op afstand mogelijk.

De aard van het probleem lag bij Valves Steam-protocol, schrijft Tom Court van beveiligingsbedrijf Contextis. Dat protocol controleerde de lengte van een eerste datapakketje van een gefragmenteerde datagram niet. Dat opent de deur naar een buffer overflow, specifiek voor de library van de Steam-client die gefragmenteerde datagrams opbouwt op basis van ontvangen udp-pakketjes.

In juli vorig jaar voegde Valve address space layout randomization-beveiliging toe aan de client. Sindsdien is de kwetsbaarheid niet zonder meer te misbruiken, maar leidt uitbuiting ervan tot crashes. Vanaf zeker 2008 heeft het lek er echter in gezeten, claimt Contextis, en ook na juli 2017 was misbruik nog mogelijk met extra informatie over de geheugenlocatie van de Steam-app.

Het bedrijf heeft Valve op 20 februari van dit jaar op de hoogte gebracht van de vondst en twaalf uur later had het bedrijf het probleem opgelost in de bèta-client. Op 22 maart is de fix in de stabiele client doorgevoerd. "Het was een simpele bug, die relatief eenvoudig was te misbruiken dankzij het ontbreken van moderne beveiliging", schrijft Court.

Reacties (81)

[Bonzo2009]

Wat is hier precies mee te achterhalen indien er misbruik plaats heeft gevonden ?
Het totale systeem of wachtwoorden ?
Weet iemand dit ?
Of is het puur dat de client een crash krijgt ?

[Reactie gewijzigd door Bonzo2009 op 26 juli 2024 01:39]

[Men_o]

Er kan andere code uitgevoerd worden, meestal door een pointer aan te passen. Maar dan moet de aanvaller wel eerst die code ook al op de pc van de client hebben staan. Voor zover ik weet is de plek die je hebt om in de bytes die je overschrijft zelf code weg te zetten veel te klein voor iets substantieels, maar misschien dat hier varianten/manieren voor zijn die ik niet ken (niet echt mijn vakgebied).

[batjes]

Bij buffer overflows kun je als de hacker zelf code opsturen die het gaat uitvoeren. Dat hoeft niet lokaal te staan.

Daarom zijn buffer overflows ook zo lekker gevaarlijk. Het is weinig anders dan een mogelijkheid om zelf data het geheugen van een systeem in te laden.

[Verwijderd]

Note, dat werkt alleen als de buffer "op de stack" wordt gealloceerd. Omdat als je dan aan het einde van je buffer voorbij de laatste byte van de buffer schrijft, je waarden op de stack overschrijft. En dat is waar het return-address van je functie staat. Waar je heen gaat springen als de functie klaar is.

Als je van het netwerk leest, dus altijd lezen in een buffer die je ge-mallocd hebt.
Als je van het netwerk leest, altijd fgets() gebruiken en nooit gets(). Eigenlijk zou gets() uit de stdio-library verwijderd moeten worden.

[MSalters]

Eigenlijk zou gets() uit de stdio-library verwijderd moeten worden.

gets() is verwijderd uit de stdio library. Al 7 jaar geleden.

Overigens is het uitvoeren van code uit buffers al geen issue meer sinds Vista; DEP zorgt ervoor dat de stack niet executable is. Je kunt potentieel een return adres wijzigen, maar alleen als dat [i]achter/] een buffer op de stack staat. Moderne compilers draaien dat om, en je hebt dan een buffer underflow nodig om een return adres te overschrijven. Die zijn veel zeldzamer.

[Verwijderd]

gets() is verwijderd uit de stdio library. Al 7 jaar geleden.

Ah, goed. Dat wist ik niet. Ik schrijf code voor een proprietary OS. Daar hebben we ook gets() verwijderd. Ik had geen idee hoe dat op andere platformen zat.

Overigens is het uitvoeren van code uit buffers al geen issue meer sinds Vista;

Sorry. De wereld is meer dan Windows tegenwoordig.

[MSalters]

Ten tijde van Vista hadden Linux, Mac en OpenBSD al de equivalente bescherming. Maar dat was marginaal, Vista en vooral Win7 maakten het gangbaar.

[Tokkes]

maar aangaande Steam isdat hier geen probleem

[Proxx]

uitvoeren van code op afstand mogelijk.

het bericht doet vermoeden dat het als backdoor kan fungeren..

afhankelijk van welke code uigevoerd word. kan dit gebruikt worden om idd de computer over te nemen, wachtwoorden te stelen

In juli vorig jaar voegde Valve address space layout randomization-beveiliging toe aan de client. Sindsdien is de kwetsbaarheid niet zonder meer te misbruiken, maar leidt uitbuiting ervan tot crashes.

dus sinds juli leid het alleen tot crashes

[Reactie gewijzigd door Proxx op 26 juli 2024 01:39]

[Bonzo2009]

Van 2008 tm 2017 was het uitvoeren van code dus mogelijk.
En sinds vorig jaar crasht de client als ik het dus begrijp ?

Bijna 10 jaar is het systeem dus kwetsbaar geweest lekker..

[Grrrrrene]

Vrijwel ieder systeem is wel ergens kwetsbaar voor. Pas als de kwetsbaarheid gevonden wordt en uitgebuit of door bonafide experts gemeld bij de maker (of door de maker zelf ontdekt natuurlijk), kan het gat worden gedicht. Zolang niemand van de kwetsbaarheid weet, is er toch niks aan de hand?

[batjes]

Je moest eens weten hoe kwetsbaar je systeem is. Van je hardware tot je software. Het is 1 grote gatenkaas.

Van de grote partijen worden ze nog wel gevonden, kan 10, 20 of zelfs 30 jaar duren. Maar ze worden meestal wel gevonden.

Bedenk je eens al die software in je program files waarvan het meeste nooit aan het licht komt want veel komt van kleine bedrijfjes, veel is ook al tig jaar niet geupdate (of abandoned).

Dit soort vonsten zijn weinig meer dan legacy opruimen. Security first is pas de laatste 5 jaar een beetje de norm geworden. En zelfs nu nog houden genoeg developers zich hier niet aan.

[Men_o]

Te weinig kennis is ook vaak een probleem bij developers. Dit is niet helemaal hun eigen schuld. Opleidingen zijn te weinig inhoudelijk en daarbij komt dat de helft van de ontwikkelaars die werkzaam zijn minder dan 5 jaar ervaring hebben. Dan is het ook nog zo dat er snel van technieken gewisseld wordt en dat veel ontwikkelaars niet de tijd krijgen om zich in security te verdiepen op hun werk en ook gewoon een leven buiten het werk willen en dus buiten werktijd ook niet deze kennis op doen.

Daarbij zijn genoeg bedrijven ook niet zo geïnteresseerd om veel tijd en geld in security te steken (al zullen ze dit nooit hard op zeggen). De gemiddelde consument koopt/gebruikt ook niet een product omdat het veilig is, die wilt gewoon dat het werkt en er mooi uit ziet en daarbij goedkoop is. Dit werkt allemaal niet echt mee.

[batjes]

Ik geef de developers persoonlijk ook echt niet de schuld, in veel gevallen willen de developers het zelf wel, maar van hogere hand wordt dan anders besloten. Zoals je zelf ook al aangeeft.

Security first is meer een mindset dan wat anders. Bufferoverflows is bijna security 101.

Het grootste huidige probleem is de legacy uit het tijdperk dat bijna niemand security serieus nam. Er draait zo ontiegelijk veel meuk op gatenkaas, als je er over nadenkt, eigenlijk niet leuk mocht er nu een wereld oorlog achtige pleuris uitbreken.

[Men_o]

Ja precies, volledig met eens.

[Blokker_1999]

En hoe serieus nemen we security vandaag? Ik heb ook al dingen gezien dit jaar waarbij ik denk: als de verkeerde mensen dit zien rollen er koppen.

[Stoelpoot]

In het artikel staat enkel "uitvoeren van code". Dan kan je er dus van uit gaan dat het volledige toegang betrof. Dat is ook vaak zo bij buffer overflow-exploits.

[Bor]

In principe kun je willekeurige code draaien op het systeem. Je zou zo het systeem op afstand malware kunnen laten ophalen en installeren (bv voor makkelijkere remote toegang), bestanden of informatie kunnen wegsluizen etc.

[3dfx]

Je kunt op afstand code uitvoeren (Remote Code Execution), en tja, wat voor code is dan aan de aanvaller
Naar een website dirigeren om op de achtergrond een virus te downloaden, de overgenomen pc inzetten in een botnet of voor crypto mining etc.

Hier een voorbeeldje waar de rekenmachine van Windows wordt gestart:
https://www.youtube.com/w..._continue=1&v=0QaozC8S0Aw

[jetspiking]

Heel erg netjes van Valve dat ze het zo snel aangepakt hebben en ook nog is het doorgeven aan de media. Veel bedrijven doen dit ze niet na.

Nog een extra reden om Steam te gebruiken

[_Thanatos_]

Beter nog, ze hebben het gefixt en gereleased vóórdat de media er lucht van kreeg. Meestal moet een bug eerst in de media komen voordat een groot softwarehuis er iets mee gaat doen.

[Vinxian]

Wat voor mij niet helemaal duidelijk is wat een kwaadwillende zou moeten doen om van deze bug gebruik te maken.
Was de verkeerde website openen terwijl de steam client open stond bijvoorbeeld voldoende?

[vliegendekat]

Een speciaal in elkaar gezet UDP-berichtje sturen naar een willekeurige PC die de steam-client, al dan niet op de achtergrond, heeft draaien.
Zo te zien kan dit ook op afstand door het internet worden geëxploiteerd.

[Squ1zZy]

Het versturen van malformed UDP pakketjes is genoeg voor Remote Code Execution.

In het kort: De aanvaller hoefde dus alleen wat pakketjes te sturen om de machine over te nemen. Er was geen actie nodig van de slachtoffer.

[Bor]

Het versturen van UDP pakketjes is natuurlijk niet genoeg. Het eea moet aan specifieke voorwaarden voldoen. De uitleg inclusief technische details en een video met voorbeeld is direct te lezen via de link in het artikel.

[Loggedinasroot]

Maar 9/10 mensen zitten achter een nat en hebben er geen last van toch?

[kozue]

NAT doet er niet toe. De steam client zet zelf verbindingen op (al is het alleen al naar de steam login server), en dan weet de router wel welk poortje naar jouw computer moet. Alles wat op die poort binnen komt wordt doorgezet, legitiem of niet. Het enige dat nodig is, is achterhalen op welke client poort de verbinding is gemaakt. Maar dat zou je ook moeten als je direct op het internet zit want client poorten zijn over het algemeen willekeurig.

[MSalters]

UDP is problematisch met een NAT, omdat het geen verbinding vormt. Met TCP maak je een verbinding tussen twee hosts, en verbinding die kun je met een NAT simpel omleiden. Maar elk UDP pakketje staat op zich. Het is dus enigzins giswerk hoe je daar een port remap moet doen.

[Loggedinasroot]

Je kan het gewoon op basis van de destination port remappen? OpenVPN kan je gewoon prima remappen als ie luistert op een bepaalde UDP port.

[Verwijderd]

Je hebt helemaal gelijk. @MSalters reactie raakt kant nog wal. Het maakt wat betreft NAT niet uit of het UDP of TCP is. Een port-mapping is een port-mapping, ongeacht welke van de 2 je gebruikt.

[MSalters]

En jij maakt een port mapping aan voor elke webpagina die je bezoekt? Want dat is hoe HTTP werkt: je opent een willekeurige lokale TCP poort, verbindt met remote port 80 of 443, en over die TCP connectie wordt de data teruggezonden. Omdat de TCP port willekeurig is, kun je geen port mapping aanmaken in NAT. Dat is ook niet nodig, NAT snapt TCP. De NAT gateway houdt per TCP verbinding bij welke interne PC daarbij hoort.

Met UDP zou dit niet werken. Er is geen UDP verbinding, per definitie, dus een NAT gateway kan die ook niet bijhouden.

[Verwijderd]

Dat heeft allemaal vrij weinig met NAT/PAT te maken. Je session state table is verantwoordelijk voor het door laten van terugweg verkeer voor NAT sessies die opgezet zijn en deze table wordt automatisch opgeschoond zodra de verbinding afgesloten wordt en als dat niet gebeurd, dan volgt er een timeout (meestal 30 min voor TCP en 2 min voor UDP).

De discussie ontstond uit het feit dat dit een UDP aanval betreft en zoals opgemerkt werd, heb je hier niet echt last van als je achter een NAT zit (wat overigens voor TCP het zelfde zou zijn). Om een UDP/TCP pakket te ontvangen op je destination host die achter een NAT zit, heb je wel degelijk een port-mapping nodig, of een established verbinding met de aanvallende host.

[EnigmA-X]

Om een UDP/TCP pakket te ontvangen op je destination host die achter een NAT zit, heb je wel degelijk een port-mapping nodig, of een established verbinding met de aanvallende host.

Nee, want: source spoofing.

Die port-mapping voor UDP bestaat al (tussen de steam client en steam server). Essentieel in de hele exploit is dat de attacker de source port en ip spoofed. Het is UDP, dus dat boeit in die zin ook heel erg weinig (UDP doet niet aan syn/ack), dus: fire & forget.

Wat wel lastig is in deze exploit, is dat er een client -> server datagram aanwezig moet zijn bij de attacker om de juiste connection id en sequence nummer te hebben (anders worden de exploited pakketjes alsnog gedropped door de client).

[EnigmA-X]

De NAT gateway houdt per TCP verbinding bij welke interne PC daarbij hoort.

Dat doet de NAT gateway ook voor UDP verbindingen. NAT traversal (ook wel hole punching) voor TCP en UDP scheelt niet zo heel erg veel van elkaar in functionele zin.

Dat zo'n beetje iedere router prima in staat is om NAT traversal voor UDP traffic af te handelen wordt m.i. wel bewezen door het feit dat je achter iedere hoekietoekie-router prima DNS-requests kan doen (wat meestal gewoon UDP traffic is).

[RefriedNoodle]

Een port mapping is per protocol, dus tcp of udp. Een mapping voor een tcp port, zal geen udp-pakketjes forwarden. Het maakt dus wel degelijk uit.

@MSalters verhaal klopt op zich wel: udp is sessie-loos, dus een router zal bij dynamische nat iets meer moeite moeten doen om een inkomend udp-pakketje bij een bepaalde flow te matchen, en als zodanig te forwarden naar de juiste host.

Jij hebt het over statische port-mappings, dat is een ander verhaal. De issue daarbij is ook nog eens dat met UPnP een host zelf een portmapping mag aanmaken in de router.

[Nimja]

Dit betekend dus dat de persoon open moest staan voor het internet OF de aanvaller al binnen hetzelfde netwerk zou zitten.

Dus impact viel nog wel mee.

[Squ1zZy]

Helaas. Zoals @Cergorach hieronder al aangeeft is dat er een connectie open staat vanaf je client naar een server. De pakketjes worden dus geaccepteerd als de pakketjes worden vervalst en doen alsof ze van de server komen. Deze exploit heeft wel een CVSS score 10.0 verwacht ik.

@Cergorach AV doet anti-virus en is geen NIDS (Network Intrusion Detection System). Er is geen AV die hier iets tegen doet of je moet een bestand droppen die wordt gedetecteerd, maar dat gaat buiten deze exploit om.

[Slurpgeit]

@Cergorach AV doet anti-virus en is geen NIDS (Network Intrusion Detection System). Er is geen AV die hier iets tegen doet of je moet een bestand droppen die wordt gedetecteerd, maar dat gaat buiten deze exploit om.

In 2000 inderdaad niet nee, tegenwoordig in 2018 doet elk zelfrespecterend anti-malware product ook IDS.

[Torakk]

Was dit ook demanier om die bitcoin miners op je steam te installeren? Dat heeft een maat van me gehad. PC bleef op volle kracht blazen terwijl een spel allang was afgesloten. Na lang zoekwerk bleek dat er iets aan steam hing die dat deed. Uiteindelijk heb ik het gevonden bij hem door de internetkabel eruit te trekken. doen ging alles ineens weer naar idle. Bleek een virus te zijn dat in steam zat.

[Cergorach]

Nee, het was al voldoende om de Steam Client open te hebben staan. Wat ik er van begrijp is dat het code stuurt naar je Steam client en dat door een bug ervoor kan zorgen dat er code wordt uitgevoerd. Er wordt nog wel gekeken van welke server dat code zou komen, maar dat kon ook gespoofed worden. Iva_Bigone heeft al een link geplaatst hoe remote bv. de Windows rekenmachine gestart kan worden op een geheel gepatchde W10 machine.

Wat ik me alleen afvraag is of sommige AV oplossingen dergelijke code executie tegen hadden gehouden of konden detecteren.

@MSalters Nee, niemand wist dat dit issue bestond tot voor een paar maanden geleden, dus je AV weet niet dat je Steam Client bugged is, maar er wordt al langer heuristic intrusion detection toegepast door verschillende oplossingen. De vraag is of deze dit kunnen detecteren, een rekenmachine opstarten is niet echt een issue, maar malafide acties zouden wellicht wel tegen gehouden worden. Niet zozeer de bufferoverflow tegenhouden, maar de acties die daaruit voortvloeien en detecteren. Het probleem is dat ik weet hoe het globaal werkt, alleen niet de specifieke toepassing, vandaar de vraag.

[Reactie gewijzigd door Cergorach op 26 juli 2024 01:39]

[MSalters]

Het lijtk me onwaarschijnlijk dat een AV oplossinge weet dat Steam een bug heeft waarin de buffer voor het eerste pakket te klein is. Vanuit UDP oogpunt is het een volkomen legitiem pakket, de UPP header bevat de correcte lengte. Het past alleen niet in de buffer die Steam klaar heeft gezet.

[kozue]

Maar je moet dus dan ook niet de UDP packets proberen te detecteren, want een AV weet toch nooit wat er in hoort te zitten, maar de buffer overflow. Een buffer overflow is namelijk *nooit* legitiem (tenzij er iemand heel erg slecht heeft zitten programmeren, maar dat soort software kun je beter in z’n geheel blokkeren).
Of en hoe je een buffer overflow kunt herkennen vanuit een extern programma zoals een AV weet ik ook niet (ik programmeer niet eens in talen die daar gevoelig voor zijn), maar als het kan, lijkt het mij dat een AV zoiets wel zou moeten kunnen blokkeren.

[Jerie]

Nee, niemand wist dat dit issue bestond tot voor een paar maanden geleden,

Opzeker wel iemand; het was nog niet publicly disclosed ("0 day") maar dat betekent toch echt iets anders dan dat "niemand van dit issue wist".

[Cergorach]

Ik vermoed dat het niet in het 'wild' is gebruik, maar ik heb daar geen bewijs voor of tegen. Wellicht dat iemand dit heel specifiek heeft gebruikt bij een kleine groep gebruikers met heel weinig invloed op het systeem zelf, anders was men er eerder achtergekomen dmv. onderzoek. Want op een gegeven moment ga gegevens verzamelen van aangevallen PCs, wat hebben deze PCs in common, met een groot genoege set gegevens zou je tot de conclusie komen "He, ze gebruiken allemaal Steam!"... Vervolgens gaan mensen Steam doorlichten. Dat is hier niet gebeurd.

[Jerie]

Yep dat is hier niet gebeurd.

Het was intern bekend bij Steam, bij de melder van de bug, en misschien ook wel bij mensen die dat interne verkeer van Steam af kunnen luisteren. Ik vind het kwalijk dat de bug zo lang unfixed is (1 maand na melding is lang voor een RCE).

[toman]

Dat vroeg ik mij ook gelijk af... hoe reageert de av hierop.

[batjes]

Spoofing Packets

In order for an attacker’s UDP packets to be accepted by the client, they must observe an outbound (client->server) datagram being sent in order to learn the client/server IDs of the connection along with the sequence number. The attacker must then spoof the UDP packet source/destination IPs and ports, along with the client/server IDs and increment the observed sequence number by one.

[thijsken]

Netjes opgelost toch? Binnen 12 uur aangepakt, zo snel mogelijk getest en doorgevoerd in de stabiele versie. Top!

[Verwijderd]

"Het bedrijf heeft Valve op 20 februari van dit jaar op de hoogte gebracht van de vondst en twaalf uur later had het bedrijf het probleem opgelost in de bèta-client. Op 22 maart is de fix in de stabiele client doorgevoerd"

Binnen 12 uur op de bèta-client is lekker snel ja. Maar het mocht nog een maand duren voordat de bug daadwerkelijk doorgevoerd was op de stabiele client. Een kwetsbaarheid wil je toch zsm doorvoeren voor iedereen? Is een maand naar de stabiele versie snel? Zijn andere bedrijven hierin trager?
Heb eigenlijk geen idee

Duidelijk uitgelegd. Bedankt allen

[Reactie gewijzigd door Verwijderd op 26 juli 2024 01:39]

[batjes]

Andere bedrijven hebben vaak wat minder verantwoordelijkheid en geen honderden miljoenen klanten om tevreden te houden.

Een maand testen voor je het live gooit is nog best vlot. Valt echt niets op aan te merken bij Valve.

[supersnathan94]

Mwah ik vind een maand nog best lang. Je wil natuurlijk niet dat de fix van de ene bug een nieuwe introduceerd, maar dat kun je denk ik ook eerder al weten. CI/CD enzo.

[batjes]

Is echt afhankelijk van het niveau van de exploit. Hoe hoger de prioriteit, hoe meer dev/test kracht je er op kan zetten, hoe sneller je bij de uitrol fase aankomt. Het is van veel factoren afhankelijk hoe lang het kan duren, wat dat betreft is een maand hoe dan ook best netjes, de industriestandaard is 2-3 maanden. Intel heeft bv bijna een jaar nodig om hun exploitjes te fixen.

Haastige spoed is zelden goed, beter even wat langer testen dan abrupt uitrollen. Wat zou duurder zijn, 100.000 mensen aan de support, of 2 weken extra testen.

Verder is dit een mitm aanval, je zult eerst verkeer tussen steamclient en server moeten onderscheppen wil je het misbruiken. Het lijkt me wat dat betreft niet een al te serieuze exploit (als iemand je man in the middled, dan maakt dit nog maar weinig uit, maakt het wel wat makkelijker). Als je dat meerekent, dan is een maand helemaal dikke prima.

Nogmaals, niets op aan te merken aan Valve in dit geval. Prima gehandeld.

[Chud]

Hierboven is een discussie over een AV die dit zou moeten oppakken. Onlangs is mij uitgelegd dat de toekomst van AV en veiligheid niet meer zit in traditionele AV (bestanden scannen) maar is gedrag herkenning. Als voorbeeld werdt webroot gemeld.

Had zo'n nieuwerwets AV programma misbruik van exploits als deze tegen kunnen gaan?

[Mellow Jack]

CI of niet CD... Het is best mogelijk dat ze de aanpassingen op die hele berg beta testers willen testen om te zien of het geen bijeffecten heeft

[alt-92]

A/B testing in PRD.

[erwinwernars]

ze hadden inderdaad deze fix wel als een losse hotfix in de stable versie gooien. maarja dan is de vraag de veiligheidslek bestaat al 10 jaar, waarom alles omgooien ervoor om het 1 maand eerder te releasen

[Grrrrrene]

1 maand op 10 jaar is nog geen 1% van de tijd dat de kwetsbaarheid heeft bestaan. Als het "gat" 10 jaar lang niet is misbruikt, waarom zou dat dan specifiek in die ene maand wel gebeuren?

[Bor]

Men weet niet of het gat is misbruikt of niet. Dat is een belangrijk nuance verschil. Bij een succesvolle en relatief makkelijke remote code execution kan het duren voordat de exploit publiek bekend wordt gemaakt. Dit soort exploits zijn ook interessant voor bv spionage etc.

[DiaZ_1986]

In juli vorig jaar voegde Valve address space layout randomization-beveiliging toe aan de client. Sindsdien is de kwetsbaarheid niet zonder meer te misbruiken, maar leidt uitbuiting ervan tot crashes.

Lijkt erop dat er al een dirty-quick-fix was doorgevoerd waardoor het misbruik ervan al niet meer mogelijk was. Dus dat er een maand tussen zat geeft enkel aan de ze het belangrijker vonden om het stabiel te houden..

[Reactie gewijzigd door DiaZ_1986 op 26 juli 2024 01:39]

[daellat]

Komt mij meer over als een bij effect van ASLR omdat valve toen nog nog niet afwist van de kwetsbaarheid. Want zodra ze van de kwetsbaarheid wisten was het binnen een dag net gefixt in de beta.

[Blokker_1999]

Zolang er geen bewijzen van misbruik zijn moet je de risico's afwegen tussen een patch doorvoeren die niet getest is en nieuwe problemen kan veroorzaken of een bug laten bestaan die voor zover bekend in die 10 jaar nooit misbruikt is.

[Cergorach]

Het bron artikel heeft het over 8 uur van melding tot push naar de beta client:

This bug was disclosed to Valve in an email to their security team ([e-mail]) at around 4pm GMT and just 8 hours later a fix had been produced and pushed to the beta branch of the Steam client.

Dat staat helemaal onderin, kennelijk heeft iemand niet het hele arttikel gelezen...
Verder is dit issue al in maart/april in de productie client gereleased:

Our vulnerability was reported to Valve on the 20th February 2018 and to their credit, was fixed in the beta branch less than 12 hours later. The fix was pushed to the stable branch on the 22nd March 2018.

Patch notes van 21 maart met updates voor 4 april:
https://store.steampowered.com/news/38412/

[Reactie gewijzigd door Cergorach op 26 juli 2024 01:39]

[janjwjmc]

Het nieuws hierop loopt wat achter

[LOTG]

Op zich wel, maar zoals @Verwijderd zegt had het eigenlijk ook met een hotfix in de stabiele client moeten worden uitgerold.

Het aantal gebruikers wat niet op de beta client zit was gedurende een maand nu nog steeds kwetsbaar.

Gezien dit een remote execution exploit was is de ernst dus ook erg hoog.

[roy-t]

address space layout randomization-beveiliging toe aan de client. Sindsdien is de kwetsbaarheid niet zonder meer te misbruiken, maar leidt uitbuiting ervan tot crashes. Vanaf zeker 2008 heeft het lek er echter ingezet, claimt Contextis, en ook na juli 2017 was misbruik nog mogelijk met extra informatie over de geheugenlocatie van de Steam-app.

Dit stukje is ook belangrijk. De bug was eigenlijk niet meer te misbruiken in de (toen huidige) steam client. Hier staat nog de bijzin bin dat de bug nog wel te misbruiken was "met extra informatie over de geheugenlocatie van de Steam-app". Maar dat staat er even te makkelijk bij. Om die informatie te krijgen zul je op een andere manier het systeem binnen moeten komen en zelfs dan is het in Windows niet makkelijk om het geheugen adres van een ander process te bemachtigen.

Ik denk dat Valve dus netjes gehandeld heeft. De patch redelijk snel uitgerold, maar niet het gewone beta->stable process overslaan.

[Blokker_1999]

Ze was nog altijd te misbruiken, al kwamen er ineens een hoop randvoorwaarden bij kijken die eigenlijk al bijna verplichten dat je reeds op een andere manier toegang had tot het systeem.

[BernardV]

De ernst was niet meer zo hoog. In de tekst staat ook dat Valve vorig jaar juli aslr heeft toegevoegd en daardoor was het lek niet meer te misbruiken.

In juli vorig jaar voegde Valve address space layout randomization-beveiliging toe aan de client. Sindsdien is de kwetsbaarheid niet zonder meer te misbruiken, maar leidt uitbuiting ervan tot crashes.

[Milo44]

Toch vind ik het dan slordig dat ze er 10 jaar mee wachten?

[iam2noob4u]

"Wachten" is denk ik niet helemaal het goede woord. Het lijkt erop dat het probleem niet bekend was bij Valve.

[KeRsTmAnNeKe]

Maar was het ook al 10 jaar bekend? Nadat het Valve bekend is gemaakt hebben ze binnen 8 uur dus al een fix gemaakt.

[hooibergje]

Inderdaad. Kunnen een hoop bedrijven nog een hoop van leren.

[_Thanatos_]

Maar hoe hebben ze nou kunnen weten dat het lek er 10 jaar in zat, als ze pas recent erop zijn gaan testen?

[Xfade]

Omdat die code die ze nu aangepast hebben al 10 jaar hetzelfde was ?

[_Thanatos_]

Vanaf zeker 2008 heeft het lek er echter in gezeten, claimt Contextis

Contextis is een extern bedrijf. Die hebben niet de sourcecode van Steam. Dus nog steeds rest de vraag hoe ze dit weten.

[Xfade]

Het gaat om de Client.

"The Steam protocol has been reverse engineered and well documented by others (e.g. https://imfreedom.org/wiki/Steam_Friends) from analysis of traffic generated by the Steam client. The protocol was initially documented in 2008 and has not changed significantly since then."

https://www.contextis.com...ility-in-the-steam-client

[Juantinto]

Hebben ze de Valve weer dicht gedraaid?

[Dr.Root]

Zo konden cheats ook weggeschreven worden in de buffer van steam? En zo dus, undetectable?

[RoyReyn]

Even helemaal off-topic maar ben ik de enige die de autheur op Mark Zuckerberg vind lijken?