Mag je de Shellshock-kwetsbaarheid gebruiken om die kwetsbaarheid te repareren?

shell-script-hacker-go-awayEen recent ontdekte softwarekwetsbaarheid laat aanvallers code injecteren in de Bash-shell, die door OS X en vrijwel alle Linux-distributies wordt gebruikt. Dat meldde Tweakers woensdag. Door de kwetsbaarheid kun je op afstand code laten uitvoeren op systemen die met die shell werken. Een slimme lezer mailde me vervolgens: wat nu als die code geen kwade bedoelingen heeft maar de getroffen Bash-shell upgradet naar een veilige versie?

Kwetsbaarheden als deze zijn (helaas) een regelmatig terugkerend fenomeen. Gelukkig blijken ze vaak op te lossen, en dat is ook wat er hier is gebeurd. Oplettende systeembeheerders hebben ondertussen dus het probleem al opgelost, maar je zult ze de kost moeten geven die over drie maanden nog deze kwetsbaarheid op hun systeem hebben zitten.

Het gaat hier om het soort kwetsbaarheid waarbij je op afstand met speciaal gekozen code arbitraire instructies kunt uitvoeren. Het vereist de aanwezigheid van de zogeheten Bash-shell, maar die is op veel Linux systemen standaard aanwezig. Genoeg ruimte voor exploitatie van de fout dus. Je kunt allerhande narigheid uithalen op iemands systeem, maar -dank voor de suggestie- ook op afstand het probleem oplossen door als instructie mee te geven “upgrade de bash shell”.

Op andermans systeem binnengaan zonder toestemming is in beginsel computervredebreuk, zeker als je daarbij gebruik maakt van een technische ingreep en dat is dit zeker wel. Maar de wet spreekt letterlijk van “wederrechtelijk binnendringen” en dat betekent dat áls je een recht hebt, je niet strafbaar bent als je binnendringt.

Het recht zou in dit geval gevonden worden in de zaakwaarneming. Daar hebben we het al eerder over gehad, bijvoorbeeld in de context van andere mensen met open netwerkschijven helpen. De eis uit de wet (art. 6:198 BW) is kort gezegd dat een goede reden voor is en die persoon dat niet zelf kan doen. En je moet zo snel mogelijk verslag afleggen bij de persoon wiens zaak je hebt waargenomen.

Bij deze kwetsbaarheid kun je je afvragen of mensen dit niet zelf kunnen doen. Een mailtje sturen dat ze lek zijn, en dan kijken hoe er wordt gereageerd dus. Pas als er geen reactie komt én je reden hebt om aan te nemen dat men echt lek is en dit schade geeft, zou je zelf actie mogen ondernemen. Mits je dat dan maar ook mailt naar die partij.

Ik vind het dubbel. Enerzijds, de fix is eenvoudig en als deze is uitgevoerd door gewoon het standaard package management systeem aan te roepen dan is de kans op bijkomende schade nihil. Het resultaat is hetzelfde als wanneer meneer het zelf doet. Anderzijds, ik zou er ook niet vrolijk van worden als mensen bij mij dingen komen repareren die ik zelf net wilde gaan doen. Dus wanneer is het nódig dat je dit recht in eigen hand neemt?

Arnoud

23 reacties

  1. Als ik het goed herinner, dan heeft microsoft wel eens zoiets gedaan (maar dan natuurlijk bij windows i.p.v. Linux). Ik kan alleen niet zo snel een link vinden. Volgens mij was dat wel een tijdje geleden, dus misschien waren automatische updates toen nog niet zo gebruikelijk als nu. En het zou kunnen dat het daarbij om al geïnfecteerde computers van een botnet ging, waarbij het normale update-kanaal mogelijk gesaboteerd was.

  2. In theorie zou het kunnen dat iemand zelf een Bash-script heeft gemaakt dat afhankelijk is van het foutieve gedrag. Als je dan als buitenstaander een Bash-update uitvoert, dan maak je de werking van andermans script kapot. Toegegeven: als jij die schade kunt aanrichten, dan kan een kwaadwillende dat ook, en een kwaadwillende kan daarbij mogelijk nog meer schade aan toevoegen, maar dat is nog geen excuus om zelf de ander schade toe te brengen. In principe zou die ander zelf de afweging moeten maken: in theorie zou het kunnen dat het risico van kwaadwillenden lager wordt ingeschat dan de schade door het breken van bestaande Bash-scripts.

    In theorie moet het dus beter zijn om de ander op de hoogte te stellen van het bestaan van het lek, en de ander vervolgens de afweging te laten maken. Maar goed, in dit geval is dit een nogal theoretisch verschil, want het is niet erg waarschijnlijk dat iemand Bash-scripts heeft gemaakt die van dit obscure gedrag afhankelijk zijn.

    1. Persoonlijk lijkt mij dit het digitale equivalent van het breken van een voorruit om de uitgedroogde kat in de woonkamer te drinken te geven. En volgens mij (verbeter me als dit onjuist is) is dat nog steeds rechtmatig in het geval van zaakwaarneming; zolang die schade noodzakelijk is, en niet van noemenswaardig grotere impact dan het laten bestaan van de probleemsituatie.

      Persoonlijk lijkt het me erg moeilijk om te beargumenteren hoe het bestaan van een wijdverbreid bekende Remote Code Execution-vulnerability minder grote schade met zich meebrengt dan het kapotmaken van een functioneel bash-scriptje dat op dit lek bouwt. Vanuit moreel oogpunt is het natuuurlijk wel zo netjes om bij je verslag (dus “ik heb het voor je gefixt” e-mailtje) even te melden wat het lek was, en dat je ze eventueel kunt helpen met het repareren, in het onwaarschijnlijke geval dat legitieme sotware problemen ondervind van je oplossing.

      1. Maar wie ben jij om te bepalen wat voor mij schade is en wat niet? Wie ben jij om mijn belangenafweging te maken?

        En in algemene zin: waarom zou je in godesnaam je willen bemoeiten met andermans veiligheidsproblemen wanneer die ander daar niet om vraagt en het veiligheidsprobleem geen ‘derdenwerking’ heeft?

        Blijf gewoon met je tengels van mijn spullen af en ga iets nuttigs voor jezelf doen 😉

          1. Helder, dank Arnoud! Dat wordt dan een interessante discussie of (ten eerste) ik een verplichting heb om dergelijke schade bij derden te voorkomen (mag je van een reguliere gebruiker verwachten dat hij deze kennis heeft?) en (ten tweede) of het voorkomen van schade bij derden valt onder zaakswaarneming, wanneer de eigenaar van de waargenomen zaak zelf geen schade heeft. Het belang dat dan wordt behartigd is tenslotte in dat geval niet het belang van de eigenaar, maar dat van een derde (tenzij geconstrueerd kan worden dat het behartigde belang niet is het voorkomen van schade bij de derde, maar het voorkomen van aansprakelijkheid bij de eigenaar van de geinfecteerde machine).

        1. Vrijwel ieder beveiligingsprobleem heeft derdenwerking, dat is nu juist het probleem ervan. De aanname dat dat niet zo is, is helaas zowel veelvoorkomend als vrijwel altijd onjuist.

          En als we het op ethisch gebied gaan bekijken (“blijf gewoon met je tengels van mijn spullen af”), dan zou ik heel simpel zeggen: “jammer dan, jij brengt derden in gevaar door je beveiliging niet op orde te houden; op dat moment heb jij vanuit ethisch oogpunt helemaal geen recht meer om te klagen over schade.”

          Op juridisch gebied lijkt het me vrij duidelijk, zie al het bovenstaande.

            1. Nee, die verliezen meestal hun rijbewijs als ze gevaarlijk gedrag op de weg vertonen. Dat gebeurt regelmatig bij 70+ers die met 25 km/u over de snelweg hobbelen. Of gaan spookrijden. Of over de weg slingeren. Maar sowieso levert ieder ongeluk waarin je betrokken bent de mogelijkheid dat men je rijvaardigheid gaan betwijfelen. Zeker indien jij eraan schuldig bent. Maar dit is dan wel een taak voor politie, justitie en het CBR, niet voor andere weggebruikers. Echter, het is regelmatig voorgekomen dat andere weggebruikers zelf ingrijpen als iemand gevaarlijk weggedrag vertoont door b.v. de politie te bellen. Autosleutel dronken vrouw (78) afgepakt in Lochem Getuige van ongeluk op A50 pakt dronken bestuurder autosleutel af Genoeg voorbeelden hiervan…

      2. Persoonlijk lijkt het me erg moeilijk om te beargumenteren hoe het bestaan van een wijdverbreid bekende Remote Code Execution-vulnerability minder grote schade met zich meebrengt dan het kapotmaken van een functioneel bash-scriptje dat op dit lek bouwt.

        Het is misschien niet zo waarschijnlijk, maar ik kan met wat fantasie wel een scenario bedenken:

        Stel, je hebt een fabriekje, waar een robot aan de lopende band onderdelen produceert. De robot wordt aangestuurd via Bash-scriptjes die ergens afhankelijk zijn van het oude gedrag van Bash, en de robot-controller moet om een bepaalde reden aangesloten zijn op het bedrijfsnetwerk, en daarmee indirect op het internet.

        Het meeste “misbruik” van de vulnerability is dan relatief probleemloos: meestal zal er alleen een bot worden geïnstalleerd die spam gaat versturen of zo, en het productieproces wordt niet verstoord (aangenomen dat system resources niet zo’n probleem zijn). Er bestaat een kans dat een kwaadwillende jouw productieproces al dan niet bewust verstoort via deze route, maar die kans is minder dan 100%, terwijl, als een “goedbedoelende” inbreker jouw Bash upgradet, de kans 100% is dat je productieproces wordt verstoord. De verwachtingswaarde van de schade bij een upgrade kan dan groter zijn dan de verwachtingswaarde van de schade bij niet upgraden.

        1. Het meeste “misbruik” van de vulnerability is dan relatief probleemloos: meestal zal er alleen een bot worden geïnstalleerd die spam gaat versturen of zo, en het productieproces wordt niet verstoord (aangenomen dat system resources niet zo’n probleem zijn)

          Dat is echter geen redelijke aanname; om jouw voorbeeld te gebruiken, is het heel goed mogelijk om de betreffende productie te saboteren op zo’n manier dat het mensenlevens in gevaar brengt. Dat is niet een scenario waar je direct aan zou denken, maar wel een zeer realistisch scenario. Het gaat hier om een ‘remote code execution’-lek – dat betekent dat letterlijk alles gedaan kan worden op een gecompromitteerd systeem. De enige veilige aanname is dan ook dat het op de meest ernstig mogelijke manier misbruikt zal worden.

          1. Om het een beetje vriendelijk te houden, laat ik het scenario uitbreiden met de informatie dat de veiligheid zelfs in het ergste geval niet in gevaar komt, doordat die wordt gegarandeerd door het fysieke ontwerp van de machine, dat niet software-matig kan worden veranderd.

            Je hebt gelijk dat een “veilige aanname” uit moet gaan van de “worst case”. Echter: in dit scenario maak je denk ik een betere beslissing door uit te gaan van een “risico-analyse”, waarbij keuzes acceptabel zijn zelfs als ze risico’s met zich mee brengen, als ze gemiddeld genomen maar een betere uitkomst geven dan de alternatieve keuzes.

            Uiteindelijk zal de ondernemer natuurlijk zijn Bash-scriptjes moeten (laten) aanpassen, en/of de machine goed isoleren van het internet. Het kan echter zijn dat beide tijdrovend zijn, en in de tussentijd wil je niet dat de productie stil ligt.

  3. als deze is uitgevoerd door gewoon het standaard package management systeem aan te roepen dan is de kans op bijkomende schade nihil.
    Zeker weten? Ik heb in het verleden vaak genoeg meegemaakt dat een update van systeem-onderdelen ervoor konden zorgen dat het een en ander vervolgens mis ging. Sowieso kan de update zelf al misgaan simpelweg omdat de gebruiker niet door heeft dat er een update wordt uitgevoerd en dus het apparaat een reset geeft. Of wat als de update zelf een reset uitvoert en daarmee een langdurig en traag proces onderbreekt, zoals het renderen van een plaatje? Met Windows updates heb ik vaak genoeg meegemaakt dat ik bezig was met renderen en dit een paar dagen zou duren. Op zich geen probleem, mits de update het systeem niet stiekem in de achtergrond herstart zodat ik weer van voor af aan kan beginnen. Dan zijn er meerdere uren gewoon verspild. Wat als een systeem wordt gebruikt om bitcoins mee te minen en de update een reset uitvoert en het systeem vervolgens stopt met minen omdat deze bij het opstarten daarvoor geen opdracht krijgt. Als de gebruiker dan 1 keer per week even de status controleert kan hij dus bijne een week aan bitcoins hebben gemist, wat best een aardige schade kan zijn. En dan de eeuwigdurende circel: een router is gebaseerd op Linux en ontvangt een Bash update. Deze wordt uitgevoerd maar wordt niet opgeslagen door de router. Wel voert de router een reset uit, waarna weer de oude Bash shell wordt geladen. Deze wordt opnieuw door de hacker-software ontdekt en krijgt dus opnieuw een opdracht tot installeren. Die installatie slaagt en opnieuw een reset waarbij de oude versie weer opkomt. En ga zo maar door. Blijf je lekker bezig en de gebruiker maar klagen bij zijn provider omdat zijn Internet continu afbreekt… De aanname dat een dergelijke update geen schade oplevert gaat dus iets te kort door de bocht.

      1. Het is in ieder geval de Bash shell die opnieuw moet opstarten van de oude naar de nieuwe versie. Je hoeft niet de gehele kernel te herstarten maar de shell is toch een belangrijk onderdeel en een update ervan zal gevolgen met zich mee brengen. Bash is een onderdeel dat zeer dicht tegen de kernel aan ligt. Sommige web servers maken overigens gebruik van de Bash shell zodat ook zij gevoelig zijn voor deze hack, als je als hacker alleen de user agent aanpast naar iets dat Bash kan interpreteren… Kortom, een update van Bash kan grote gevolgen hebben voor een systeem.

        Overigens zijn nu eindelijk grote aantallen ontwikkelaars de broncode van Bash aan het doornemen en ze worden er niet blij van. Er blijken namelijk behoorlijk veel problemen te zijn met de code. Vooral problemen met de parser.

        1. De impact valt in de praktijk wel mee hoor. Ik heb in een eerdere reactie wel geopperd dat er in theorie een incompatibiliteit met bestaande scripts kan zijn, maar dat is niet veel meer dan een theoretische mogelijkheid. De veranderde “functionaliteit” zou sowieso nooit door scripts gebruikt moeten worden.

          De kwetsbaarheid doet zich alleen voor bij het starten van nieuwe Bash-processen, waarbij environment-variabelen worden meegegeven die data bevatten die van onbetrouwbare bron afkomstig zijn (lees: het internet). Je update-manager kan /bin/bash gewoon vervangen in je filesystem: dan worden alle nieuwe Bash-processen gestart met de nieuwe versie, en ben je van de kwetsbaarheid af. Het feit dat bestaande Bash-processen nog met de oude executable werken is niet relevant, dus herstarten is niet nodig.

          1. Maar zolang de oude Bash-processen nog draaien is het systeem dus kwetsbaar. Als je van buitenaf dus de update wilt forceren dan zul je de oude processen alsnog moeten stilleggen. En je weet niet welk doel die processen kunnen hebben. Ik weet bijvoorbeeld dat er bedrijven zijn die automatisch in aandelen handelen door hun computer rechtstreeks de laatste beursgegevens binnen te halen om te besluiten wanneer er gekocht of verkocht moet worden. Dit is een proces waarin iedere milliseconde telt en eigenlijk maar weinig interactie met menselijke gebruikers zijn. Als hierbij Bash wordt gebruikt en dat proces wordt verstoord dan zijn de gevolgen moeilijk te overzien. En dan krijg je het dilemma van de hacker die ziet dat deze machine de oude Bash gebruikt en dus een beveiligingsprobleem is. Hij forceert een update, maar dit proces blijft draaien met de oude versie van Bash. Dus beseft hij dat hij dit draaiende proces ook even moet killen, en daarmee begint de teller van de schade meteen op te lopen. Hopelijk doet hij moeite om het proces opnieuw op te starten, want de vraag is of de eigenaar het zelf wel op tijd opmerkt. Iedere seconde telt eigenlijk…

            1. Maar zolang de oude Bash-processen nog draaien is het systeem dus kwetsbaar.

              Nee, want zoals al gezegd: De kwetsbaarheid doet zich alleen voor bij het opstarten van nieuwe Bash-processen.

              Er hoeven dus geen bestaande bash-processen te worden herstart.

  4. Enerzijds, de fix is eenvoudig en als deze is uitgevoerd door gewoon het standaard package management systeem aan te roepen dan is de kans op bijkomende schade nihil. Het resultaat is hetzelfde als wanneer meneer het zelf doet.

    Dat klopt voor PC’s, maar Bash wordt ook wel gebruikt op embedded systemen zoals wireless routers, en die krijgen praktisch nooit automatische updates.

    Ik heb mijn eigen router gecontroleerd, en die draait gelukkig Busybox (met geïntegreerde Ash), en die is niet kwetsbaar voor dit probleem. Bash is niet eens geïnstalleerd. 🙂

  5. > Bij deze kwetsbaarheid kun je je afvragen of mensen dit niet zelf kunnen doen.

    Ik zit net te lezen hoe dat bij FreeBSD zou kunnen (blijkt ook kwetsbaar), maar zo simpel is dat voor mij nog niet, en ik dat dat ik een beetje een techneut ben, ik kende sh in 1986 al.

  6. Een slimme lezer mailde me vervolgens: wat nu als die code geen kwade bedoelingen heeft maar de getroffen Bash-shell upgradet naar een veilige versie?

    Dat zou alleen kunnen als CGI op de website zo is gefigureerd dat de scripts als user root draaien. Dat zou op zich al een megagroot securityrisico zijn, dus het lijkt me uitgesloten dat dat voorkomt, zodat de hele vraagstelling theoretisch is.

    Toch? Of mis ik iets?

    1. Wat je mist is dat er altijd dergelijke grote security risks zullen zijn. De vraag is alleen hoe bekend ze zijn. De risico’s die alleen bekend zijn bij 1 hacker zijn nog steeds enorme risico’s maar zolang die hacker het misbruik ervan kan verbergen duurt het erg lang voordat anderen dit door hebben. <aluhoedje>Ofwel, je hebt geen garantie dat je systeem echt veilig is.</aluhoedje>

Geef een reactie

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