Zeroday in Steam is openbaar gemaakt na onenigheid over bugbountyprogramma

Een beveiligingsonderzoeker heeft een zeroday in Steam openbaar gemaakt. Dat deed hij uit onvrede over het beleid van Valve rondom responsible disclosure. De hacker was eerder uit het HackerOne-programma verwijderd.

Het gaat om een local privilege escalation in de Steam-client voor Windows, schrijft de Russische hacker en onderzoeker Vasily Kravets in een blog. Met de exploit kunnen andere apps adminrechten krijgen in Windows via de Steam-app. Het is de tweede zeroday die de hacker in twee weken tijd bekendmaakt.

Kravets ontdekte twee weken geleden al een andere local privilege escalation. Hij meldde dat aan Valve via HackerOne, een bedrijf dat responsible disclosure-meldingen coördineert tussen bedrijven en hackers. Volgens Valve was het lek echter niet groot genoeg om aanspraak te maken op een beloning. Toen Kravets daarop alsnog details publiceerde over de kwetsbaarheid, werd hij uit het HackerOne-programma verwijderd. Door de publicatie zou hij de regels van het programma hebben geschonden.

Inmiddels heeft Kravets dus een tweede lek ontdekt. Ook daarbij gaat het om een lpe, waarbij een aanvaller wel eerst fysieke toegang tot een machine moet hebben. Daar zit het probleem volgens Valve. In de scope van het bugbountyprogramma op HackerOne zegt Valve dat lpe's wel degelijk onder de beloningscriteria vallen, maar dat geldt alleen bij aanvallen met malware of gecompromitteerde software. In dit geval, waarbij een aanvaller fysiek op de machine moet zitten, valt het lek buiten de reikwijdte, zegt Valve. Hetzelfde geldt voor aanvallen waarbij een gebruiker bestanden op willekeurige plekken in het OS moet zetten, al ontkent Krevats dat dat laatste nodig is om deze kwetsbaarheid uit te buiten.

Valve heeft het eerdere lek in Steam wel gerepareerd, nadat daar veel negatieve media-aandacht over kwam. Wel zegt een andere beveiligingsonderzoeker dat hij de fix kan omzeilen. Het gamebedrijf heeft nog niet gereageerd op het huidige lek.

Reacties (109)

[Vizzie]

begrijpelijk dat ze iets van criteria hanteren. Die zijn nog openbaar ook dus deze kerel had vooraf kunnen kijken of hij een beloning kon krijgen.

Beetje flauw om die bugs dan op internet te gooien als je vooraf had kunnen weten niet in aanmerking te komen voor een beloning en in ook nog een programma zit waarbij je hebt afgesproken dat niet te doen. Logisch dat je daar dan uitgetrapt wordt.

[terracide]

Dit zijn niet gewoon hackers, maar professionals die bugs vinden als beroep. Ik kan me voorstellen dat als de voorwaarden niet duidelijk zijn je daar enorm van baalt. Want je doet eigenlijk werk wat Valve zelf had moeten doen. En als zij niet betalen omdat volgens Valve die bugs niet serieus genoeg zijn dan kan ik me voorstellen dat je ze op het internet zet. Het is nogal vreemd dat ze niet willen betalen want die bugs zijn niet ernstig genoeg, maar aan de andere kant mag je er niks over zeggen want hij kan wel misbruikt worden. Lekker dubbel. Want als dan toch blijkt dat deze bugs worden misbruikt door malware dan zit er niks anders op dan de voorwaarden van Valve aan te passen. Het is gewoon betalen of je maakt ze openbaar want dan hebben ze geen waarde voor niemand ook niet voor malware makers. Wat Valve nu doet is lekker goedkoop, maar totaal oneerlijk als je het mij vraagt.

[GeoBeo]

Dit zijn niet gewoon hackers, maar professionals die bugs vinden als beroep. Ik kan me voorstellen dat als de voorwaarden niet duidelijk zijn je daar enorm van baalt. Want je doet eigenlijk werk wat Valve zelf had moeten doen. En als zij niet betalen omdat volgens Valve die bugs niet serieus genoeg zijn dan kan ik me voorstellen dat je ze op het internet zet. Het is nogal vreemd dat ze niet willen betalen want die bugs zijn niet ernstig genoeg, maar aan de andere kant mag je er niks over zeggen want hij kan wel misbruikt worden. Lekker dubbel. Want als dan toch blijkt dat deze bugs worden misbruikt door malware dan zit er niks anders op dan de voorwaarden van Valve aan te passen. Het is gewoon betalen of je maakt ze openbaar want dan hebben ze geen waarde voor niemand ook niet voor malware makers. Wat Valve nu doet is lekker goedkoop, maar totaal oneerlijk als je het mij vraagt.

Laten we niet vergeten wat de kern is waarvoor bug bounty programma's bestaan.

In de echte wereld zijn er 2 manieren om geld te verdienen met het vinden van bugs:
1. Verkopen van het lek aan de auteur van de software via een bug bounty programma. Zodat het lek gerepareerd kan worden.
2. Verkopen van het lek op de zwarte markt aan de hoogste bieder. Zodat het lek actief misbruikt kan worden.

Als optie 1 niet werkt en je geen zin hebt in de ethisch twijfelachtige aanpak van optie 2, dan heb je optie 3: publiceren om druk te zetten. Of optie 4: wachten tot iemand anders hetzelfde lek vindt en wellicht voor optie 2 kiest: een andere hacker krijgt het geld voor het werk dat jij al gedaan hebt.

Valve is raar bezig, want aan de ene kant claimen ze dat de bug geen geld waard is en onbelangrijk is, maar tegelijk vinden ze hem wel belangrijk genoeg om hem te repareren. In feite heeft de hacker dus gratis werk geleverd voor Valve.

Elke volgende hacker die bugs in Valve software vindt (en ethisch weinig bezwaren heeft) gaat dus de volgende keer lekker direct naar de zwarte markt om daar z'n bug te verkopen in plaats van de Groningers van Hacker1 of Valve.

Eindresultaat: Valve krijgt een slechte goedkope reputatie, Valve krijgt de reputatie onveilige software te bouwen en Valve security bugs worden op de zwarte markt vekrocht aan overheden en criminelen met slechte bedoelingen. Dat maakt de software dus feitelijk risicovol om te gebruiken.

[D0phoofd]

Want je doet eigenlijk werk wat Valve zelf had moeten doen.

Zeker niet. Het zorgt juist voor een ingang waar zij gevonden exploits of fouten kunnen aankaarten bij de maker van het programma tegen een vergoeding. Dat mensen daar hun werk van maken is natuurlijk niet gek als zij hier aanleg voor hebben.

Wat deze man hier doet is natuurlijk wel terecht (in mijn optiek). Want als hij meermaals een Privelige Escalation (wat een exploit is die veel impact kan hebben), hij deze aankaart via de officiële kanalen. Maar word hier afgewezen, dan een keer goedgekeurd, maar toch weer afgewezen... Dan snap ik wel dat hij 'm publiceert.

Hij kreeg zelf namelijk de indruk dat Valve geen waarde hechtte aan de feiten.
"Here I realized that Valve has no interest in EoP vulnerabilities." - Link


Edit:

Even een kant tekening. Dit soort voorvallen, zoals Valve nu omgaat met bounty-hunters van kastje-naar-de-muur sturen. Mogelijk minder 'incentive' geeft aan dit soort mensen om de exploits te rapporteren.

Dit lijkt mij gewoon een goedkope fix voor Valve op deze manier.

[Reactie gewijzigd door D0phoofd op 23 juli 2024 11:51]

[Vizzie]

Maar die voorwaarden zijn (in elk gebal op het punt van bugs waarvoor je fysieke toegang tot de pc van de gebruiker nodig hebt) glashelder.

Niemand dwingt deze man in de software van valve duiken of deel te nemen aan een bounty programma.

Als hij daarvoor kiest en akkoord gaat met bepaalde voorwaarden moet hij zich daar aan houden.

Hij kan toch ook software van een leverancier met een ruimhartiger / opener beleid gaan onderzoeken als hij het niet eens is met voorwaarden van het programma van valve?

[nobraininvolved]

maar als iemand iets vind en de fabrikant geeft aan dat 't niet belangrijk genoeg is om er iets aan te doen (of een bounty te geven), dan is hij vervolgens toch vrij om ermee te doen wat hem goeddunkt? Immers; de fabrikant toont geen interesse en doet 't af als 'niet belangrijk'.
't is 't 1 of 't ander: Of het is interessant genoeg en valt onder de bountyregeling, OF het is niet interessant genoeg en dan mag 't dus gepubliceerd worden...
Ik begrijp die hacker wel hoor...

[Kaasrol]

Steam ziet LPE bugs zoals deze niet als hun probleem. Het valt buiten hun scope en eerder weigerden ze al hiervoor te betalen of überhaupt fixes door te voeren, zoals ook in het artikel vermeld. Echter willen ze niet dat erover gepubliceerd wordt..? Dat staat nogal met elkaar in conflict als je het mij vraagt.

Steam sloopt het securitymodel van Windows en zou haar verantwoordelijk moeten nemen.

[Reactie gewijzigd door Kaasrol op 23 juli 2024 11:51]

[Vizzie]

Dat is een andere discussie, of die bug wel of niet belangrijk is.

In de kern gaat het erom dat deze man een afspraak maakt met hackerone (niet met valve) over hoe met bugs omgegaan wordt (niet op internet zetten blijkbaar).

Vervolgens vindt hij een bug die niet in aanmerking komt voor een beloning (kan je het wel of niet mee eens zijn, ook weer een andere discussie) en zet hij in strijd met de afspraken die hij gemaakt heeft met hackerone de bug op internet.

Ik vind het volkomen logisch dat hem dan de deur wordt gewezen.

Misschien moet valve de criteria voor beloningen voor bugs aanpassen of meer bugs in de scope van hun verantwoordelijkheid trekken, misschien moet MS Windows aanpassen om lpe moeilijker / onmogelijk te maken maar ik vind de manier waarop deze onderzoeker zich heeft gedragen niet ok.

Als je je niet aan bepaalde afspraken wilt houden maak dan geen afspraken.

[Robbiedobbie]

De bug kwam niet alleen niet in aanmerking voor een beloning, de bug kwam niet in aanmerking om gefixt te worden omdat deze buiten de scope viel. Dat is een belangrijk verschil. Als de bug buiten de scope van het programma valt, waardoor hij niet gefixt kan worden, zou het ook buiten de scope moeten vallen kwa afspraken met hackerone (het is tenslotte buiten de afgesproken scope).

[alexiooo]

Je vergeet dat dit soort dingen publiceren in beginsel illegaal is. Door HackerOne constructies is het nu wel geaccepteerd, maar als je volledig buiten die afspraken wilt werken kan je nog steeds niet vrijelijk publiceren.

[Unsocial Pixel]

In welk beginsel is het publiceren van je eigen observatie op je eigen systeem illigaal?

[!GN!T!ON]

Je vergeet dat dit soort dingen publiceren in beginsel illegaal is.

Heb je daar een bron bij? Dat klinkt mij heel raar in de oren namelijk...

[Robbiedobbie]

Dat is weer een hele discussie opzich. Het is namelijk maar net de vraag of dit als illegaal gezien moet worden, simpelweg omdat hij niet op andermans systemen heeft zitten werken, noch aanpassingen in steam zelf heeft gedaan. Hij heeft alleen geobserveerd wat steam op zijn eigen systeem doet, en alleen een paar wijzigingen in zijn systeem (Niet in steam zelf) gedaan, die door gebrekken in steam ervoor zorgen dat hij administrator rechten kan krijgen. Daarna heeft hij simpelweg zijn verhaal gedaan hoe dit kan.

Maar ik denk dat de discussie of het wel/niet legaal is om dit soort fouten op te sporen zonder HackerOne constructies niet interessant is in dit geval. Tenslotte is hier al een punt van discussie of de bug binnen de NDA valt op het moment dat HackerOne het buiten scope rekend.

[Yaz]

Welke wetgeving is dan verantwoordelijk voor het niet mogen verspreiden van gevonden problemen? Volgens mij geen.

[lonegunner]

denk dat valve de rechten heeft op de files, dus publiceren is altijd in strijd met de wet(volgens mij)

[Yaz]

Ze publiceren toch niet de bestanden maar hoe je iets kan doen met die bestanden. Een beetje zoals een kookboek.

[aldieaccounts]

Precies.

[SuperDre]

Zoals Robbiedobbie aangeeft, het ging niet zozeer om het niet in aanmerking komen van een beloning, maar vooral om niet in aanmerking te komen om opgelost te gaan worden... Tja, wil je het niet oplossen, dan zou ik ook het lek publiceren want blijkbaar vind je zelf het probleem niet ernstig genoeg als deze bekend zou zijn.
Je zou het zelfs zo kunnen zien dat het onverantwoord was om het NIET te publiceren..
Ik ga er van uit dat hij het niet gepubliceerd zou hebben als men gewoon netjes had gezegd dat de bug zo snel mogelijk opgelost zou worden (en met snel bedoel ik dan gewoon in EEN volgende update, niet pas over een paar jaar).

[LankHoar]

Niet logisch. HackerOne zou zicht achter hun hackers moeten scharen en tegen Valve in gaan over dit besluit. Zo maak je ethische hackers boos, en het is beter om ze te vriend te houden.

[alexiooo]

Aan de andere kant snap ik Steams reactie ook wel. Dit is een bug die fysieke toegang nodig heeft. Wanneer is de laatste keer dat je met een machine hebt gewerkt waar Steam op staat en die belangrijk genoeg is om je zorgen te maken over potentiële hackers met fysieke toegang.

Security is belangrijk, maar goed nadenken over je threat model valt daar ook onder.

[SuperDre]

Genoeg mensen die Steam op publieke computers gebruiken..
Dat het niet zo'n hoge prioriteit heeft geloof ik wel, maar hier werd blijkbaar zelfs gezegd dat ze het niet gingen oplossen... tja, als je zoiets zegt, dan vindt je het dus ook niet erg als het lek gepubliceerd wordt (want iemand anders zou het ondertussen ook wel gevonden kunnen hebben). Had je gezegd, we gaan het proberen op te lossen in een volgende update, dan zou hij waarschijnlijk ook het lek niet gepubliceerd hebben (tot een paar updates na enkele maanden later misschien, als het dan nog steeds niet gefixed is).

[Rmg]

Als Lan/Game cafe exploitant zou dit best wel eens een groot issue kunnen zijn..

[!GN!T!ON]

Maar dan is het toch ook geen enkele issue om de bug te publiceren?

[halofreak1990]

Ik snap er juist helemaal niets van. Als ontwikkelaar zou je elke bug er een te veel moeten vinden, ongeacht de impact.

[Robbiedobbie]

Zo werkt het niet helemaal natuurlijk. De onderzoeker heeft toch echt wel serieuze beveiligings issues gevonden die volgens valve niet in de scope van hun bugprogramma vallen. Echter zijn het wel issues die opgelost moeten worden, omdat misbruik echt wel mogelijk is.

Valve is hypocriet om te zeggen dat het geen problemen zijn, maar vervolgens wel te verbieden erover te praten. Als het allemaal veilig zou zijn, dan mag er toch over gepraat worden? Uiteindelijk heeft deze onderzoeker ervoor gekozen om deze bugs publiekelijk te maken zodat ze wel opgelost kunnen worden. Tenslotte zouden ze anders onopgemerkt misbruikt kunnen worden door anderen die het ook ontdekt hebben (Een andere onderzoeker had individueel dezelfde fout al ontdekt).

Daarom is het ook goed dat hij nu alsnog een 2e bug op deze manier publiceert. Zo wordt valve alsnog gedwongen om de beveiliging in orde te krijgen. Anders zorgt steam op windows ervoor dat je pc direct een heel stuk minder veilig is geworden.

[TijsZonderH]

Ik weet eerlijk gezegd niet of Valve dat heeft verboden, ik weet alleen dat HackerOne dat deed. Verandert de situatie wel een beetje

[SuperDre]

Niet echt, uiteindelijk is Valve de eindverantwoordelijke, ZIJ maken gebruik van HackerOne..

[CTVirus]

https://hackerone.com/valve

> Please note that we will not consent to disclose reports if they have been marked out-of-scope or inapplicable, or where Valve has not taken a specific corrective action / mitigation.

[Unsocial Pixel]

Notitie gemaakt, ze zijn het er niet mee eens.. Tja ik ben het ook welleens niet met dingen eens. Slikken of stikken dan maar he

[Amorac]

Hackerone ligt hier niet wakker van hoor, die doen gewoon geen zaken meer met de onderzoeker. Het stikken en slikken zal eerder door de onderzoeker gedaan worden.

[Osiummaster]

De reputatie van Hackerone gaat hier niet op vooruit. Als ze ethische hackers gaan aanvallen dan gaat iedereen voortaan de zwarte markt op met dit soort bugs.

[Robbiedobbie]

Nee ok, misschien heb ik dat niet heel lekker verwoord. De onderzoeker heeft wel nog contact proberen te leggen met Valve zelf, maar die verwezen hem terug naar HackerOne. Mijn punt is meer dat je de onderzoeker niet kwalijk kan nemen dat hij die bug uiteindelijk toch openbaar heeft gemaakt.

Verder kun je natuurlijk het beleid van Valve in twijfel trekken omdat ook LPE bugs echt opgelost moeten worden. Zeker als gamebedrijf wat zich ook op kinderen focust. Stel een ouder geeft een kind bewust geen admin rechten om bepaalde zaken te voorkomen. Dankzij deze bugs kan het kind die rechten toch verkrijgen (En ja, ook kinderen kunnen dit toepassen).

[TijsZonderH]

Dat laatste ben ik zeker met je eens. Dat eerste denk ik ook wel, ik bedoelde ook meer dan ik niet zeker weet wat de voorwaarden van HackerOne zijn in zo'n geval en of je hen makkelijker kunt negeren dan een bedrijf zelf.

[Jerie]

Valve is degene die de ticket heeft gesloten. Heb ik gezien dmv een screenshot van de issue.

[supertheiz]

Even als vergelijking: Hij heeft aangetoond dat je de voordeur van je woning van binnenuit kan openen zonder een sleutel.
Valve zegt: Geen security probleem, want je moet eerst in de woning komen en dat kan niet zomaar.
Kravets zegt: Wel een security probleem, want ook binnen in je woning moet je de sleutel gebruiken.

Lastig, ze hebben beiden een punt.
Echter het feit dat ze zsm worden gedicht lijkt erop te wijzen dat Valve ze toch ook wel belangrijk vindt.

[Vizzie]

Dat is mijn punt niet.

Valve zegt voor dit soort meldingen krijg je geld via dit programma en voor deelname gelden deze voorwaarden.

Hij doet een ander soort melding, krijgt geen geld en schendt vervolgens de voorwaarden van het programma waar hij mee akkoord is gegaan.

Als hij dingen waar hij geen geld voor krijgt gewoon op internet wil zetten: prima, maar spreek dan niet af dat je dat niet zal doen door deel te nemen aan een programma dat dat in zn voorwaarden verbied.

[supertheiz]

Niet helemaal waar.
Kravets vindt dat het wel onder de voorwaarden valt, Valve vindt van niet.
Valve zegt de overeenkomst op, waardoor Kravets vindt dat hij zich ook niet meer aan die overeenkomst hoeft te houden.

Of om jouw laatste stukje te veranderen:
Als Valve vindt dat het geen security issue is en daar niet voor wil betalen, prima. Maar repareer dat dan ook niet via een prio 1 security patch.

[Vizzie]

Volgens mij vindt hij niet dat het wel onder de voorwaarden valt maar dat dat wel zo zou moeten zijn.

Er staat letterlijk echt letterlijk in die voorwaarden dat meldingen waarvoor fysieke toegang tot de pc nodig is buiten de scope vallen. Hij kan dus nooit vinden dat het er wel onder valt tenzij hij niet kan lezen.

En valve zegde de overeenkomst op NADAT hij de overeenkomst geschonden had, niet daarvoor.

[fre0n]

Bovendien, als t niet binnen de voorwaarden van t programma valt en niet als security issue van valve gezien wordt, valt t ook niet binnen de nda

[Robbiedobbie]

De vergelijking klopt niet helemaal. Vergelijk het eerder met een afgesloten kamer in je woning waar je de sleutel niet van hebt, maar welke je toch kan openen. Valve zegt, geen probleem want je moet eerst toegang hebben tot het huis.
Echter heeft het bezoek nu opeens toegang tot een afgesloten ruimte, terwijl die ruimte natuurlijk bewust is afgesloten voor het bezoek.

[Tommy_K]

Deze kwetsbaarheid is vooral een probleem voor systeembeheerders die gebruikers beteugeld hebben, als je via deze route dus administrator rechten kan krijgen op je werkcomputer zijn ze daar niet blij mee.

En ja werkcomputers hebben over het algemeen geen Steam geïnstalleerd staan maar dat zou geen reden moeten zijn om dit gat in de beveiliging open te laten.

[redniels]

Echter.... Valve liegt. Valve heeft geen punt. ze hebben het verprutst.
De voordeur kun je nog steeds niet van binnenuit openen. Die zit nog goed op slot, en de sleutel is van het slot afgehaald. Nee... het is erger!: Ze hebben een manshoog gat in de muur gemaakt naast de voordeur!

Steam geeft schijnbaar

(ik ben tot op heden te "druk" geweest met The BOYS (FUCKING DIABOLICAL!) op amazon en mijn Netflix verslaving ;-) om dit te checken op mijn gamepc)

op HKLM\iets\valve
en op de steam service (mmc services.msc)
en op [steam_install_location]\bin

Everyone: Full control. Op het moment dat zoiets gebeurd zet je werkelijk alles buiten spel qua windows security model. Iedereen mag alles zolang het maar op (of door!)een van deze plekken gebeurd. Da's wachten op shit en da's nu gebeurd.

Dit heeft helemaal niets meer te maken met local elevation en alles met het opzettelijk vermoorden van het windows security model door Steam.

Als iedere gebruiker daar alles mag... kan iedere gebruiker (dus ook dat scriptje op die website die je opent in je browser welke draait onder jouw user, of die phishing mail waar nog steeds 50% van de mensen op klikt) daar ook alles wijzigen. En dat gebeurd hier. In plaats van een game of de steamservice te starten, wordt de inhoud daarvan gewijzigd waardoor er wat dan ook wordt opgestart....(everyone: Full control, remember? Dus ook bestanden/regkeys/services vervangen/overschrijven/veranderen op die plek!)

Onder welke user draaien die dan? Wel...uiteindelijk de SYSTEM (of vergelijkbaar, misschien installer) account.. Yikes.

Zolang dat principe (Everyone: Full control) niet wordt losgelaten blijft dit bestaan. Hij doet nu eigenlijk weer hetzelfde truukje als voorheen, met wat bait & switch tussendoor om een extra ingebouwde check te omzeilen. Het is weer mogelijk door deze belachelijke rechten..

Dit is niet het eind. Dit wordt nog erger. Steam is op deze manier een groot attack surface geworden en ik vind het bijzonder dat dit nooit eerder naar buiten is gebracht. Dit is niet te fixen, dit moet opnieuw bedacht en gemaakt worden. Valve heeft een leuke uitdaging erbij.

De vraag rijst natuurlijk wel: Hoe hebben GOG, Origin, Uplay, Epic store, etc etc etc dit probleem getackeld? ook op deze droevige manier?
(het probleem is nieuwe games/updates installeren zonder continu nagging UAC JA/NEE popups)

[DataGhost]

Dit is niet te fixen, dit moet opnieuw bedacht en gemaakt worden. Valve heeft een leuke uitdaging erbij.
[..]
(het probleem is nieuwe games/updates installeren zonder continu nagging UAC JA/NEE popups)

Hoe kom je erbij dat het opnieuw gemaakt moet worden? Je kan gewoon de wijzig-rechten dichtzetten, dat is tenminste het probleem voor zover dat op te maken is uit jouw post. Ik ben zelf ook een Steam-like programma aan het maken waarmee ik "zonder admin-rechten" toch dingen kan installeren zonder popup, en zonder dat dat maar door iedereen te exploiten is. Dat is echt niet zo moeilijk.

[redniels]

Ik dacht dat ik gereageerd had maar ik zal wel niet goed op plaats reactie hebben geklikt...dus... Let's try that again!

Als er gebeurt wat jij voorstelt... dan werkt het niet meer. dan komen er weer UAC prompts en dat is (waarschijnlijk) wat steam probeert te voorkomen!
Als jij jouw programma schrijft op eenzelfde manier als steam en dan dwars door UAC en de installer services heen gaat... Dan is dat gemakkelijk te exploiten. Je bent obscuur en daardoor redelijk veilig maar... Security through obscurity is nooit heel erg sterk geweest.

Ik heb ook nooit gezegd dat het moeilijk is om het security model van Windows kapot te maken, het is alleen niet slim.

Wat heeft Valve gedaan:
1) een regkey onder HKLM aangepast. Alles onder die key mag door iedereen worden aangepast (Everyone: Full control) via deze key kun je steam de opdracht geven om iets op te starten. Yikes. Dat draait dan ook nog onder system. Yikesx2. HKLM is by design Everyone: READ, admin/system FULL. maar dat is niet afgedwongen.

2) de rechten op de steamservice aangepast naar everyone: full control. iedereen heeft dus de controle over de service, de service definitie en het starten en stoppen daarvan. Yikes. Die draait ook onder system.. Wha.. Yikes? (let op he: je geeft hier een willekeurige user de rechten om alles te doen.. ALLES met een proces wat draait onder de hoogste lokale autoriteit: SYSTEM. SYSTEM kan meer dan local admin. Da's not done, maar goed, dit is de 2e keer al dus let's carry on. Alweer: Services zijn by design Everyone: READ, admin/system FULL. maar dat is niet afgedwongen.

3) De rechten op de \bin dir aangepast zodat iedereen en alles daar kan wijzigen en schrijven. je kan dus doom.exe vervangen door engvirus.exe. Dat kan je vrij gemakkelijk voor elkaar krijgen bij 30% van de gebruikers via een phishing mail of zo. en (bijna) iedereen heeft Steam..

Op dit moment zijn er dus 3 attack vectors voor steam.. Er zitten schijnbaar nu wat checks en balances in Steam maar deze zijn wederom simpel te omzeilen via een bait & switch door wat te kloten met open file locks..

Dat zijn allemaal dingen die onder een gewone user kunnen draaien, daar heeft Valve voor gezorgd.. En met open file locks spelen in je eigen user sessie is ook niet zo'n probleem.. Dus... een beetje slimme dev kan een scrippie in elkaar draaien en embedden in een html-etje of whatever (brak docje, jpg, etc) en bob's your uncle, you're powned. alles wat die steamservice aftrapt draait onder SYSTEM. en mag. dus. alles.

-*boom!*-

Nou.... waarom zeg ik dat dit moeilijk op te lossen is:
Omdat ik aanneem dat het hele doel is om games en steam zelf te installeren en/of te updaten zonder UAC prompts. want gebruikers zijn stom en klikken op NEE of klikken helemaal niet.
Als je dit veranderd, haal je een basis functionaliteit van Steam weg. en die klote UAC prompts komen terug... en het hele zooitje valt om.

[DataGhost]

Ik weet ondertussen wat ze hebben gedaan, en dat is supersimpel op te lossen door te zorgen dat je een beperkte set acties als niet-admin kan initieren. Bijvoorbeeld toestaan dat iemand op de knop "update alles" mag klikken, dat kan je volgens mij met Windows Update ook als niet-admin doen, ook al gebeuren er daarna dingen die je niet zonder adminrechten mag doen. Dat is verder niet inherent onveilig als het verder fatsoenlijk dichtgetimmerd is. In dat opzicht is Steam, of in ieder geval het concept, ook gewoon veilig (mits deze lekken zijn opgelost) want je hebt maar een beperkte set software (games) waar je uit mag kiezen en het runnen ervan gebeurt zonder admin-rechten. Het gaat alleen om installatie en updates.
1) De regkey is niet heel spannend als de service niets anders doet dan games installeren/verwijderen. In dit geval kon je er een pad mee aanpassen naar een pad waar jij controle over had. Zorg gewoon dat die key niet writable is en je functionaliteit is hetzelfde maar niet meer exploitable. Dat het in HKLM staat maakt ook geen reet uit, al stond het ergens anders, als je programma op welke manier dan ook input accepteert van non-admins moet dat gevalideerd worden. Hier is waarschijnlijk iets van feature creep aan de hand geweest, volgens mij mag de non-admin client legitiem schrijven in die subkeys (en dat hoeft ook geen probleem te zijn, ook niet in HKLM, je installeert een game namelijk op de machine en niet alleen voor 1 user) maar hebben ze later in dezelfde key een pad gezet wat gebruikt kan worden om de service iets anders te laten doen, en zijn ze vergeten dat die key world-writable was. Kijk maar wat er in die key staat, dan wordt het je wel duidelijk.
2) Een service starten is ook niet spannend als niet-admin en dat gebeurt opzich best vaak. Bijvoorbeeld muziek afspelen kan je als normale user omdat er een service (Windows Audio) met hoge privileges draait die vervolgens tegen de hardware praat (wat jij niet mag als normale user). Yikes? Mwah niet echt. Ik heb misschien de update al, maar de service*definitie* is bij mij niet world-writable, dus daar is niks mis mee. Het gaat om het starten van de service als non-admin, wat op zichzelf dus niet raar is behalve:
3) De rechten op de bin-dir zijn het eigenlijke probleem. Dat mag natuurlijk nooit gebeuren. De service binary is te vervangen door een eigen programma en gecombineerd met het mogen starten van de service als non-admin zorgt dat ervoor dat je willekeurige code kan draaien als SYSTEM. Zet dat (world-schrijfrechten op bin\) dicht en het maakt echt niet meer uit wie die service kan starten/stoppen omdat je niks anders doen dan hem starten en stoppen, en die acties zijn op zichzelf volstrekt ongevaarlijk. Dus er zijn geen 3 attack vectors, nummer 2 is nutteloos zonder nummer 3.

Dus. Zet de rechten op de regkey dicht (of splits de key zodat de gevoelige delen niet world-writable zijn), zet de schrijfrechten op bin\ dicht (die zijn echt nergens voor nodig) en laat de user lekker de service starten als 'ie hem nodig heeft. Poepsimpel. Steam vraagt dan aan de service van "hey, installeer game X of Y", of "update Z" en de service gaat dan in de Steam-library kijken wat daarbij hoort. Dan kan je dus die dingen als admin uitvoeren, zonder UAC-prompt. Niet willekeurig wat jij als aanvaller wilt, maar slechts wat er in de Steam-library staat en is goedgekeurd. Het is niet alsof de non-admin client gewoon een .exe aan de service voert en dat 'ie die gewoon uit gaat voeren.

Ik weet behoorlijk precies wat de attack vectors zijn van mijn programma, en heb daarmee ook bepaalde afwegingen gemaakt. In het kort heb ik een service en een lijst van mogelijke acties op een admin-writable locatie staan die door zowel de service (SYSTEM) als de client (non-admin) gelezen worden. De client kan aan de service vragen een bepaalde actie (ID) uit te voeren. De service gaat dan in de lijst kijken welke actie(s) precies bij dat ID horen en voert ze uit. De servicedefinitie is ook enkel admin-writable, maar normale users mogen start/stop doen. Ik nodig je graag uit om hier gaten in te schieten.

[Ed Vertijsment]

Je zou kunnen stellen:

Als de bug niet serieus genoeg is om binnen een bug bounty te vallen is het kennelijk ook niet zo'n groot probleem als het dan de wijde wereld in gaat.

Ik vind het vreemd om een bug bounty programma te hebben, vervolgens te zeggen dat het niet serieus genoeg is, maar het dan wel verbieden om het te publiceren.

[Vizzie]

Dat is een heel valide mening, maar neem dan gewoon geen deel aan dat programma als de voorwaarden je niet aanstaan.

Wat mij betreft is het geen vrijbrief de voorwaarden vervolgens te schenden.

[Zynth]

Ook binnen een programma zou je de vrijheid moeten hebben om te kunnen zeggen wat je wil.
Zeker als het bedrijf in kwestie zegt dat waar het over gaat, helemaal niet zo erg is.

[Reactie gewijzigd door Zynth op 23 juli 2024 11:51]

[CH4OS]

begrijpelijk dat ze iets van criteria hanteren. Die zijn nog openbaar ook dus deze kerel had vooraf kunnen kijken of hij een beloning kon krijgen.

Punt is meer dat bij het eerste gevonden lek hij dus dacht wel kans te maken op een beloning, maar Valve dat vervolgens afdeed als 'buiten de scope' voor een beloning.

Beetje flauw om die bugs dan op internet te gooien als je vooraf had kunnen weten niet in aanmerking te komen voor een beloning en in ook nog een programma zit waarbij je hebt afgesproken dat niet te doen. Logisch dat je daar dan uitgetrapt wordt.

Dit stukje tekst had dus anders moeten zijn; Beetje flauw dus om tijdens het spelen van het spelletje, de spelregels opeens te veranderen. Want dat is namelijk exact wat er is gebeurd.

[Reactie gewijzigd door CH4OS op 23 juli 2024 11:51]

[Vizzie]

Dat hij de regels niet goed gelezen had is niet het veranderen van de regels tijdens het spel.

[CH4OS]

Ik zeg dan ook niet dat het aan de onderzoeker ligt, die heeft immers de spelregels niet veranderd.

[TabCam]

Hij heeft toch gekeken of hij zijn beloning kon krijgen. Dat was volgens Steam niet zo en heeft hij de bug openbaar gemaakt. Daarop is hij verwijderd uit het programma en kon hij de bonus voor de tweede bug niet meer krijgen. Lijkt ook op de eerste bug dus ergens niet slim van Steam, want hoezo is een local privilege escalation verkrijgen niet gevaarlijk?

Ik snap dat fysieke toegang het probleem veel minder groot maakt, maar ik zou toch een minder grote bonus geven want het klopt niet. Er staat echter niet in het verhaal of Steam dat heeft gedaan en hij meer wilde, dat blijft gissen.

[Brousant]

Beetje flauw om die bugs dan op internet te gooien als je vooraf had kunnen weten niet in aanmerking te komen voor een beloning

Beetje flauw als je gestraft wordt voor het publiceren over een kwetsbaarheid die kennelijk helemaal niet ernstig is (d.w.z. niet ernstig genoeg om een bounty waard te zijn).

[naarden 4ever]

Ik denk dat hij geen betere handeling had kunnen uitvoeren. Als Valve beweert dat deze hack niet gevaarlijk genoeg is om te fixen, dan lijkt mij dat publicatie van dat lek niet tot verregaande gevolgen kan leiden, toch? Logische oorzaak-gevolg redenatie.

Het heeft nu de aandacht gekregen en Valve heeft het toch gefixt, ook al is dat door de druk van de media.

Uiteindelijk gaat het om je verantwoordelijkheid nemen als organisatie voor de veiligheid van je klanten. Ik snap Valve’s redenatie prima, wat is de kans dat een hack als deze wordt gebruikt? Je moet immers fysiek toegang hebben tot de machine, dat is toch een enorm beperkt risico? Ja, totdat dat lek breed in de media uitgelicht wordt. Valve moet op de blaren zitten voor een brak beleid, en ik denk dat deze hacker daar een hele goede zet in heeft gedaan. Ja, een beetje chaotic good kan je het wel noemen, maar als dit de methode is om een bedrijf op zijn verantwoordelijkheden te wijzen, dan zal het zo zijn.

[RobIII]

Ook daarbij gaat het om een lpe, waarbij een aanvaller wel eerst fysieke toegang tot een machine moet hebben.

It rather involved being on the other side of this airtight hatchway

Edit:
Point being: ja, een LPE is niet (en nooit) goed, natuurlijk niet, maar het is een heel ander liedje als je fysiek toegang tot het systeem moet hebben i.t.t. een remote exploitable probleem. Natuurlijk moet Steam Valve het probleem oplossen, maar zolang het niet remote exploitable is blijft het probleem vrij gelokaliseerd en lastig uit te buiten en dus snap ik dat ze er geen dikke bounty op uitkeren.

[Reactie gewijzigd door RobIII op 23 juli 2024 11:51]

[M2M]

Maar als je op usernivo, in steam gebruik kunt maken van een bug in de software van steam, om je eigen code als administrator uit te voeren, dan heb je toch een 0-day exploit te pakken?

[RobIII]

Ja, maar zolang die nog niet remote-exploitable is heb je er vooral jezelf mee. Don't get me wrong, het is niet goed, maar het is pas echt fout als 't remote exploitable is.

[M2M]

Mee eens dat remote exploits echte foute boel zijn, maar de hoeveelheid mensen die zichzelf veilig wanen door in te loggen als user ipv admin en dan alsnog een mooi virusje in %windir% te pakken kunnen krijgen.

[RobIII]

Helemaal eens, maar vanuit Steam Valve's perspectief is dat irrelevant

[Reactie gewijzigd door RobIII op 23 juli 2024 11:51]

[M2M]

Dan snap ik wel waarom de beveiligingsonderzoeker het daar niet mee eens zou kunnen zijn.

[looc]

Niet de case hier, in my opinion
Als een iemand toegang heeft tot een non-admin user, kan hij die met deze exploit nog steeds admin rechten krijgen.
Voorbeelden waar dat kan gebeuren:

• een 'vriend' die je pc even gebruikt
• Een kiosk pc met steam geinstalleerd

[Reactie gewijzigd door looc op 23 juli 2024 11:51]

[RobIII]

Dat klopt en het is, zoals ik hier al zei, zéker niet goed. Maar zolang het niet remote exploitable is heb je er vooral jezelf (of de eigenaar van het systeem/netwerk) mee. De impact is (vrij) lokaal. Je hebt kunt hier niet 'wereldwijd' misbruik van maken.

[Reactie gewijzigd door RobIII op 23 juli 2024 11:51]

[looc]

Totdat een ander programma wel remote exploitable is.
Als een indringer dan user rechten heeft, kan met deze steam exploit nog steeds hogere rechten verkregen worden.

Want wat als ik een exploitable webserver onder mijn account draait, waarmee een hacker nu onder mijn user alles kan doen wat ik kan? Inclusief gebruik maken van deze lpe?
Los van het feit of het slim is om een webserver onder mijn username te draaien. Maar als Valve deze lpe fixed, dan zou in mijn voorbeeld in ieder geval niet heel mn systeem overgenomen worden.

[RobIII]

Totdat een ander programma wel remote exploitable is.

Ja, maar is dat Valve's verantwoordelijkheid? Omdat <willekeurig programma> remote exploitable is moeten zij maar een bounty uitkeren

Nogmaals: natuurlijk moeten ze deze LPE fixen en is 't niet goed, maar vanuit Valve's perspectief is 't niet meer dan een lokale bug.

[Reactie gewijzigd door RobIII op 23 juli 2024 11:51]

[R4gnax]

Ja, maar is dat Valve's verantwoordelijkheid?

Ja. Defense in depth. Ook MS neemt LPEs in Windows en ingesloten programmatuur serieus en verhelpt deze.

[Reactie gewijzigd door R4gnax op 23 juli 2024 11:51]

[RobIII]

Nogmaals: natuurlijk moeten ze deze LPE fixen en is 't niet goed

[halofreak1990]

Ja, maar is dat Valve's verantwoordelijkheid?

Eh, ja? Zij zijn dan toch de enabler van die andere exploit om sysadmin rechten te krijgen? In de echte wereld ben je dan medeplichtig, en dat is net zo goed strafbaar.

vanuit Valve's perspectief is 't niet meer dan een lokale bug.

En kunnen ze blijbaar net zo min verder kijken dan hun neus lang is, als tot drie tellen.

[MadMarky]

bedankt voor het linkje. Geeft imo een goede uitleg waarom sommige local privilige escalation bugs eigenlijk helemaal niet zo kritiek zijn, zoals Valve in dit geval ook aangeeft.

[kuurtjes]

Vanaf dat je iets local privilege escalation kan noemen is het al kritiek, het zit letterlijk in de naam.

[roemerbakker]

Dank voor het linkje. Ik ben het er mee eens dat niet elke LPE bug meteen een groot probleem is, echter staat er ook in het gelinkte artikel dat het wel degelijk een probleem is als er privilege escalation kan ontstaan, wat in dit geval ook gebeurt. Een ander programma wat zonder deze privileges draait, kan deze via de bug verkrijgen. Naar mijn mening wel degelijk een security probleem wat Valve zou moeten oplossen.

[RobIII]

Een ander programma wat zonder deze privileges draait, kan deze via de bug verkrijgen.

Klopt, maar dan is 't nog steeds niet remote exploitable tenzij dat andere programma remote exploitable is. En dat kan Valve vrij lastig oplossen als 't niet hun software is he?

Naar mijn mening wel degelijk een security probleem wat Valve zou moeten oplossen.

Dat is ook nergens (door mij) gezegd; natuurlijk moeten ze 't oplossen; mijn punt is alleen dat de impact vooralsnog vrij laag is als je fysieke toegang moet hebben tot het systeem om de LPE uit te voeren. Is het een bug? Ja. Is 't een security probleem? Ja. Is 't supergevaarlijk en moeten er mensen voor uit bed gebeld worden of van vakantie terugkeren om zsm een fix uit te rollen? Nee. Is de impact enorm? Nee. Moet de bounty uitgekeerd worden? Nee.

[Reactie gewijzigd door RobIII op 23 juli 2024 11:51]

[kuurtjes]

In userland kan je ook veel doen hoor.

[Greymane]

Kansloos natuurlijk. Pas als je veel klachten krijgt iets patchen. Veiligheid zou prio 1voor een bedrijf moeten zijn. Krijg je het op een bordje aangeleverd, doe je er niks mee.

[Yoshi]

De fixes daar kunnen ze met bezig zijn, dat is helemaal niet af te leiden uit het artikel. Ik ga er vooral vanuit dat ze idd wel hun tijd nemen voor bepaalde lekken te dichten en verder kan ik ook uitmaken dat de berichtgeving vanuit Valve zoals gewoonlijk te wensen overlaat.

de fix is er nl. al in de beta ;-)
https://steamcommunity.co...etail/1599262071399843693
Zou mogelijks wel in het artikel mogen staan :-)

Dus ze doen er mogelijks wel iets mee, maar god mag weten wat :.
Veiligheid hoort idd prio 1 te zijn dat wel. Maar ik denk dat ze er wel degelijk iets mee doen.

Verder is ook de policy op H1, idd naar aanleiding van de discussie, aangepast. Dus al bij al goed nieuws. Maar communicatie is een ramp vanuit Valve

[Reactie gewijzigd door Yoshi op 23 juli 2024 11:51]

[Cilph]

Waarom zou je iemand uit het programma trappen? Dan garandeer je gewoon dat iets uitlekt.

[m8ZBm1Si]

Als iemand iets gaat uitlekken omdat hij geen beloning krijgt, is dat een vertrouwensbreuk en houdt diegene zich niet aan de regels van het programma.

[Cilph]

Had hem dan een beloning gegeven zou ik zeggen, en niet tegenstribbelen "want het was niet belangrijk genoeg".

[m8ZBm1Si]

Misschien eens het artikel lezen. Hij kreeg geen beloning omdat het lek fysieke toegang nodig had tot de computer.

Ook daarbij gaat het om een lpe, waarbij een aanvaller wel eerst fysieke toegang tot een machine moet hebben. Daar zit het probleem volgens Valve. In de scope van het bugbountyprogramma op HackerOne zegt Valve dat lpe's wel degelijk onder de beloningscriteria vallen, maar dat geldt alleen bij aanvallen met malware of gecompromitteerde software. In dit geval, waarbij een aanvaller fysiek op de machine moet zitten, valt het lek buiten de reikwijdte, zegt Valve

Oftewel, als Valve hiervoor een beloning gaat geven, breken ze hun eigen regels. De persoon die het uitlekt hier, had van te voren kunnen lezen dat hij geen beloning zou krijgen.

[Cilph]

Dan zie ik het probleem met het uitlekken niet echt, want het was dus immers geen lek.

[m8ZBm1Si]

Ik vind het jammer dat je niet het schadelijke van dit gedrag niet inziet.

[Cilph]

Dat zie ik inderdaad niet. Valve ziet er kennelijk geen risico in, ze bestempelen het immers niet als een lek, en ze geven geen beloning. Waarom zou je het dan niet openbaar mogen maken? Wat is het gevaar?

[m8ZBm1Si]

Ik zal het iets makkelijker voor je maken. Misschien zijn vetgedrukte letters makkelijker te lezen?

valt het lek buiten de reikwijdte, zegt Valve

Het is wel een lek, en zo bestempelen ze het ook. Het valt alleen buiten de eisen voor een beloning. Verder gaat een hacker akkoord met voorwaarden als hij dit meld via HackerOne, en vervolgens heeft hij deze geschonden. Logisch toch dat hij vervolgens uit het programma wordt gegooid?

[halofreak1990]

Echter heeft HackerOne hier natuurlijk de verkeerde kant gekozen. Het is toch te gek voor woorden dat als een bedrijf een exploit niet belangrijk genoeg vindt om te fixen, dat je de exploit vervolgens niet openbaar mag maken? Dan was het blijkbaar toch niet zo onbelangrijk, en had de onderzoeker gewoon zijn geld moeten krijgen.

Zou voor mij een reden zijn om eventuele exploits die ik zou ontdekken buiten HackerOne om te melden.

[m8ZBm1Si]

Ik snap dat het artikel lezen vrij lastig is, dus dan pakken we de vetgedrukte letters er maar weer bij.

Valve zegt nergens dat ze het lek niet belangrijk genoeg vinden om te fixen. Ze zeggen alleen dat er geen beloning op staat.

Iets dat ze duidelijk van te voren hebben gemeld. Als de hacker gelezen had, had hij dit geweten.

[Haruhi]

"Hey man we hebben een bug programma"
"Jaaaaaaaaa, maar dan heeft iemand toegang op je pc nodig, das niet echt een bug."

Rare insteek, mn baas beloont iedereen die naar voren komt met een bug.

[DarkKnight]

Of ik lees iets anders dan jullie allemaal, maar wat ik lees is dat HackerOne hem eruit getrapt heeft, niet Valve.
Valve heeft alleen teruggegeven dat de bug in kwestie niet zwaar genoeg was voor een beloning (terecht of niet, is verder niet aan de orde). Daarop heeft de persoon in kwestie de bug uitgelekt, wat tegen de voorwaarden van HackerOne was (niet Valve).
Dus het zijn 2 afzonderlijke acties door 2 verschillende entiteiten, die wel gerelateerd maar geen directe correlatie hebben.

[WimmieV]

"Een beveiligingsonderzoeker heeft een zeroday in Steam openbaar gemaakt. Dat deed hij uit onvrede over het beleid van Valve rondom responsible disclosure. De hacker was eerder uit het HackerOne-programma verwijderd."

Zijn een hacker en een beveiligingsonderzoeker voortaan precies hetzelfde 🤔

Dat maak ik op uit de vetgedrukte kop van het artikel

[Reactie gewijzigd door WimmieV op 23 juli 2024 11:51]

[Pinkys Brain]

Uit wraak maakt hij er een zero day van met bijna geen tijd na bekendmaking, dus ja hacker. Meeste "beveiligingsonderzoekers" vallen hem bij, dus ook hackers.

Als je vind dat exploits meteen openbaar moeten worden gemaakt en dat responsible disclosure onzin is kan ik die gedachtengang nog wel volgen. Maar als je dan vervolgens geld aanneemt om het niet te doen niet meer ... dan ben je gewoon afpersing aan het rationaliseren.

[Reactie gewijzigd door Pinkys Brain op 23 juli 2024 11:51]

[Raphaelo]

Uit wraak maakt hij er een zero day van met bijna geen tijd na bekendmaking, dus ja hacker. Meeste "beveiligingsonderzoekers" vallen hem bij, dus ook hackers.

Als je vind dat exploits meteen openbaar moeten worden gemaakt en dat responsible disclosure onzin is kan ik die gedachtengang nog wel volgen. Maar als je dan vervolgens geld aanneemt om het niet te doen niet meer ... dan ben je gewoon afpersing aan het rationaliseren.

Welke 'exploits'? Volgens Valve is er ja niets aan het handje...

[Pinkys Brain]

Volgens Valve zijn exploits van deze aard geen bounty waardig ... is nog geen reden om ze meteen op straat te gooien.

"Ik krijg geen geld, dus krijgt iedereen maar de tering."

[Brousant]

Vergelijk het eens met bijvoorbeeld https://www.omroepbrabant...ig-gewond-naar-ziekenhuis
Daaruit is toch ook niet op te maken dat een man en een voetganger in het algemeen precies hetzelfde zijn.

[WimmieV]

Bedankt,
Ik snap wat je bedoelt, maar ik vind de vergelijking wel mank gaan.

Bij het artikel gaat het om twee verschillende 'beroepen' / 'wat je doet'

In jouw voorbeeld gaat het om iets wat je doet en om wat je bent.


Maar goed, je moet tegenwoordig eerst het hele artikel lezen, dan pas vragen gaan stellen.
Koppen en de vetgedrukte "sub-koppen" lijken alleen bedoeld voor het aandacht vragen.
Niet om de verkorte versie van het artikel weer te geven 😏

(In bijna alle media lijkt het wel)

[Reactie gewijzigd door WimmieV op 23 juli 2024 11:51]

[Byron010]

Attacks that require physical access to the user’s device.

Te vinden: hier

Staat toch heel duidelijk dat het dan buiten de scope valt. Via de Diff changes van de scope is ook te zien dat dit er langer in staat.

Gewoon zijn eigen fout dus..

[Reactie gewijzigd door Byron010 op 23 juli 2024 11:51]

[Parrotmaster]

Dus het eerste lek was niet groot genoeg voor een beloning in het bugbountyprogramma maar wel groot genoeg om iemand uit dat programma te trappen? Klinkt als een grijs gebied.

[Vizzie]

Hoezo grijs?

Iemand mag deelnemen aan een programma met voorwaarden. Hij schendt die voorwaarden (ook al had hij wel een bug gevonden, niet een binnen de scope van het programma). Hij publiceert de bug tegen de voorwaarden van het programma in. Hij wordt uit het programma gezet voor het overtreden van de voorwaarden.

Wat is hier grijs?

Ook al was het een minieme bug die nooit misbruikt kon worden: afspraak is afspraak. Als je je niet aan je afspraken houdt wil valve/hackerone terecht geen zaken met je doen.

Zwart wit

[Gelb]

Je hebt volkomen gelijk.

Het is hier absoluut zwart wit.

De beste man publiceerde een bug die buiten de scope van het door Valve opgezette bounty programma viel.

Ergo de bug viel buiten het programma dus tevens ook buiten de daarvoor afgesloten voorwaarden.
Geheel zwart wit geen grijs gebied.

Of toch ligt het misschien toch wat genuanceerder?

[Vizzie]

Ergo de bug viel buiten het programma dus tevens ook buiten de daarvoor afgesloten voorwaarden.
Geheel zwart wit geen grijs gebied.

Nee de voorwaarden stelden blijkbaar dat je de bugs niet zou publiceren of ze nu binnen de scope vielen of niet.

Waarom iedereen iemand die zich gewoon niet aan zn afspraken houdt zo in bescherming neemt is mij echt een raadsel.

[Raphaelo]

[...]


Nee de voorwaarden stelden blijkbaar dat je de bugs niet zou publiceren of ze nu binnen de scope vielen of niet.

Waarom iedereen iemand die zich gewoon niet aan zn afspraken houdt zo in bescherming neemt is mij echt een raadsel.

Misschien dat sommige mensen die afspraken nogal wazig of dom vinden. Het feit dat iemand technisch 'gelijk' of 'ongelijk' heeft is minder relevant.

[Jerie]

De reporter van de bug had van origine goede bedoelingen. De bug had nooit buiten het programma moeten vallen, dan hadden we deze stupide discussie ook niet.

[halofreak1990]

Wordt tijd dat Valve eens échte concurrentie krijgt. Misschien dat dan de kwaliteit van hun software eindelijk eens onder de loep wordt genomen, daar.

[whetstone]

Als ik een ethische hacker was, en ik werd op deze manier behandeld, zou ik veel ergere dingen gedaan hebben dan wat deze hacker gedaan heeft. Ik zou alle gevonden beveiligingslekken duur verkopen aan criminele organisaties, zodat ik toch mijn geld krijg en Steam bovendien enorm wordt geschaad door de aanvallen van die criminele organisaties.

ftfy

[D11]

zodat ik toch mijn geld krijg en Steam bovendien enorm wordt geschaad door de aanvallen van die criminele organisaties.

Het zijn helaas de gebruikers van Steam die hiermee enorm geschaad worden. Of Valve hiermee geschaad wordt is dan nog maar afwachten.

[mutley69]

Ik heb geen compassie met steam nog met z'n gebruikers. Als steam niet wil vergoeden - moeten ze tegen de weerbots kunnen. Life sucks.

[markwiering]

Ik denk dat als een groot aantal Steam gebruikers geschaad worden door hackers, het aantal gebruikers van Steam snel afneemt, en dat zal Valve wel degelijk schaden.

Dit is natuurlijk wel jammer voor de gebruikers van Steam. Ik gebruik Steam zelf namelijk ook. Ik wilde Grand Theft Auto V kopen, maar uit mijn vreselijke ervaring met de beveiligingsmechanismen van Grand Theft Auto IV (die ervoor zorgen dat ik dit spel niet kan spelen, ook al heb ik de legitieme versie!), wist ik dat dit met GTA V erger zou zijn. Daarom kocht ik GTA V via Steam. Zodoende kon ik GTA V zonder teveel moeite en problemen aan de praat krijgen.