Մեկ այլ խոցելիություն է հայտնաբերվել Log4j 2 գրադարանում (CVE-2021-45105), որը, ի տարբերություն նախորդ երկու խնդիրների, դասակարգվում է որպես վտանգավոր, բայց ոչ կրիտիկական: Նոր թողարկումը թույլ է տալիս առաջացնել ծառայության մերժում և դրսևորվում է օղակների և խափանումների տեսքով որոշակի գծեր մշակելիս: Խոցելիությունը շտկվել է մի քանի ժամ առաջ թողարկված Log4j 2.17 թողարկման մեջ: Խոցելիության վտանգը մեղմվում է նրանով, որ խնդիրը հայտնվում է միայն Java 8-ով համակարգերում:
Խոցելիությունը ազդում է համակարգերի վրա, որոնք օգտագործում են համատեքստային հարցումներ (Համատեքստային որոնում), օրինակ՝ ${ctx:var}՝ տեղեկամատյան ելքի ձևաչափը որոշելու համար: 4-alpha2.0-ից մինչև 1 Log2.16.0j տարբերակները չունեին պաշտպանվածություն անվերահսկելի ռեկուրսիայի դեմ, ինչը հարձակվողին թույլ էր տալիս շահարկել փոխարինման մեջ օգտագործվող արժեքը՝ առաջացնելով հանգույց, ինչը կհանգեցնի կույտի տարածքի սպառման և վթարի: Մասնավորապես, խնդիրն առաջացել է այնպիսի արժեքների փոխարինման ժամանակ, ինչպիսին է «${${::-${::-$${::-j}}}}»:
Բացի այդ, կարելի է նշել, որ Blumira-ի հետազոտողները առաջարկել են խոցելի Java հավելվածների վրա հարձակվելու տարբերակ, որոնք չեն ընդունում արտաքին ցանցային հարցումները, օրինակ՝ Java հավելվածների մշակողների կամ օգտագործողների համակարգերը կարող են հարձակվել այս կերպ։ Մեթոդի էությունն այն է, որ եթե օգտագործողի համակարգում կան Java-ի խոցելի գործընթացներ, որոնք ընդունում են ցանցային կապերը միայն տեղական հոսթից կամ մշակում են RMI հարցումները (Remote Method Invocation, port 1099), հարձակումը կարող է իրականացվել JavaScript կոդով։ երբ օգտվողներն իրենց բրաուզերում բացում են վնասակար էջ: Նման հարձակման ժամանակ Java հավելվածի ցանցային պորտին կապ հաստատելու համար օգտագործվում է WebSocket API-ն, որի վրա, ի տարբերություն HTTP հարցումների, նույն ծագման սահմանափակումները չեն կիրառվում (WebSocket-ը կարող է օգտագործվել նաև ցանցի նավահանգիստները սկանավորելու համար: հոսթինգ՝ ցանցի հասանելի մշակողներին որոշելու համար):
Հետաքրքրություն է ներկայացնում նաև Google-ի կողմից Log4j-ի կախվածության հետ կապված գրադարանների խոցելիության գնահատման արդյունքները: Google-ի տվյալներով՝ խնդիրն ազդում է Maven Central պահեստի բոլոր փաթեթների 8%-ի վրա: Մասնավորապես, 35863 Java փաթեթներ, որոնք կապված են Log4j-ի հետ ուղղակի և անուղղակի կախվածությունների միջոցով, ենթարկվել են խոցելիության: Միևնույն ժամանակ, Log4j-ն օգտագործվում է որպես ուղղակի առաջին մակարդակի կախվածություն միայն դեպքերի 17%-ում, իսկ տուժած փաթեթների 83%-ի դեպքում կապումն իրականացվում է Log4j-ից կախված միջանկյալ փաթեթների միջոցով, այսինքն. երկրորդ և ավելի բարձր մակարդակի հակումներ (21% - երկրորդ մակարդակ, 12% - երրորդ, 14% - չորրորդ, 26% - հինգերորդ, 6% - վեցերորդ): Խոցելիության շտկման տեմպերը դեռ շատ ցանկալի բան են թողնում. խոցելիության հայտնաբերումից մեկ շաբաթ անց հայտնաբերված 35863 փաթեթներից խնդիրը մինչ այժմ շտկվել է միայն 4620-ում, այսինքն. 13%-ով։
Միևնույն ժամանակ, ԱՄՆ Կիբերանվտանգության և ենթակառուցվածքների պաշտպանության գործակալությունը արտակարգ հրահանգ է հրապարակել, որով դաշնային գործակալություններից պահանջվում է բացահայտել Log4j խոցելիությունից տուժած տեղեկատվական համակարգերը և տեղադրել թարմացումներ, որոնք արգելափակում են խնդիրը մինչև դեկտեմբերի 23-ը: Մինչեւ դեկտեմբերի 28-ը կազմակերպությունները պարտավոր են հաշվետվություն ներկայացնել իրենց կատարած աշխատանքի մասին: Խնդրահարույց համակարգերի նույնականացումը պարզեցնելու համար պատրաստվել է ապրանքների ցանկ, որոնք հաստատվել են խոցելիության առկայության մասին (ցուցակը ներառում է ավելի քան 23 հազար դիմում):
Source: opennet.ru