Kerentanan liyane wis diidentifikasi ing perpustakaan Log4j 2 (CVE-2021-45105), sing, ora kaya rong masalah sadurunge, diklasifikasikake minangka mbebayani, nanging ora kritis. Jeksa Agung bisa ngetokake anyar ngijini sampeyan kanggo nimbulaké nolak layanan lan manifests dhewe ing wangun puteran lan tubrukan nalika proses baris tartamtu. Kerentanan kasebut diatasi ing rilis Log4j 2.17 sing dirilis sawetara jam kepungkur. Bebaya kerentanan dikurangi kanthi kasunyatan manawa masalah kasebut mung katon ing sistem Java 8.
Kerentanan mengaruhi sistem sing nggunakake pitakon kontekstual (Context Lookup), kayata ${ctx:var}, kanggo nemtokake format output log. Log4j versi saka 2.0-alpha1 kanggo 2.16.0 kurang pangayoman marang recursion uncontrolled, kang diijini panyerang ngapusi Nilai digunakake ing substitusi kanggo ndadékaké daur ulang, anjog kanggo kesel papan tumpukan lan kacilakan. Utamane, masalah kasebut kedadeyan nalika ngganti nilai kayata "${${::-${::-$${::-j}}}}".
Kajaba iku, bisa dicathet menawa peneliti saka Blumira wis ngusulake pilihan kanggo nyerang aplikasi Java sing rawan sing ora nampa panjaluk jaringan eksternal; contone, sistem pangembang utawa pangguna aplikasi Java bisa diserang kanthi cara iki. Inti saka metode kasebut yaiku yen ana proses Java sing rawan ing sistem pangguna sing nampa sambungan jaringan mung saka host lokal, utawa proses panjalukan RMI (Remote Method Invocation, port 1099), serangan kasebut bisa ditindakake kanthi kode JavaScript sing dieksekusi. nalika pangguna mbukak kaca ala ing browser. Kanggo nggawe sambungan menyang port jaringan aplikasi Java sajrone serangan kasebut, WebSocket API digunakake, sing, ora kaya panjaluk HTTP, watesan sing padha ora ditrapake (WebSocket uga bisa digunakake kanggo mindhai port jaringan ing lokal). host kanggo nemtokake pawang jaringan sing kasedhiya).
Uga menarik yaiku asil sing diterbitake Google babagan ngevaluasi kerentanan perpustakaan sing ana gandhengane karo dependensi Log4j. Miturut Google, masalah kasebut mengaruhi 8% kabeh paket ing repositori Maven Central. Khususé, 35863 paket Java sing digandhengake karo Log4j liwat dependensi langsung lan ora langsung katon ing kerentanan. Ing wektu sing padha, Log4j digunakake minangka katergantungan tingkat pertama langsung mung ing 17% kasus, lan ing 83% paket sing kena pengaruh, ikatan kasebut ditindakake liwat paket penengah sing gumantung ing Log4j, yaiku. kecanduan tingkat kaloro lan luwih (21% - tingkat kapindho, 12% - katelu, 14% - papat, 26% - kalima, 6% - enem). Laju kanggo ndandani kerentanan isih akeh sing dikarepake; seminggu sawise kerentanan kasebut diidentifikasi, saka 35863 paket sing diidentifikasi, masalah kasebut wis diatasi nganti saiki mung 4620, yaiku. ing 13%.
Sementara, Badan Perlindungan Siber lan Infrastruktur AS ngetokake arahan darurat sing mbutuhake agensi federal kanggo ngenali sistem informasi sing kena pengaruh kerentanan Log4j lan nginstal nganyari sing ngalangi masalah kasebut ing tanggal 23 Desember. Ing tanggal 28 Desember, organisasi kudu nglaporake karyane. Kanggo nyederhanakake identifikasi sistem sing bermasalah, dhaptar produk sing wis dikonfirmasi nuduhake kerentanan wis disiapake (dhaptar kasebut kalebu luwih saka 23 ewu aplikasi).
Source: opennet.ru