'Responsible disclosure' bij potentiële beveiligingsprobleme

[ktf]

In het kort
De richtlijnen/etiquette voor het melden van beveiligingslekken is over het algemeen vrij duidelijk: meldt je bij de softwareontwikkelaar, geef duidelijk aan wat er mis is, communiceer je verwachtingen, wacht enige tijd en meldt het publiek als de ontwikkelaar geen actie onderneemt.

Het probleem wat ik nu heb: wat doe je met bestanden waarvan je verwacht dat ze beveiligingslekken bloot zullen leggen, sterker nog, waarvan het doel is om beveiligingsproblemen aan het licht te brengen? Er is niet één ontwikkelaar om aan te spreken (het zijn er tientallen/honderdenen), het is niet redelijkerwijs mogelijk alle software/hardware te testen, maar voor het algemeen belang is het praktisch dat zulke bestanden er zijn?

Ik ben op zoek naar meningen en hun argumenten, anekdotes, tips etc. voor dit geval.

In detail
Sinds een tijdje werk ik in mijn vrije tijd aan FLAC, een audio codec. Naast code ben ik ook bezig met standaardisatie. Hiervoor heb ik ook een set bestanden samengesteld die alle 'features' van het FLAC formaat afgaan, zodat andere ontwikkelaars hun FLAC implementatie kunnen testen. Momenteel bestaat deze set enkel uit valide bestanden, allen conform de specificatie.

Nu heb ik deze bestanden op veel verschillende hardware en software geprobeerd, en daarbij tientallen crashes en freezes langs zien komen. Ik heb nergens gekeken of er mogelijkheden zijn deze crashes te misbruiken, maar het lijkt me redelijk om te verwachten dat deze er zijn.

Bij publicatie van deze bestanden heb ik niet echt stilgestaan bij het veiligheidsaspect: deze bestanden zijn valide, en ik heb niks speciaals gedaan om ze te maken, de meeste komen zo uit de beschikbare software rollen. Nu overweeg ik echter ook gemodificeerde bestanden aan de set toe te voegen, met duidelijk gedefinieerde fouten. Als de valide bestanden al apparatuur laten crashen, dan zullen deze bestanden dat ook zeker gaan doen.

Is het publiceren van zulke bestanden verantwoord? Is het verdedigbaar? Is er iets wat ik kan doen om publicatie (meer) verantwoord te maken?

[oak3]

Het is de verantwoordelijkheid van de persoon die de bestanden gebruikt om zich er van te verzekeren dat de bestanden geen kwaad kunnen. Dat is toch intussen wel algemeen geaccepteerd als je iets download van het internet.

Wel netjes om een toelichting te geven bij de bestanden en erbij te vermelden dat er risico's zijn als je dat nu al weet.

Als voorbeeld, er zijn ook partijen die malware publiceren voor onderzoek. Iedereen snapt wel dat je dat niet zomaar moet uitvoeren op je systeem.

[ktf]

Eigenlijk bedoelde ik meer dat deze bestanden misschien als 'sjabloon' kunnen worden gebruikt.

Bijvoorbeeld: ik plaats bestanden welke (buiten mijn weten) een kwetsbaarheid blootlegt in product X. Een kwaadwillende komt hierachter, en gebruikt mijn bestand, eventueel na aanpassing, om deze kwetsbaarheid in product X uit te buiten. Kan ik op wat voor manier dan ook rekening houden met dit scenario?

De bestanden zijn uiteraard bedoeld om dergelijke lekken op te sporen, maar iedereen kan dat proberen. Waarschijnlijk is 'het publiek' daar sneller mee dan de ontwikkelaar zelf.

[sh4d0wman]

De ontwikkelaar heeft de plicht veilige software te maken. Als de parser al om zeep gaat met valide bestanden zal het zeker crashen met meer creatieve input aka fuzzing.

Als jij fuzz cases als zodanig online zet dan zal daar weinig mis mee zijn. Een weaponized versie online zetten is not-done. Maar als het zo simpel te vinden is kan een blackhat dat ook wel zonder jouw templates.

Je zult ook wel gaan merken dat niet elke fabrikant op responsible disclosure zit te wachten. Een deel zal nooit reageren, een deel zal patchen zonder je op de hoogte te brengen en als je mazzel hebt zijn er een paar welke je credit geven voor de bug.

[DaFeliX]

Je hebt problemen gevonden in meerdere producten, en vraagt of je deze problemen moet melden. Maar in je TS stel je ook dat je ontwikkelaars de kans moet geven deze problemen op te lossen, dus volgens mij moet je je eigen advies volgen en dit bij de ontwikkelaars melden.

Zoals je zelf al zegt is het nog niet duidelijk of 't beveiligingsproblemen oplevert, dus iemand met kwade bedoelingen zal dit zelf nog moeten uitzoeken. Zolang je deze bestanden niet publiceert met instructies hoe je ze kunt gebruiken om in applicatie X een exploit uit te voeren, zie ik niet echt een probleem; de kans dat anderen dezelfde problemen hebben gevonden is vrij groot natuurlijk.

Dus: Een kant-en-klare exploit voor een nog niet gedicht lek voor een applicatie: Nee. Anders: Ja

ktf schreef op dinsdag 8 november 2022 @ 14:51:
In het kort
De richtlijnen/etiquette voor het melden van beveiligingslekken is over het algemeen vrij duidelijk: meldt je bij de softwareontwikkelaar, geef duidelijk aan wat er mis is, communiceer je verwachtingen, wacht enige tijd en meldt het publiek als de ontwikkelaar geen actie onderneemt.

[...]

Het mooiste zou zijn dat je met de ontwikkelaar overlegt wat die "enige tijd" precies is. Of je publiceert het probleem niet publiekelijk, dat kan ook altijd nog

[ktf]

sh4d0wman schreef op woensdag 9 november 2022 @ 07:23:
Je zult ook wel gaan merken dat niet elke fabrikant op responsible disclosure zit te wachten. Een deel zal nooit reageren, een deel zal patchen zonder je op de hoogte te brengen en als je mazzel hebt zijn er een paar welke je credit geven voor de bug.

Het blijkt inderdaad erg moeilijk om fabrikanten van hardware uberhaubt te bereiken. Een mailtje naar een bug-bounty programma van Samsung (waarin ik expliciet aangaf geen interesse in de bounty maar gewoon bugs wilde melden) werd afgedaan met de mededeling dat het apparaat er niet onder viel, een mailtje naar de helpdesk van Sony is 3 maanden later nog niet opgevolgd. Van anderen is het uberhaubt niet mogelijk een e-mailadres te vinden. Tja...

sh4d0wman schreef op woensdag 9 november 2022 @ 07:23:
Als jij fuzz cases als zodanig online zet dan zal daar weinig mis mee zijn. Een weaponized versie online zetten is not-done. Maar als het zo simpel te vinden is kan een blackhat dat ook wel zonder jouw templates.

DaFeliX schreef op woensdag 9 november 2022 @ 07:45:
Zoals je zelf al zegt is het nog niet duidelijk of 't beveiligingsproblemen oplevert, dus iemand met kwade bedoelingen zal dit zelf nog moeten uitzoeken. Zolang je deze bestanden niet publiceert met instructies hoe je ze kunt gebruiken om in applicatie X een exploit uit te voeren, zie ik niet echt een probleem; de kans dat anderen dezelfde problemen hebben gevonden is vrij groot natuurlijk.

Dus: Een kant-en-klare exploit voor een nog niet gedicht lek voor een applicatie: Nee. Anders: Ja

Bedankt!

[sh4d0wman]

DaFeliX schreef op woensdag 9 november 2022 @ 07:45:
Het mooiste zou zijn dat je met de ontwikkelaar overlegt wat die "enige tijd" precies is. Of je publiceert het probleem niet publiekelijk, dat kan ook altijd nog

Door Google (Project0) is die termijn meestal 90 dagen. Dus dat kun je veilig aanhouden.

Het valt inderdaad nog wel tegen hoe grote namen/merken (niet) reageren. Meerdere bugs melden stopt soms ook opeens de communicatie Dus ik heb ook wel eens wat online gezet. Niet anoniem en dan loop je een risico op advocaten of kwade mails.

Bug bounty programmas geven ook wisselend resultaat. Heb wel eens een bekende leverancier gehad die toevallig net dezelfde bugs (x3) zelf had ontdekt en niet uit wilde betalen. Zoveel toeval geloof ik niet in dus toen was ik het even beu. Na 6 maanden bestonden de bugs nog steeds.... Veilige software heeft nog een lange weg te gaan.

edit: @DaFeliX het waren 3 verschillende klasse bugs binnen dezelfde applicatie. Dus vandaar mijn argwaan Het was een betaalde bug bounty dus dan werk ik liever niet voor niks.

[Voor 8% gewijzigd door sh4d0wman op 14-11-2022 11:41]

[DaFeliX]

sh4d0wman schreef op maandag 14 november 2022 @ 10:22:
[...]

Bug bounty programmas geven ook wisselend resultaat. Heb wel eens een bekende leverancier gehad die toevallig net dezelfde bugs (x3) zelf had ontdekt en niet uit wilde betalen. Zoveel toeval geloof ik niet in dus toen was ik het even beu. Na 6 maanden bestonden de bugs nog steeds.... Veilige software heeft nog een lange weg te gaan.

Dat zelf ontdekken overkomt ons ook wel eens hoor, zo toevallig is dat niet: We maken een bug, deployen dit naar productie en een andere devver merkt een probleem wanneer hij in gerelateerde code werkt.
Of een probleem wordt door twee onderzoekers binnen 1 dag gemeld; omdat het een nieuw probleem is, of de software die gebruikt word voor 't scannen aangepast is.

Als een bedrijf dan nog 'ns besluit om 6 maanden te wachten met 't fixen van een probleem, kan het gebeuren dat er meerdere mensen 'tzelfde probleem hebben gemeld. Hoe frustrerend dat ook kan zijn, accepteren dat 't is lijkt mij gezonder dan van kwade opzet uitgaan.

Ik haal mijn genoegen uit 't melden van problemen, zodat de ander dit kan oplossen. Ik verwacht geen beloning, en verwacht ook niet dat men mijn probleem oplost. Dan blijft het voor mij een leuk spel