En annan sårbarhet har identifierats i Log4j 2-biblioteket (CVE-2021-45105), som, till skillnad från de två föregående problemen, klassificeras som farligt, men inte kritiskt. Det nya numret låter dig orsaka ett överbelastningsskydd och manifesterar sig i form av loopar och krascher när du bearbetar vissa rader. Sårbarheten åtgärdades i Log4j 2.17-versionen som släpptes för några timmar sedan. Faran med sårbarheten mildras av att problemet bara uppstår på system med Java 8.
Sårbarheten påverkar system som använder kontextuella frågor (Context Lookup), som ${ctx:var}, för att bestämma loggutdataformatet. Log4j-versioner från 2.0-alpha1 till 2.16.0 saknade skydd mot okontrollerad rekursion, vilket gjorde det möjligt för en angripare att manipulera värdet som användes i substitutionen för att orsaka en loop, vilket ledde till utmattning av stackutrymme och en krasch. I synnerhet uppstod problemet när man bytte ut värden som "${${::-${::-$${::-j}}}}".
Dessutom kan det noteras att forskare från Blumira har föreslagit ett alternativ för att attackera sårbara Java-applikationer som inte accepterar externa nätverksförfrågningar, till exempel kan system hos utvecklare eller användare av Java-applikationer attackeras på detta sätt. Kärnan i metoden är att om det finns sårbara Java-processer på användarens system som endast accepterar nätverksanslutningar från den lokala värden, eller bearbetar RMI-förfrågningar (Remote Method Invocation, port 1099), kan attacken utföras genom att JavaScript-kod exekveras när användare öppnar en skadlig sida i sin webbläsare. För att upprätta en anslutning till nätverksporten för en Java-applikation under en sådan attack, används WebSocket API, till vilket, till skillnad från HTTP-förfrågningar, begränsningar av samma ursprung inte tillämpas (WebSocket kan också användas för att skanna nätverksportar på den lokala värd för att fastställa tillgängliga nätverkshanterare).
Av intresse är också resultaten som publicerats av Google för att utvärdera sårbarheten hos bibliotek som är associerade med Log4j-beroenden. Enligt Google påverkar problemet 8 % av alla paket i Maven Central-förvaret. Särskilt 35863 4 Java-paket associerade med Log4j genom direkta och indirekta beroenden utsattes för sårbarheter. Samtidigt används Log17j som ett direkt förstanivåberoende endast i 83 % av fallen, och i 4 % av drabbade paket sker bindningen genom mellanpaket som är beroende av Log21j, d.v.s. missbruk av den andra och högre nivån (12% - andra nivån, 14% - tredje, 26% - fjärde, 6% - femte, 35863% - sjätte). Takten för att åtgärda sårbarheten lämnar fortfarande mycket att önska, en vecka efter att sårbarheten identifierades, av 4620 13 identifierade paket, har problemet hittills åtgärdats i endast XNUMX XNUMX, d.v.s. på XNUMX %.
Samtidigt utfärdade US Cybersecurity and Infrastructure Protection Agency ett nöddirektiv som kräver att federala myndigheter identifierar informationssystem som påverkas av Log4j-sårbarheten och installerar uppdateringar som blockerar problemet senast den 23 december. Senast den 28 december är organisationer skyldiga att rapportera om sitt arbete. För att förenkla identifieringen av problematiska system har en lista över produkter som har bekräftats uppvisa sårbarheter utarbetats (listan innehåller mer än 23 tusen applikationer).
Källa: opennet.ru