In de Log4j 2-bibliotheek is opnieuw een kwetsbaarheid ontdekt (CVE-2021-45105), die, in tegenstelling tot de twee eerdere problemen, is geclassificeerd als gevaarlijk, maar niet kritiek. Het nieuwe probleem kan leiden tot een denial-of-service en manifesteert zich in de vorm van een oneindige lus en een ongeplande afsluiting bij het verwerken van bepaalde strings. De kwetsbaarheid is verholpen in de zojuist verschenen release van Log4j 2.17. Het gevaar van de kwetsbaarheid wordt verzacht doordat het probleem alleen voorkomt op systemen met Java 8.
Kwetsbaar zijn systemen die contextuele zoekopdrachten (Context Lookup) gebruiken bij het bepalen van het log-uitvoerformaat, zoals ${ctx:var}. In de versies van Log4j, van 2.0-alpha1 tot en met 2.16.0, ontbrak bescherming tegen ongecontroleerde recursie, waardoor een aanvaller via manipulatie van de waarde die wordt gebruikt bij de substitutie een oneindige lus kon veroorzaken, wat leidde tot het uitputten van de stackruimte en een ongeplande afsluiting van het proces. In het bijzonder deed het probleem zich voor bij het vervangen van waarden zoals "${${::-${::-$${::-j}}}}".
Daarnaast kan worden opgemerkt dat onderzoekers van Blumira een aanvalsmethode hebben voorgesteld voor kwetsbare Java-applicaties die geen externe netwerkverzoeken accepteren. Bijvoorbeeld, systemen van ontwikkelaars of gebruikers van Java-applicaties kunnen op deze manier worden aangevallen. De essentie van de methode is dat wanneer er kwetsbare Java-processen op het systeem van de gebruiker aanwezig zijn, die alleen verbindingen van de localhost (localhost) accepteren of RMI-verzoeken (Remote Method Invocation, poort 1099) verwerken, de aanval kan worden uitgevoerd met JavaScript-code die wordt uitgevoerd wanneer gebruikers een kwaadaardige pagina in hun browser openen. Voor het tot stand brengen van een verbinding met de netwerkpoort van de Java-applicatie wordt bij een dergelijke aanval de WebSocket-API gebruikt, die in tegenstelling tot HTTP-verzoeken geen same-origin-beperkingen toepast (WebSocket kan ook worden gebruikt voor het scannen van netwerkpoorten op de localhost om beschikbare netwerkhandelaars te identificeren).
Ook de door Google gepubliceerde resultaten van de kwetsbaarheidsbeoordeling van bibliotheken die afhankelijk zijn van Log4j zijn interessant. Volgens Google raakt het probleem 8% van alle pakketten in de Maven Central-repository. In totaal zijn 35863 Java-pakketten kwetsbaar gebleken die verband houden met Log4j, via directe en indirecte afhankelijkheden. Log4j wordt in slechts 17% van de gevallen als een directe eerste niveau afhankelijkheid gebruikt, terwijl in 83% van de kwetsbare pakketten de binding plaatsvindt via tussenliggende pakketten die afhankelijk zijn van Log4j, dat wil zeggen afhankelijkheden van het tweede en hogere niveau (21% - tweede niveau, 12% - derde, 14% - vierde, 26% - vijfde, 6% - zesde). De snelheden van de kwetsbaarheidcorrectie laten op dit moment nog te wensen over; een week na de ontdekking van de kwetsbaarheid is het probleem in slechts 4620 van de 35863 ontdekte pakketten opgelost, wat neerkomt op 13%.
Ondertussen heeft het Amerikaanse Cybersecurity and Infrastructure Security Agency een dringende richtlijn gepubliceerd die federale agentschappen verplicht om informatie systemen die kwetsbaar zijn voor Log4j te identificeren en voor 23 december updates te installeren die het probleem verhelpen. Tot 28 december wordt van organisaties verwacht dat zij verslag uitbrengen van het voltooide werk. Ter vereenvoudiging van de identificatie van problematische systemen is er een lijst van producten opgesteld waarin de kwetsbaarheid is bevestigd (de lijst bevat meer dan 23.000 applicaties).
Bron: opennet.ru
