Den 17. december, 2021 i deres blog forklarede Google Open Source Insights Team hele situationen, de observerede vedrørende Apache Log4j-sårbarhed. De beskrev den udbredte sårbarhed og aktuelle fremskridt med at rette op på open source JVM-økosystemet. Team delte også deres tanker om, hvor lang tid det muligvis vil tage for denne sårbarhed at blive rettet på tværs af hele økosystemet, og hvor de skal fokusere næste gang.
Den 9. december lærte informationssikkerhedsøkosystemet om sårbarhedens eksistens, der udgør en stor grad af alvorlighed og udbredt indvirkning. Titusindvis af softwarepakker (artefakter i Java-økosystemet) og projekter bruger et populært logningsværktøj, log4j, der viste sig at have sårbarhederne diskuteret. Som specialister forklarer, giver disse sårbarheder mulighed for fjernudførelse af kode ved at udnytte de forskellige JNDI-opslagsfunktioner, der er blotlagt af logningsbiblioteket log4j. I mange versioner af biblioteket eksisterede den udnyttede funktion som standard.
Apache Log4j sårbarhed vil tage et stykke tid at rette op
Ikke længe siden afslørede log4j sårbarheder rørte mere end 35,000 Java-pakker, nummerering til over 8% af Maven Central-depotet. Da depotet var det mest betydningsfulde Java-pakkelager, forårsagede det et omfattende resultat for softwareindustrien. Det påpeger specialister 8% er et enormt resultat for økosystemresultatet, mens det gennemsnitlige antal for Maven Central-rådgivningsresultatet går med 2% og medianen mindre end 0.1%. Selvom de nævnte tal ikke omslutter alle Java-pakker, for eksempel direkte distribuerede binære filer.
På tidspunktet for postpubliceringen er næsten fem tusinde af de pågældende artefakter blevet rettet. Og over 30,000 artefakter, mange afhængige af en anden artefakt, venter stadig på at blive rettet. Teamet nævner, at de regnede en artefakt som fast, hvis artefakten havde mindst én version påvirket og har udgivet en større upåvirket stabil version (det er ifølge semantisk versionering). I tilfælde af log4j betragtes en artefakt som rettet, hvis den er blevet opdateret til 2.16.0 eller ikke længere er afhængig af log4j.
To væsentlige problemer hindrer rettelsesprocessen
Selvom situationerne generelt kan defineres som klare, specialisterne påpeger to væsentlige fikseringsproblemer. Det første mål, de definerer, er det faktum, at mange artefakter er afhængige af log4j indirekte. De af direkte afhængigheder tegner sig for ca 7,000 af de berørte artefakter. I et sådant tilfælde afhænger enhver af dens versioner af en berørt version af log4j-core eller log4j-api, beskrevet i CVE'erne. Den indirekte afhængighed eller transitive afhængighed betyder afhængighederne af ens egne afhængigheder.
Alt dette afhængighedspersonale skaber betydelige hindringer for at løse, om man skal se på det med afhængighedskæder. Her forbliver alt helt klart: Jo dybere sårbarhed falder ned, jo flere trin skal man gå for at rette det. Ifølge teamets forbrugerafhængighedsgrafer viste histogramresultater store tal. I mere end 80% af pakkernes sårbarhed er mere end et niveau dybt. De fleste af dem er fem niveauer nede og i nogle ni niveauer nede. Processen med at fikse vil kræve først at gå til de dybeste afhængigheder først og alle træer bagefter.
Åbne intervaller giver mulighed for at vælge den senest udgivne version
En anden vanskelighed ligger i valg på økosystemniveau i afhængighedsopløsningsalgoritmen og kravspecifikationskonventioner. Praksisen adskiller sig fra dem som f.eks. npm, hvor de rutinemæssigt angiver åbne intervaller for afhængighedskrav. Åbne intervaller giver mulighed for at vælge den senest udgivne version, der opfylder afhængighedskrav. Og det trækker efterfølgende nye rettelser ind. Brugere modtager en patchet version på den næste build efter tilgængeligheden af patchen. Det genererer afhængighederne hurtigere.
"I Java-økosystemet, det er almindelig praksis at specificere "bløde" versionskrav - nøjagtige versioner, der bruges af opløsningsalgoritmen, hvis ingen anden version af den samme pakke vises tidligere i afhængighedsgrafen. Udbredelse af en rettelse kræver ofte eksplicit handling fra vedligeholdere for at opdatere afhængighedskravene til en patchet version,” Open Source Insights Team skrev om dette andet problem.
Med disse råder Team open source-fællesskabet om at aktivere automatiske afhængighedsopdateringer og tilføje sikkerhedsbegrænsninger. De leverede også en liste over 500 berørte pakker med noget af det højeste transitive forbrug. Efter specialisternes mening vil prioritering af disse pakker lette løsningen og efterfølgende fjerne blokeringen af flere af fællesskabet. Team takkede de open source-vedligeholdere og forbrugere, der har opgraderet deres versioner af log4j.
For spørgsmålet, hvor lang tid det ville tage at rette op på alting, udtrykte teamet en vag mening. De siger, at det er svært at vide. Hvis det hele er offentligt offentliggjorte kritiske råd, der påvirker Maven-pakker, kan processen tage et stykke tid. De siger mindre end halvdelen (48%) af de artefakter, som en sårbarhed påvirkede, er blevet rettet. Men på log4j-fronten ser tingene ud til at være lovende med ca 13% der er blevet rettet.
