Ilang linggo na ang nakalilipas, ang balita ng mga problema sa seguridad ng Log4j ay nagpabaligtad ng maraming mga gumagamit sa network at ito ay isa sa mga bahid na pinakamaraming pinagsamantalahan at binansagan ng maraming eksperto bilang "pinaka-mapanganib sa isang mahabang panahon », Sa mga kahinaan na ipinaalam sa network ay pinag-uusapan natin ang ilan sa mga ito dito sa blog at sa pagkakataong ito ay nakahanap na kami ng balita ng isa pa.
At ito ay ilang araw na ang nakalipas ang balita ay inilabas na ang isa pang kahinaan ay natukoy sa Log4j 2 library (na nakalista na sa ilalim ng CVE-2021-45105) at kung saan, hindi katulad ng nakaraang dalawang isyu, ay inuri bilang mapanganib, ngunit hindi kritikal.
Ang bagong problema nagbibigay-daan sa pagtanggi sa serbisyo at nagpapakita ng sarili sa anyo ng mga loop at abnormal na pagwawakas kapag pinoproseso ang ilang mga linya.
Kakayahang mangyari nakakaapekto sa mga system na gumagamit ng paghahanap sa konteksto, gaya ng $ {ctx: var}, upang matukoy ang format ng output ng log.
ang Ang mga bersyon ng Log4j na 2.0-alpha1 hanggang 2.16.0 ay walang proteksyon laban sa hindi makontrol na recursion, Ano pinahintulutan ang isang umaatake na manipulahin ang halaga na ginamit sa pagpapalit na magdulot ng walang katapusang loop na mauubusan ng espasyo sa stack at maging sanhi ng pag-hang ng proseso. Sa partikular, naganap ang problema kapag pinapalitan ang mga halaga tulad ng "$ {$ {:: - $ {:: - $$ {:: - j}}}}".
Bukod dito, Mapapansing ang mga mananaliksik ng Blumira ay nagmungkahi ng pag-atake sa mga mahihinang aplikasyon ng Java na hindi tumatanggap ng mga kahilingan mula sa mga panlabas na network, halimbawa, ang mga system ng mga developer o gumagamit ng mga Java application ay maaaring atakehin sa ganitong paraan.
Ang kakanyahan ng pamamaraan ay kung mayroong mga mahina na proseso ng Java sa system ng user na tumatanggap lamang ng mga koneksyon sa network mula sa lokal na host (localhost), o nagpoproseso ng mga kahilingan sa RMI (Remote Method Invocation, port 1099), ang pag-atake ay maaaring gawin sa pamamagitan ng executed JavaScript code kapag nagbukas ang user ng malisyosong page sa browser. Upang magtatag ng koneksyon sa network port ng isang Java application sa naturang pag-atake, ginagamit ang WebSocket API, kung saan, hindi tulad ng mga kahilingan sa HTTP, walang mga paghihigpit sa parehong pinagmulan ang inilalapat (maaari ding gamitin ang WebSocket upang i-scan ang mga port ng network sa lokal host upang matukoy ang mga available na driver ng network).
Interesado rin ang mga resulta ng pagsusuri sa kahinaan ng mga library na nauugnay sa mga dependency sa Log4j na inilathala ng Google. Ayon sa Google, ang problema ay nakakaapekto sa 8% ng lahat ng mga pakete sa Maven Central repository.
Sa partikular, 35863 Log4j related Java packages na may direkta at hindi direktang mga dependency ang nalantad sa mga kahinaan. Sa turn, ang Log4j ay ginagamit bilang isang direktang dependency ng unang antas lamang sa 17% ng mga kaso, at sa 83% ng mga pakete na sakop ng kahinaan, ang pagbubuklod ay ginagawa sa pamamagitan ng mga intermediate na pakete na nakadepende sa Log4j, ibig sabihin. dependencies ng pangalawa at pinakamataas na antas (21% - ang pangalawang antas, 12% - ang pangatlo, 14% - ang ikaapat, 26% - ang ikalima, 6% - ang ikaanim).
Ang bilis ng pag-aayos ng kahinaan ay nag-iiwan pa rin ng maraming nais, isang linggo pagkatapos matukoy ang kahinaan, mula sa 35863 na mga pakete na natukoy, ang problema ay naayos hanggang ngayon lamang sa 4620, iyon ay, sa 13%.
Ang mga pagbabago sa package ay kinakailangan upang i-update ang mga kinakailangan sa dependency at palitan ang mga lumang bersyon na binding ng mga nakapirming bersyon ng Log4j 2 (Ang mga Java package ay nagsasanay sa pag-binding sa isang partikular na bersyon, at hindi isang bukas na saklaw na nagbibigay-daan sa pag-install ng pinakabagong bersyon).
Ang pag-aalis ng kahinaan sa mga application ng Java ay nahahadlangan ng katotohanan na ang mga programa ay kadalasang nagsasama ng isang kopya ng mga aklatan sa paghahatid, at hindi sapat na i-update ang bersyon ng Log4j 2 sa mga pakete ng system.
Samantala, naglabas ang U.S. Agency for Infrastructure Protection and Cybersecurity ng emergency directive na nangangailangan ng mga pederal na ahensya na tukuyin ang mga sistema ng impormasyon na apektado ng kahinaan sa Log4j at mag-install ng mga update na humaharang sa problema. bago ang Disyembre 23.
Sa kabilang banda, ang isang gabay ay ibinigay hanggang Disyembre 28, kung saan ang mga organisasyon ay may obligasyon na mag-ulat sa gawaing isinagawa. Upang gawing simple ang pagkilala sa mga may problemang sistema, isang listahan ng mga produkto kung saan ang pagpapakita ng isang kahinaan ay nakumpirma ay inihanda (mayroong higit sa 23 libong mga aplikasyon sa listahan).
Sa wakas, Ito ay nagkakahalaga ng pagbanggit na ang kahinaan ay naayos sa Log4j 2.17 na nai-publish ilang araw na ang nakakaraan. at ang mga gumagamit na hindi pinagana ang mga update ay inirerekomenda na isagawa ang kaukulang pag-update, bilang karagdagan sa katotohanan na ang panganib ng kahinaan ay pinapagaan ng katotohanan na ang problema ay nagpapakita lamang ng sarili nito sa mga system na may Java 8.
Fuente: https://logging.apache.org/