Ang isa pang kahinaan ay natukoy sa Log4j 2 library (CVE-2021-45105), na, hindi katulad ng nakaraang dalawang problema, ay inuri bilang mapanganib, ngunit hindi kritikal. Ang bagong isyu ay nagbibigay-daan sa iyo na magdulot ng pagtanggi sa serbisyo at nagpapakita ng sarili sa anyo ng mga loop at pag-crash kapag nagpoproseso ng ilang mga linya. Ang kahinaan ay naayos sa paglabas ng Log4j 2.17 na inilabas ilang oras ang nakalipas. Ang panganib ng kahinaan ay pinapagaan ng katotohanan na ang problema ay lilitaw lamang sa mga system na may Java 8.
Ang kahinaan ay nakakaapekto sa mga system na gumagamit ng mga contextual na query (Context Lookup), gaya ng ${ctx:var}, upang matukoy ang log output format. Ang mga bersyon ng Log4j mula 2.0-alpha1 hanggang 2.16.0 ay walang proteksyon laban sa hindi makontrol na recursion, na nagbigay-daan sa isang attacker na manipulahin ang value na ginamit sa pagpapalit upang maging sanhi ng loop, na humahantong sa pagkaubos ng stack space at pag-crash. Sa partikular, naganap ang problema kapag pinapalitan ang mga halaga gaya ng "${${::-${::-$${::-j}}}}".
Bukod pa rito, mapapansin na ang mga mananaliksik mula sa Blumira ay nagmungkahi ng opsyon na atakehin ang mga mahihinang Java application na hindi tumatanggap ng mga kahilingan sa panlabas na network; halimbawa, ang mga system ng mga developer o user ng mga Java application ay maaaring atakehin sa ganitong paraan. Ang kakanyahan ng pamamaraan ay kung may mga mahinang proseso ng Java sa system ng user na tumatanggap lamang ng mga koneksyon sa network mula sa lokal na host, o nagpoproseso ng mga kahilingan sa RMI (Remote Method Invocation, port 1099), ang pag-atake ay maaaring isagawa sa pamamagitan ng JavaScript code na pinaandar. kapag nagbukas ang mga user ng malisyosong page sa kanilang browser. Upang magtatag ng isang koneksyon sa network port ng isang Java application sa panahon ng naturang pag-atake, ang WebSocket API ay ginagamit, kung saan, hindi katulad ng mga kahilingan sa HTTP, ang mga paghihigpit sa parehong pinagmulan ay hindi inilalapat (WebSocket ay maaari ding gamitin upang i-scan ang mga network port sa lokal host upang matukoy ang magagamit na mga humahawak ng network).
Interesado rin ang mga resultang inilathala ng Google ng pagtatasa sa kahinaan ng mga aklatan na nauugnay sa mga dependency ng Log4j. Ayon sa Google, ang problema ay nakakaapekto sa 8% ng lahat ng mga pakete sa Maven Central repository. Sa partikular, 35863 Java packages na nauugnay sa Log4j sa pamamagitan ng direkta at hindi direktang mga dependency ang nalantad sa mga kahinaan. Kasabay nito, ang Log4j ay ginagamit bilang direktang dependency sa unang antas lamang sa 17% ng mga kaso, at sa 83% ng mga apektadong pakete, ang pagbubuklod ay isinasagawa sa pamamagitan ng mga intermediate na pakete na nakadepende sa Log4j, i.e. mga pagkagumon sa pangalawa at mas mataas na antas (21% - ikalawang antas, 12% - pangatlo, 14% - ikaapat, 26% - ikalima, 6% - ikaanim). Ang bilis ng pag-aayos ng kahinaan ay nag-iiwan pa rin ng maraming bagay na naisin; isang linggo pagkatapos matukoy ang kahinaan, sa 35863 natukoy na mga pakete, ang problema ay naayos na sa ngayon sa 4620 lamang, i.e. sa 13%.
Samantala, naglabas ang US Cybersecurity and Infrastructure Protection Agency ng emergency directive na nag-aatas sa mga pederal na ahensya na tukuyin ang mga sistema ng impormasyon na apektado ng kahinaan ng Log4j at mag-install ng mga update na humaharang sa problema sa Disyembre 23. Pagsapit ng Disyembre 28, ang mga organisasyon ay kinakailangang mag-ulat sa kanilang trabaho. Upang gawing simple ang pagkilala sa mga may problemang sistema, isang listahan ng mga produkto na nakumpirmang nagpapakita ng mga kahinaan ay inihanda (ang listahan ay may kasamang higit sa 23 libong mga aplikasyon).
Pinagmulan: opennet.ru