Het Wassenaar Arrangement versus de security-onderzoeker

| AE 7806 | Hacken, Software | 22 reacties

bug-fout.pngEen Britse student mag zijn scriptie niet publiceren omdat hij daarin exploits uitlegt, wat verboden is door het Wassenaar Arrangement. Dat meldde Ars Technica afgelopen vrijdag. De bachelorscriptie bevat nu enkele zwartgemaakte pagina’s, en details daaruit worden alleen aan bona fide securityonderzoekers beschikbaar gesteld. Wacht even, is het nu ook al verboden om wetenschappelijke publicaties over securitygaten te doen?

Het Akkoord van Wassenaar (niet te verwarren met het Akkoord van Wassenaar) is een verdrag dat exportrestricties stelt op wapens en dual-use technologie. In 2014 werd de scope van dit Akkoord uitgebreid: ook intrusion software is nu een ‘wapen’ en daarmee onderworpen aan exportrestricties.

Meer specifiek gaat het om

Software ‘specially designed’ or modified to avoid detection by ‘monitoring tools,’ or to defeat ‘protective countermeasures,’ of a computer or network-capable device, and performing any of the following: (a) The extraction of data or information, from a computer or network-capable device, or the modification of system or user data; or (b) The modification of the standard execution path of a program or process in order to allow the execution of externally provided instructions.

Het is item (b) waardoor ook zero days en andere exploitsoftware hieronder zou kunnen vallen: vrijwel alle exploits zijn uiteindelijk gericht op het uitvoeren van andere instructies, het hele punt immers is de controle overnemen van het systeem dat je aanvalt.

Op zich valt ook een exploit in een paper onder deze definitie. Het gaat immers niet om het medium waarin de software is verschenen of de bedoelingen van de auteur. Echter, elders in het Akkoord staat:

Controls do not apply to “technology” “in the public domain”, to “basic scientific research” or to the minimum necessary information for patent applications.

Hierbij betekent “public domain”

“technology” or “software” which has been made available without restrictions upon its further dissemination. Copyright restrictions do not remove “technology” or “software” from being “in the public domain”.

Oftewel, wie publiceert zonder restrictie, valt buiten het verdrag. Vreemd is het wel, want als je dus je software voor een beperkt publiek aanbiedt dan krijg je exportrestricties om je oren, maar zet je het met broncode en al op internet onder een opensourcelicentie dan heb je nergens wat mee te maken.

Het lijkt er bij deze student op dat er nog wat anders meespeelt: hij noemt naast het Akkoord ook het ethisch beleid van zijn universiteit als factor die in de weg zit. Ik kan dat beleid zo niet vinden, maar het is ergens voorstelbaar dat een stel alfa’s uit het bestuur meende dat exploits publiceren onethisch is ongeacht de wetenschappelijke waarde daarvan. Daar doe je dan verder juridisch niets aan.

Arnoud

Deel dit artikel

  1. het is ergens voorstelbaar dat een stel alfa’s uit het bestuur meende dat exploits publiceren onethisch is ongeacht de wetenschappelijke waarde daarvan. Daar doe je dan verder juridisch niets aan.
    Tot op zekere hoogte kan ik dat ook nog wel waarderen. Het is niet zo dat als er geen wet tegen is, dat dus alles maar geoorloofd is.

    • Dat is geen excuus voor domme, schadelijke beperkingen.

      Het lijkt me een goed idee dat een informatica-faculteit gewoon de onder security researchers geldende ethiek van responsible disclosure over neemt in een officieel document. Mochten er op hoog bestuurlijk niveau te veel alfa’s zitten die zoiets blokkeren, dan moet je dit maar doen op een lager niveau; desnoods in een nieuw op te richten samenwerkingsverband van professoren en andere sympathisanten. Vervolgens moet de druk op hogere bestuurslagen worden opgevoerd, totdat je geen last meer van ze hebt.

      Wat je in ieder geval wilt bereiken is dat zo’n student ongestoord kan publiceren en tegelijkertijd ook zijn diploma kan halen.

      • Het vinden van lekken is een beetje als het meedoen aan een loterij waarbij je zelf de nummers invult. De eerste die de correcte nummers raad en ze verzilvert wint de prijs. Hoe meer prijzen er al vergeven zijn, hoe lager de kans dat je wint.

        Echter zie je vaak dat een stel domme alfa’s het voor de good guys moeilijk maakt om lekken te bespreken en op te lossen, ze denken blijkbaar dat dat allemaal vanzelf gaat achter gesloten deuren, terwijl juist het publiekelijk informeren van de security gemeenschap als programmeurs daarbuiten zo veel mogelijk voorlichten cruciaal is. Ik vind het nog altijd schadelijk dat ik tijdens mijn SQL lessen zo slecht geïnformeerd werd wat SQL-injecties zijn en hoe ze werken, uit angst dat de school ‘studenten opleid tot hackers’, terwijl ze juist de programmeurs opleiden die in de toekomst SQL-injecties moeten voorkomen, en de enige manier om dat te doen is door goed te weten waar de problemen zitten en hoe ze werken.

        De bad guys daarentegen hebben de volledige vrijheid exploits te delen (met de hoogste bieder) en gniffelen in hun vuistje als maanden tot jaren niet gepatched worden. Ze spelen gewoon zo vaak mogelijk mee in de loterij en hoeven maar één keer te winnen om flinke schade aan te richten.

        Natuurlijk moet je voorkomen dat je zero days lekt, daarvoor heb je juist responsible disclosure met good practices die de juiste balans zoeken tussen druk zetten op leveranciers om problemen op te lossen, en publiceren van de problemen om andere op tijd te waarschuwen.

  2. Ik zie ook geen toegevoegde waarde van het publiceren van een actuele zero day in een wetenschappelijk onderzoeksdocument. Het is een onderzoek naar de effectiviteit van een security mitigation tool. Je hebt toch geen zero day exploit in je paper nodig om te zeggen dat zo’n tool bepaalde zero days wel of niet zal tegenhouden. Het lijkt me voldoende om de betreffende zero day te benoemen. Maar mogelijk is deze student meer bezig met een baan voor de toekomst dan research en dan is het wel interessant om nieuwe zero days te ontdekken en publiceren voor je CV.

    • Een proof by demonstration is een krachtig middel om te laten zien dat iets niet alleen maar theorie is, maar ook in de praktijk van belang is.

      Moderne (natuur)wetenschap is meer dan alleen platonisch redeneren en theoretiseren: ideeën moeten ook “empirisch” aan de werkelijkheid worden getoetst. In dat opzicht is het maken van een werkelijke exploit wel degelijk een wetenschappelijke bijdrage.

      • Een proof by demonstration is een krachtig middel om te laten zien dat iets niet alleen maar theorie is, maar ook in de praktijk van belang is.

        Ik vind het prima als je daadwerkelijk een exploit toetst in het kader van het onderzoek maar vraag me wel af of het daarbij noodzakelijk is om de exploit zelf te publiceren in je rapport. Je kunt de exploit ook omschrijven/samenvatten op een wijze die wel duidelijk maakt wat je onderzoekt maar niet de exploit zelf weggeeft. Tenzij je het onderzoek wilt publieren om te laten zien dan je in staat bent om zero day exploits te maken. Iets wat je vermoedelijk makkelijk een baan kan opleveen

  3. Is dit dan een verbod op responsible disclosure en moet je nu altijd full disclosure gebruiken? Als je een kwetsbaarheid vind in een stuk software van een amerikaanse producent en die exclusief aan de producent wil onthullen publiceer je naar een beperkt publiek en zou je dus onder die export restricties vallen terwijl als je het gewoon online kwakt je er niet onder valt. Dat lijkt me niet de bedoeling van dit verdrag.

  4. als je dus je software voor een beperkt publiek aanbiedt dan krijg je exportrestricties om je oren

    Voor zover ik weet is de best practice in de security wereld als volgt:

    1. Stuur de gegevens over het beveiligingslek alleen naar die partijen die verantwoordelijk zijn voor het dichten van het lek (in dit geval Microsoft). Geef ze ruim de tijd om het lek te dichten, maar geef ze wel een deadline.
    2. Mochten die partijen goed kunnen beargumenteren waarom ze meer tijd nodig hebben, geef ze dan eventueel meer tijd.
    3. Zodra de deadline is verstreken, publiceer het beveiligingslek, ongeacht of er een patch is. Dit zet de verantwoordelijke partij onder druk om voor de deadline een patch te maken, en het informeert gebruikers, bij afwezigheid van een patch, om het product (tijdelijk) niet te gebruiken / te vertrouwen.

    Als ik het goed begrijp, dan is het Akkoord van Wassenaar vooral een probleem voor stap 1. Aangezien het export-restricties zijn, neem ik aan dat het vooral een probleem is dat Microsoft zich in de VS bevindt en de ontdekker buiten de VS.

    • Deze best practice wordt blijkbaar door de wetgever op verschillende manieren ondermijnd: schoolvoorbeeld van struisvogelpolitiek. Binnen de wet is het dus blijkbaar het verstandigst om gewoon helemaal geen onderzoek naar lekken te doen, om je zo van elke vorm van juridische laakbaarheid verschoont te houden. Wat dat betekent voor de veiligheid van onze systemen wil ik liever niet aan denken.

      Je kunt dergelijk onderzoek gelukkig ook doen op locaties waar dergelijke beperkingen niet gelden. Het idee van lekker hacken op een klein tropisch eiland ergens ver weg dringt zich dan op. In plaats van stap 1 te volgen kun je als miskent talent natuurlijk ook een veiling opzetten, en de gevonden exploits aan de hoogst biedende verkopen….

  5. Timing, afgelopen vrijdag hebben wij twee studenten-assistenten gekregen (okt 2015-aug 2016) die gedurende 10 maanden Wassenaar agreement vanuit technsisch en juridisch perspectief gaan bestuderen: http://www.rechten.vu.nl/nl/nieuws-agenda/nieuwsarchief/2015/cybersecurity-onderzoek.asp Er schijnen veel van dit soort gevallen te zijn, o.a. 4 ton aan procedure kosten ivm hack VW die ontdekt was door Bart Jacobs c.s. (RU).

  6. Dus een master thesis is wel een uitzondering (basic scientific research) en een bachelor scriptie niet (applied research)?

    Controls do not apply to “technology” “in the public domain”, to “basic scientific research” or to the minimum necessary information for patent applications.

Laat een reactie achter

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren en <em> en <strong> voor italics en vet.

(verplicht)

Volg de reacties per RSS