Egy másik sérülékenységet azonosítottak a Log4j 2 könyvtárban (CVE-2021-45105), amely az előző két problémával ellentétben veszélyesnek, de nem kritikusnak minősül. Az új kiadás szolgáltatásmegtagadás előidézését teszi lehetővé, és bizonyos sorok feldolgozása során hurkok és összeomlások formájában nyilvánul meg. A sérülékenységet a Log4j 2.17 néhány órája megjelent kiadásában javították ki. A sérülékenység veszélyét mérsékli, hogy a probléma csak a Java 8-as rendszereken jelentkezik.
A biztonsági rés olyan rendszereket érint, amelyek környezetfüggő lekérdezéseket (Context Lookup) használnak, például ${ctx:var} a napló kimeneti formátumának meghatározásához. A 4-alpha2.0 és 1 közötti Log2.16.0j-verziók nem tartalmaztak védelmet az ellenőrizetlen rekurzióval szemben, ami lehetővé tette a támadó számára, hogy a helyettesítésben használt érték manipulálásával hurkot idézzen elő, ami a veremterület kimerüléséhez és összeomláshoz vezetett. A probléma különösen akkor fordult elő, amikor olyan értékeket helyettesítettek, mint például a "${${::-${::-$${::-j}}}}".
Emellett megjegyezhető, hogy a Blumira kutatói egy lehetőséget javasoltak a sebezhető Java alkalmazások megtámadására, amelyek nem fogadnak el külső hálózati kéréseket, így például a Java alkalmazások fejlesztőinek vagy felhasználóinak rendszerei támadhatók meg. A módszer lényege, hogy ha a felhasználó rendszerén vannak olyan sérülékeny Java folyamatok, amelyek csak a helyi gazdagéptől fogadnak el hálózati kapcsolatot, vagy RMI kéréseket dolgoznak fel (Remote Method Invocation, 1099-es port), akkor a támadás végrehajtható JavaScript kóddal. amikor a felhasználók rosszindulatú oldalt nyitnak meg a böngészőjükben. Egy ilyen támadás során a Java-alkalmazás hálózati portjával való kapcsolat létrehozásához a WebSocket API-t használják, amelyre a HTTP-kérésekkel ellentétben nem vonatkoznak az azonos eredetű korlátozások (a WebSocket a helyi hálózati portok vizsgálatára is használható gazdagép az elérhető hálózati kezelők meghatározásához).
Szintén érdekesek a Google által közzétett eredmények a Log4j-függőségekkel kapcsolatos könyvtárak sebezhetőségének felméréséről. A Google szerint a probléma a Maven Central adattárában található összes csomag 8%-át érinti. A Log35863j-hez közvetlen és közvetett függőségeken keresztül kapcsolódó 4 4 Java-csomag volt kitéve a sebezhetőségnek. Ugyanakkor a Log17j-t közvetlen első szintű függőségként csak az esetek 83%-ában használják, az érintett csomagok 4%-ában pedig a Log21j-től függő köztes csomagokon keresztül történik a kötés, pl. a második és magasabb szintű függőségek (12% - második szint, 14% - harmadik, 26% - negyedik, 6% - ötödik, 35863% - hatodik). A sérülékenység kijavításának üteme továbbra is hagy kívánnivalót maga után, egy héttel a sérülékenység azonosítása után a 4620 13 azonosított csomagból eddig mindössze XNUMX XNUMX-nál sikerült megoldani a problémát, azaz. XNUMX%-nál.
Eközben az Egyesült Államok Kiberbiztonsági és Infrastruktúravédelmi Ügynöksége vészhelyzeti irányelvet adott ki, amely előírja a szövetségi ügynökségeknek, hogy azonosítsák a Log4j sebezhetősége által érintett információs rendszereket, és december 23-ig telepítsenek frissítéseket, amelyek megakadályozzák a problémát. December 28-ig a szervezeteknek be kell számolniuk munkájukról. A problémás rendszerek azonosításának egyszerűsítése érdekében elkészült a bizonyítottan sérülékenységet mutató termékek listája (a lista több mint 23 ezer alkalmazást tartalmaz).
Forrás: opennet.ru