Er is nog een kwetsbaarheid geïdentificeerd in de Log4j 2-bibliotheek (CVE-2021-45105), die, in tegenstelling tot de vorige twee problemen, als gevaarlijk, maar niet kritiek is geclassificeerd. Met het nieuwe probleem kun je een Denial of Service veroorzaken en manifesteert het zich in de vorm van lussen en crashes bij het verwerken van bepaalde regels. De kwetsbaarheid is opgelost in de Log4j 2.17-release die een paar uur geleden is uitgebracht. Het gevaar van de kwetsbaarheid wordt verzacht doordat het probleem alleen voorkomt op systemen met Java 8.
Het beveiligingslek treft systemen die contextuele queries (Context Lookup) gebruiken, zoals ${ctx:var}, om het loguitvoerformaat te bepalen. Log4j-versies van 2.0-alpha1 tot 2.16.0 misten bescherming tegen ongecontroleerde recursie, waardoor een aanvaller de waarde die bij de vervanging werd gebruikt, kon manipuleren om een lus te veroorzaken, wat leidde tot uitputting van de stapelruimte en een crash. Het probleem deed zich met name voor bij het vervangen van waarden zoals "${${::-${::-$${::-j}}}}".
Daarnaast kan worden opgemerkt dat onderzoekers van Blumira een optie hebben voorgesteld om kwetsbare Java-applicaties aan te vallen die geen externe netwerkverzoeken accepteren; de systemen van ontwikkelaars of gebruikers van Java-applicaties kunnen op deze manier bijvoorbeeld worden aangevallen. De essentie van de methode is dat als er kwetsbare Java-processen op het systeem van de gebruiker staan die alleen netwerkverbindingen van de lokale host accepteren, of RMI-verzoeken verwerken (Remote Method Invocation, poort 1099), de aanval kan worden uitgevoerd door JavaScript-code uit te voeren. wanneer gebruikers een kwaadaardige pagina in hun browser openen. Om tijdens een dergelijke aanval een verbinding tot stand te brengen met de netwerkpoort van een Java-applicatie, wordt gebruik gemaakt van de WebSocket API, waarop, in tegenstelling tot HTTP-verzoeken, geen same-origin-beperkingen worden toegepast (WebSocket kan ook worden gebruikt om netwerkpoorten op het lokale netwerk te scannen). host om de beschikbare netwerkhandlers te bepalen).
Ook van belang zijn de door Google gepubliceerde resultaten van het beoordelen van de kwetsbaarheid van bibliotheken die verband houden met Log4j-afhankelijkheden. Volgens Google treft het probleem 8% van alle pakketten in de Maven Central-repository. In het bijzonder werden 35863 Java-pakketten die via directe en indirecte afhankelijkheden met Log4j waren geassocieerd, blootgesteld aan kwetsbaarheden. Tegelijkertijd wordt Log4j slechts in 17% van de gevallen gebruikt als een directe afhankelijkheid op het eerste niveau, en in 83% van de getroffen pakketten wordt de binding uitgevoerd via tussenliggende pakketten die afhankelijk zijn van Log4j, d.w.z. verslavingen van het tweede en hogere niveau (21% - tweede niveau, 12% - derde, 14% - vierde, 26% - vijfde, 6% - zesde). Het tempo waarmee de kwetsbaarheid wordt opgelost laat nog steeds veel te wensen over; een week nadat de kwetsbaarheid was geïdentificeerd, is het probleem tot nu toe in slechts 35863 van de 4620 geïdentificeerde pakketten opgelost. op 13%.
Ondertussen heeft de Amerikaanse Cybersecurity and Infrastructure Protection Agency een noodrichtlijn uitgevaardigd die federale instanties verplicht om informatiesystemen die getroffen zijn door de Log4j-kwetsbaarheid te identificeren en vóór 23 december updates te installeren die het probleem blokkeren. Uiterlijk 28 december moeten organisaties rapporteren over hun werk. Om de identificatie van problematische systemen te vereenvoudigen, is er een lijst opgesteld met producten waarvan is bevestigd dat ze kwetsbaarheden vertonen (de lijst omvat meer dan 23 applicaties).
Bron: opennet.ru