I Log4j 2-biblioteket er der opdaget en ny sårbarhed (CVE-2021-45105), som i modsætning til de to tidligere problemer er kategoriseret som farlig, men ikke kritisk. Det nye problem kan forårsage en tjenestenægtelse og viser sig som en uendelig loop og nedbrud ved behandling af bestemte strenge. Sårbarheden er blevet rettet i den udgave af Log4j 2.17, der blev offentliggjort for få timer siden. Faren ved sårbarheden mindskes af, at problemet kun viser sig på systemer med Java 8.
Sårbarhederne rammer systemer, der bruger kontekstforespørgsler (Context Lookup) til at bestemme logformatet, såsom ${ctx:var}. I versioner af Log4j fra 2.0-alpha1 til 2.16.0 manglede der beskyttelse mod ukontrolleret rekursion, hvilket gjorde det muligt for en angriber at manipulere værdien, der anvendes ved substitution, for at forårsage en uendelig loop, der resulterede i, at stakken løb tør for plads og processen nedbrød. Problemet opstod specifikt ved substitution af værdier som «${${::-${::-$${::-j}}}}».
Derudover kan det nævnes, at forskere fra Blumira har foreslået en angrebsmetode mod sårbare Java-applikationer, der ikke accepterer eksterne netværksanmodninger; for eksempel kan systemer, der ejes af udviklere eller brugere af Java-applikationer, angribes på denne måde. Metodens essens er, at hvis systemet har sårbare Java-processer, der kun accepterer netværksforbindelser fra localhost, eller behandler RMI-anmodninger (Remote Method Invocation, port 1099), kan angrebet udføres med JavaScript-kode, der aktiveres ved at åbne en skadelig webside i browseren for brugerne. For at etablere en forbindelse til netværksporten af Java-applikationen ved en sådan angreb anvendes WebSocket API, som, i modsætning til HTTP-anmodninger, ikke er underlagt same-origin-politikker (WebSocket kan også bruges til at scanne netværksporte på localhost for at identificere eksisterende netværkshåndterere).
Der offentliggjorte rapport fra Google om sårbarheden af biblioteker med afhængigheder til Log4j er også interessant. Ifølge Google påvirker problemet 8% af alle pakker i Maven Central-repositoriet. Specifikt er 35863 Java-pakker, relateret til Log4j, sårbare via direkte og indirekte afhængigheder. Log4j bruges som en direkte førstelags afhængighed i kun 17% af tilfældene, mens 83% af de berørte pakker binder via mellempakker, der er afhængige af Log4j, dvs. afhængigheder på andet og højere niveau (21% - andet niveau, 12% - tredje niveau, 14% - fjerde niveau, 26% - femte niveau, 6% - sjette niveau). Tempoet for at rette sårbarheden er stadig utilfredsstillende; en uge efter opdagelsen af sårbarheden er problemet kun blevet løst i 4620 af de 35863 identificerede pakker, hvilket svarer til 13%.
Imens har det amerikanske Cybersecurity and Infrastructure Security Agency udgivet en hastende direktiv, der pålægger føderale agenturer at identificere informationssystemer, der er sårbare over for Log4j, og installere opdateringer, der blokerer for problemet inden den 23. december. Inden den 28. december skal organisationer indgive rapporter om det udførte arbejde. For at lette identificeringen af de problematiske systemer er der udarbejdet en liste over produkter, hvor sårbarheden er bekræftet (listen indeholder over 23.000 applikationer).
Kilde: opennet.ru
