Op 17 december, 2021 in hun blog heeft Google Open Source Insights Team de hele situatie uitgelegd die ze hebben waargenomen met betrekking tot Apache Log4j Vulnerability. Ze beschreven de wijdverbreide kwetsbaarheid en de huidige vooruitgang bij het repareren van het open source JVM-ecosysteem. Team deelde ook hun gedachten over hoe lang het mogelijk zal duren voordat deze kwetsbaarheid in het hele ecosysteem is verholpen en waar we ons vervolgens op moeten concentreren.
Op 9 december hoorde het informatiebeveiligingsecosysteem van het bestaan van de kwetsbaarheid die een grote mate van ernst en wijdverbreide impact met zich meebrengt. Tienduizenden softwarepakketten (artefacten in het Java-ecosysteem) en projecten gebruiken een populaire logboektool, log4j die de kwetsbaarheden bleek te hebben besproken. Zoals specialisten uitleggen, maken deze kwetsbaarheden de uitvoering van externe code mogelijk door gebruik te maken van de schuchtere JNDI-lookups-functie die is blootgelegd door de logboekbibliotheek log4j. In veel versies van de bibliotheek bestond de geëxploiteerde functie standaard.
Apache Log4j Kwetsbaarheid duurt even om te verhelpen
Nog niet zo lang geleden onthulde log4j-kwetsbaarheden meer dan 35,000 Java-pakketten, nummering tot over 8% van de Maven Central-repository. Omdat de repository de belangrijkste repository voor Java-pakketten was, veroorzaakte dit een uitgebreid resultaat voor de software-industrie. Specialisten wijzen erop dat 8% is een enorm resultaat voor de uitkomst van het ecosysteem, terwijl het gemiddelde aantal voor de uitkomst van Maven Central-adviezen overeenkomt met 2% en de mediaan kleiner dan 0.1%. Hoewel de genoemde nummers niet alle Java-pakketten omvatten, bijvoorbeeld direct gedistribueerde binaire bestanden.
Op het moment van publicatie van de post zijn bijna vijfduizend van de betreffende artefacten gerepareerd. en over 30,000 artefacten, veel afhankelijk van een ander artefact, wacht nog steeds op patch. Het team vermeldt dat ze een artefact als opgelost beschouwden als het artefact ten minste één versie had beïnvloed en een grotere niet-beïnvloede stabiele versie heeft uitgebracht (dat is volgens semantische versiebeheer). In het geval van log4j wordt een artefact als gerepareerd beschouwd als het is bijgewerkt naar: 2.16.0 of is niet langer afhankelijk van log4j.
Twee belangrijke problemen belemmeren het herstelproces
Hoewel de situaties in het algemeen als duidelijk kunnen worden omschreven, de specialisten wijzen op twee belangrijke fixeerproblemen. Het eerste doel dat ze definiëren, is het feit dat veel artefacten indirect afhankelijk zijn van log4j. Die van directe afhankelijkheden zijn goed voor ongeveer 7,000 van de getroffen artefacten. In een dergelijk geval zijn alle versies afhankelijk van een getroffen versie van log4j-core of log4j-api, beschreven in de CVE's. De indirecte afhankelijkheid of transitieve afhankelijkheid betekent de afhankelijkheden van de eigen afhankelijkheden.
Al het personeel van deze afhankelijkheid zorgt voor aanzienlijke belemmeringen bij het oplossen of het bekijken met afhankelijkheidsketens. Hier blijft alles vrij duidelijk: hoe dieper de kwetsbaarheid valt neer, hoe meer stappen men moet nemen om het te repareren. Volgens de afhankelijkheidsgrafieken van het team toonden de histogramresultaten grote aantallen. In meer dan 80% van de pakketten kwetsbaarheid is meer dan één niveau diep. In de meeste daarvan is het vijf niveaus lager en in ongeveer negen niveaus lager. Het proces van repareren vereist dat je eerst naar de diepste afhankelijkheden gaat en daarna alle bomen.
Open reeksen geeft de mogelijkheid om de meest recent uitgebrachte versie te selecteren
Een andere moeilijkheid ligt in keuzes op ecosysteemniveau in het algoritme voor afhankelijkheidsresolutie en conventies voor vereistenspecificaties. De praktijk verschilt van die zoals npm, waar ze routinematig open bereiken specificeren voor afhankelijkheidsvereisten. Open reeksen bieden de mogelijkheid om de meest recent uitgebrachte versie te selecteren die voldoet aan de afhankelijkheidsvereisten. En het trekt vervolgens nieuwe oplossingen aan. Gebruikers ontvangen een gepatchte versie bij de volgende build na de beschikbaarheid van de patch. Het genereert de afhankelijkheden sneller.
“In het Java-ecosysteem, het is gebruikelijk om "zachte" versievereisten te specificeren - exacte versies die worden gebruikt door het resolutie-algoritme als er geen andere versie van hetzelfde pakket eerder in de afhankelijkheidsgrafiek verschijnt. Het verspreiden van een fix vereist vaak expliciete actie van de beheerders om de afhankelijkheidsvereisten bij te werken naar een gepatchte versie,” Open Source Insights-team schreef over dit tweede probleem.
Hiermee adviseert Team de open source-community om geautomatiseerde afhankelijkheidsupdates in te schakelen en beveiligingsbeperkingen toe te voegen. Ze gaven ook een lijst met 500 getroffen pakketten met het hoogste transitieve gebruik. Naar de mening van specialisten zal het prioriteren van deze pakketten de reparatie-inspanningen vergemakkelijken en vervolgens meer van de gemeenschap deblokkeren. Het team bedankte die open source-beheerders en consumenten die hun versies van log4j hebben geüpgraded.
Op de vraag hoe lang het zou duren om alles volledig op te lossen, gaf het team een vage mening. Ze zeggen dat het moeilijk is om te weten. Als het allemaal openbaar gemaakte kritieke adviezen zijn die van invloed zijn op Maven-pakketten, kan het proces even duren. Ze zeggen minder dan de helft (48%) van de artefacten die door een kwetsbaarheid zijn getroffen, zijn verholpen. Maar op het log4j-front lijken de dingen veelbelovend met ongeveer 13% die zijn gerepareerd.
