Log4j 2 bibliotēkā (CVE-2021-45105) konstatēta vēl viena ievainojamība, kas atšķirībā no divām iepriekšējām problēmām ir klasificēta kā bīstama, bet ne kritiska. Jaunā problēma ļauj izraisīt pakalpojuma atteikumu un izpaužas kā cilpas un avārijas, apstrādājot noteiktas līnijas. Ievainojamība tika novērsta Log4j 2.17 laidienā, kas tika izlaists pirms dažām stundām. Ievainojamības risku mazina fakts, ka problēma parādās tikai sistēmās ar Java 8.
Ievainojamība ietekmē sistēmas, kas izmanto kontekstuālos vaicājumus (Context Lookup), piemēram, ${ctx:var}, lai noteiktu žurnāla izvades formātu. Log4j versijām no 2.0-alpha1 līdz 2.16.0 trūka aizsardzības pret nekontrolētu atkārtošanos, kas ļāva uzbrucējam manipulēt ar aizstāšanā izmantoto vērtību, lai izraisītu cilpu, izraisot steka vietas izsīkumu un avāriju. Jo īpaši problēma radās, aizstājot tādas vērtības kā "${${::-${::-$${::-j}}}}".
Turklāt var atzīmēt, ka Blumira pētnieki ir piedāvājuši iespēju uzbrukt neaizsargātām Java lietojumprogrammām, kas nepieņem ārēju tīklu pieprasījumus, piemēram, šādi var tikt uzbruktas Java aplikāciju izstrādātāju vai lietotāju sistēmas. Metodes būtība ir tāda, ka, ja lietotāja sistēmā ir ievainojami Java procesi, kas pieņem tīkla savienojumus tikai no lokālā resursdatora vai apstrādā RMI pieprasījumus (Remote Method Invocation, ports 1099), uzbrukumu var veikt, izpildot JavaScript kodu. kad lietotāji savā pārlūkprogrammā atver ļaunprātīgu lapu. Lai šāda uzbrukuma laikā izveidotu savienojumu ar Java lietojumprogrammas tīkla portu, tiek izmantots WebSocket API, kuram atšķirībā no HTTP pieprasījumiem netiek piemēroti vienas izcelsmes ierobežojumi (WebSocket var izmantot arī, lai skenētu tīkla portus lokālajā ierīcē. resursdators, lai noteiktu pieejamos tīkla apdarinātājus).
Interesanti ir arī Google publicētie rezultāti, novērtējot ar Log4j atkarībām saistīto bibliotēku ievainojamību. Saskaņā ar Google datiem, problēma skar 8% no visām Maven Central repozitorijā esošajām pakotnēm. Jo īpaši ievainojamības tika pakļautas 35863 4 Java pakotnēm, kas saistītas ar Log4j, izmantojot tiešu un netiešu atkarību. Tajā pašā laikā Log17j kā tieša pirmā līmeņa atkarība tiek izmantota tikai 83% gadījumu, un 4% ietekmēto pakotņu saistīšana tiek veikta caur starppaketēm, kas ir atkarīgas no Log21j, t.i. otrā un augstāka līmeņa atkarības (12% - otrais līmenis, 14% - trešais, 26% - ceturtais, 6% - piektais, 35863% - sestais). Ievainojamības novēršanas temps joprojām atstāj daudz ko vēlēties, nedēļu pēc ievainojamības noteikšanas no 4620 13 identificētajām pakotnēm līdz šim problēma ir novērsta tikai XNUMX, t.i. par XNUMX%.
Tikmēr ASV Kiberdrošības un infrastruktūras aizsardzības aģentūra izdeva ārkārtas direktīvu, kas pieprasa federālajām aģentūrām identificēt informācijas sistēmas, kuras skārusi Log4j ievainojamība, un instalēt atjauninājumus, kas bloķē problēmu, līdz 23. decembrim. Līdz 28. decembrim organizācijām ir jāatskaitās par savu darbu. Lai vienkāršotu problemātisko sistēmu identificēšanu, ir sagatavots to produktu saraksts, kuriem ir apstiprinātas ievainojamības (sarakstā ir vairāk nekā 23 tūkstoši lietojumprogrammu).
Avots: opennet.ru