En anden sårbarhed (CVE-4-2) er blevet identificeret i Log2021j 45105-biblioteket, som i modsætning til de to tidligere problemer er kategoriseret som farligt, men ikke kritisk. Et nyt problem giver mulighed for en lammelsesangrebstilstand, der manifesterer sig som en løkke og nedbrud ved behandling af bestemte linjer. Sårbarheden blev rettet i Log4j 2.17-udgivelsen, der blev offentliggjort for et par timer siden. Sårbarhedens fare afbødes af, at problemet kun opstår på systemer, der kører Java 8.
Sårbarheden påvirker systemer, der bruger kontekstsøgningsforespørgsler, såsom ${ctx:var}, til at bestemme logoutputformatet. Log4j-versioner fra 2.0-alpha1 til 2.16.0 manglede beskyttelse mod ukontrolleret rekursion, hvilket tillod en angriber at manipulere den værdi, der blev brugt i substitutionen, for at forårsage et loop, hvilket førte til udtømning af stakplads og et procesnedbrud. Problemet opstod især ved substitution af værdier som "${${::-${::-$${::-j}}}}".
Derudover skal det bemærkes, at forskere fra Blumira har foreslået en variant af angrebet på sårbare Java-applikationer, der ikke accepterer eksterne netværksanmodninger. For eksempel er det muligt at angribe systemer tilhørende udviklere eller brugere af Java-applikationer på denne måde. Essensen af metoden er, at hvis der er sårbare Java-processer på brugerens system, der kun accepterer netværksforbindelser fra den lokale vært (localhost) eller behandler RMI-anmodninger (Remote Method Invocation, port 1099), kan angrebet udføres af JavaScript-kode, der udføres, når brugeren åbner en ondsindet side i browseren. For at organisere en forbindelse til Java-applikationens netværksport i et sådant angreb bruges WebSocket API'en, som i modsætning til HTTP-anmodninger ikke anvendes til samme-oprindelsesbegrænsninger (WebSocket kan også bruges til at scanne netværksporte på den lokale vært for at bestemme de tilgængelige netværkshandlere).
Af interesse er også resultaterne af sårbarhedsvurderingen af biblioteker relateret til Log4j, offentliggjort af Google. Ifølge Google påvirker problemet 8% af alle pakker i Maven Central-arkivet. Især 35863 Java-pakker relateret til Log4j via direkte og indirekte afhængigheder blev fundet at være sårbare. Samtidig bruges Log4j kun som en direkte afhængighed på første niveau i 17% af tilfældene, og i 83% af sårbare pakker udføres bindingen gennem mellemliggende pakker, der er afhængige af Log4j, dvs. afhængigheder på andet niveau og højere (21% - andet niveau, 12% - tredje, 14% - fjerde, 26% - femte, 6% - sjette). Andelen af udbedring af sårbarheder lader stadig meget tilbage at ønske: en uge efter at sårbarheden blev identificeret, er problemet ud af 35863 identificerede pakker kun blevet rettet i 4620, dvs. 13%.
I mellemtiden udstedte U.S. Cybersecurity and Infrastructure Security Agency et nøddirektiv, der forpligter føderale agenturer til at identificere informationssystemer, der er berørt af Log4j-sårbarheden og installere patches for at blokere problemet senest den 23. december. Organisationer er forpligtet til at rapportere om det arbejde, de har udført, senest den 28. december. indeholder mere end 23 tusinde applikationer).
Kilde: opennet.ru
