Alia vundebleco estis identigita en la biblioteko Log4j 2 (CVE-2021-45105), kiu, male al la antaŭaj du problemoj, estas klasifikita kiel danĝera, sed ne kritika. La nova afero permesas vin kaŭzi neon de servo kaj manifestiĝas en formo de bukloj kaj kraŝoj dum prilaborado de certaj linioj. La vundebleco estis riparita en la eldono de Log4j 2.17 publikigita antaŭ kelkaj horoj. La danĝero de la vundebleco estas mildigita de la fakto, ke la problemo nur aperas en sistemoj kun Java 8.
La vundebleco influas sistemojn, kiuj uzas kontekstajn demandojn (Konteksta serĉo), kiel ${ctx:var}, por determini la protokolan eligformaton. Al Log4j-versioj de 2.0-alpha1 ĝis 2.16.0 mankis protekto kontraŭ nekontrolita rekurso, kio permesis al atakanto manipuli la valoron uzitan en la anstataŭigo por kaŭzi buklon, kaŭzante elĉerpiĝon de stakspaco kaj kraŝo. Precipe, la problemo okazis dum anstataŭigo de valoroj kiel "${${::-${::-$${::-j}}}}".
Aldone, oni povas rimarki, ke esploristoj de Blumira proponis opcion por ataki vundeblajn Java-aplikojn, kiuj ne akceptas eksterajn retajn petojn; ekzemple, la sistemoj de programistoj aŭ uzantoj de Java-aplikoj povas esti atakitaj tiamaniere. La esenco de la metodo estas, ke se ekzistas vundeblaj Java-procezoj en la sistemo de la uzanto, kiuj akceptas retajn konektoj nur de la loka gastiganto, aŭ procesas RMI-petojn (Remote Method Invocation, haveno 1099), la atako povas esti efektivigita per JavaScript-kodo efektivigita. kiam uzantoj malfermas malican paĝon en sia retumilo. Por establi konekton al la rethaveno de Java aplikaĵo dum tia atako, la WebSocket API estas uzata, al kiu, male al HTTP-petoj, samdevenaj limigoj ne estas aplikataj (WebSocket ankaŭ povas esti uzata por skani retajn havenojn sur la loka. gastiganto por determini disponeblajn retajn prizorgantojn).
Ankaŭ interesas la rezultoj publikigitaj de Guglo pri taksado de la vundebleco de bibliotekoj asociitaj kun Log4j-dependecoj. Laŭ Google, la problemo influas 8% de ĉiuj pakaĵoj en la Maven Centra deponejo. Aparte, 35863 Java-pakaĵoj asociitaj kun Log4j per rektaj kaj nerektaj dependecoj estis elmontritaj al vundeblecoj. Samtempe, Log4j estas uzata kiel rekta unuanivela dependeco nur en 17% de kazoj, kaj en 83% de tuŝitaj pakaĵoj, la ligado estas farita per mezaj pakaĵoj kiuj dependas de Log4j, t.e. toksomanioj de la dua kaj pli alta nivelo (21% - dua nivelo, 12% - tria, 14% - kvara, 26% - kvina, 6% - sesa). La rapideco de ripari la vundeblecon ankoraŭ lasas multon por deziri; semajnon post kiam la vundebleco estis identigita, el 35863 identigitaj pakaĵoj, la problemo estis riparita ĝis nun en nur 4620, t.e. je 13%.
Dume, la Usona Agentejo pri Protekto pri Cibersekureco kaj Infrastrukturo publikigis kriz-direktivon postulante federaciajn agentejojn identigi informsistemojn trafitaj de la vundebleco Log4j kaj instali ĝisdatigojn kiuj blokas la problemon antaŭ la 23-a de decembro. Ĝis la 28-a de decembro, organizaĵoj devas raporti pri sia laboro. Por simpligi la identigon de problemaj sistemoj, listo de produktoj, kiuj estis konfirmitaj elmontri vundeblecojn, estis preparita (la listo inkluzivas pli ol 23 mil aplikojn).
fonto: opennet.ru