A Log4j 2 könyvtárban egy újabb sebezhetőség (CVE-2021-45105) került elő, amely a két korábbi problémától eltérően veszélyesnek, de nem kritikusnak minősül. Az új probléma szolgáltatásmegszakítást idézhet elő, és ciklikus hibaként jelentkezik bizonyos karakterláncok feldolgozása során. A sebezhetőség a nemrégiben közzétett Log4j 2.17 kiadásban lett javítva. A sebezhetőség veszélyét csökkenti, hogy a probléma csak a Java 8-zal rendelkező rendszereken lép fel.
A sebezhetőségeknek kitett rendszerek közé tartoznak azok, amelyek a kimeneti formátum logolásához kontextuális lekérdezéseket (Context Lookup) használnak, mint például ${ctx:var}. A Log4j 2.0-alpha1-től 2.16.0-ig terjedő verziókban nem volt védelem a kontrollálatlan rekurzió ellen, ami lehetővé tette a támadó számára, hogy az átkonvertált érték manipulálásával ciklikus hívást idézzen elő, ami a verem helyének kimerüléséhez és a folyamat leállásához vezetett. Különösen a következő értékek behelyettesítésekor merült fel a probléma: "${${::-${::-$${::-j}}}}".
Ezenkívül érdemes megemlíteni, hogy a Blumira cég kutatói támadási módot javasoltak sebezhető Java-alkalmazások ellen, amelyek nem fogadnak külső hálózati kéréseket; például így lehet támadni a fejlesztők vagy Java-alkalmazások felhasználóinak rendszereit. A módszer lényege, hogy ha a felhasználó rendszerén olyan sebezhető Java-folyamatok futnak, amelyek csak helyi hosztból (localhost) fogadnak hálózati kapcsolatokat, vagy RMI-kéréseket (Remote Method Invocation, 1099 port) kezelnek, a támadás JavaScript-kóddal valósítható meg, amelyet ártalmas weboldal megnyitásakor futtatnak a felhasználó böngészőjében. Ehhez a Java-alkalmazás hálózati portjához való kapcsolódáshoz WebSocket API-t használnak, amelyre a HTTP-kérésekkel szemben nincsenek same-origin korlátozások (a WebSocket hálózati portok helyi hoszton történő beolvasására is használható a meglévő hálózati kezelők azonosítása érdekében).
A Google által közzétett eredmények is érdekesek a Log4j-hoz kapcsolódó könyvtárak sebezhetőségi értékeléséről. A Google adatai szerint a probléma a Maven Central tároló összes csomagjának 8%-át érinti. Különösen 35863 Java-csomag sebezhető a Log4j direkt és indirekt függőségeivel szemben. A Log4j első szintű direkt függőségként mindössze 17%-ban fordul elő, míg a sebezhetőséggel érintett csomagok 83%-ában közvetett csomagok, amelyek Log4j-tól függenek, tehát második és magasabb szintű függőségről van szó (21% — második szint, 12% — harmadik, 14% — negyedik, 26% — ötödik, 6% — hatodik). A sebezhetőség javításának üteme egyelőre kielégítőtlen, egy héttel a probléma felfedezése után a 35863 nyilvántartott csomag közül eddig csak 4620-ban, azaz 13%-ban sikerült megoldani a problémát.
Közben az Egyesült Államok Kiberbiztonsági és Infrastruktúra Biztonsági Ügynöksége sürgősségi irányelvet tett közzé, amely kötelezi a szövetségi ügynökségeket, hogy azonosítsák az Log4j sebezhetőségének kitett információs rendszereket, és december 23-ig telepítsenek frissítéseket, amelyek blokkolják a problémát. December 28-ig az intézményeknek jelentést kell tenniük az elvégzett munkáról. A problémás rendszerek egyszerűbb azonosítása érdekében kidolgoztak egy termékl listát, amelyben megerősítették a sebezhetőség megjelenését (a listán több mint 23 ezer alkalmazás szerepel).
Forrás: opennet.ru
