Den 17. desember, 2021 i bloggen deres forklarte Google Open Source Insights Team hele situasjonen de observerte angående Apache Log4j-sårbarhet. De beskrev den utbredte sårbarheten og den nåværende fremgangen i å fikse JVM-økosystemet med åpen kildekode. Team delte også sine tanker om hvor lang tid det muligens vil ta før denne sårbarheten er fikset på tvers av hele økosystemet og hvor de skal fokusere videre.
9. desember fikk informasjonssikkerhetsøkosystemet vite om sårbarhetens eksistens som utgjør en stor grad av alvorlighetsgrad og omfattende innvirkning. Titusenvis av programvarepakker (artefakter i Java-økosystemet) og prosjekter bruker et populært loggingsverktøy, log4j som viste seg å ha sårbarhetene diskutert. Som spesialister forklarer disse sårbarhetene, tillate ekstern kjøring av kode ved å utnytte den vanskelige JNDI-oppslagsfunksjonen som er avslørt av loggingsbiblioteket log4j. I mange versjoner av biblioteket eksisterte den utnyttede funksjonen som standard.
Apache Log4j-sårbarheten vil ta en stund å fikse
Ikke lenge siden avslørte log4j-sårbarheter berørte mer enn 35,000 Java-pakker, nummerering til over 8% av Maven Central-depotet. Da depotet var det viktigste Java-pakkelageret, forårsaket det et omfattende resultat for programvareindustrien. Spesialister påpeker det 8% er et enormt resultat for økosystemresultatet, mens gjennomsnittstallet for Maven Central-rådgivningsresultatet går med 2% og medianen mindre enn 0.1%. Selv om de nevnte tallene ikke omslutter alle Java-pakker, for eksempel direkte distribuerte binære filer.
På tidspunktet for postpublisering var nesten fem tusen av de aktuelle gjenstandene rettet. Og over 30,000 gjenstander, mange avhengige av en annen artefakt, venter fortsatt på å bli lappet. Teamet nevner at de regnet en artefakt som løst hvis artefakten hadde minst én versjon påvirket og har gitt ut en større upåvirket stabil versjon (det er i henhold til semantisk versjonering). I tilfellet med log4j anses en artefakt som løst hvis den har blitt oppdatert til 2.16.0 eller har ikke lenger avhengighet av log4j.
To betydelige problemer hindrer reparasjonsprosessen
Selv om situasjonene generelt kan defineres som klare, Spesialistene påpeker to betydelige fikseringsproblemer. Det første målet de definerer er det faktum at mange artefakter er avhengige av log4j indirekte. De av direkte avhengigheter står for ca 7,000 av de berørte gjenstandene. I et slikt tilfelle avhenger alle versjonene av en berørt versjon av log4j-core eller log4j-api, beskrevet i CVE-ene. Den indirekte avhengigheten eller transitive avhengigheten betyr avhengighetene til ens egne avhengigheter.
All denne avhengighetens ansatte skaper betydelige hindringer for å fikse om å se på det med avhengighetskjeder. Her forblir alt ganske klart: Jo dypere sårbarhet faller ned, jo flere trinn bør man gå for å fikse det. I følge teamets avhengighetsgrafer for forbrukere viste histogramresultater store tall. I mer enn 80% av pakkenes sårbarhet er mer enn ett nivå dypt. I de fleste av dem er det fem nivåer ned og i noen ni nivåer ned. Prosessen med å fikse vil kreve å gå først til de dypeste avhengighetene først og alle tre etterpå.
Åpne områder gir muligheten til å velge den sist utgitte versjonen
En annen vanskelighet ligger i valg på økosystemnivå i algoritmen for avhengighetsoppløsning og kravspesifikasjonskonvensjoner. Praksisen skiller seg fra de som npm hvor de rutinemessig spesifiserer åpne områder for avhengighetskrav. Åpne områder gir muligheten til å velge den sist utgitte versjonen som tilfredsstiller avhengighetskrav. Og den trekker deretter inn nye rettelser. Brukere mottar en lappet versjon på neste build etter at oppdateringen er tilgjengelig. Det genererer avhengighetene raskere.
"I Java-økosystemet, det er vanlig praksis å spesifisere "myke" versjonskrav - eksakte versjoner som brukes av oppløsningsalgoritmen hvis ingen annen versjon av samme pakke vises tidligere i avhengighetsgrafen. Å propagere en rettelse krever ofte eksplisitt handling fra vedlikeholderne for å oppdatere avhengighetskravene til en oppdateringsversjon,” Open Source Insights-teamet skrev om dette andre problemet.
Med disse råder teamet åpen kildekode-fellesskapet til å aktivere automatiserte avhengighetsoppdateringer og legge til sikkerhetsreduksjoner. De ga også en liste over 500 berørte pakker med noe av den høyeste transitive bruken. Etter spesialistenes mening vil prioritering av disse pakkene gjøre det lettere å fikse innsatsen og deretter fjerne blokkeringen av flere av fellesskapet. Teamet takket de som vedlikeholder åpen kildekode og forbrukere som har oppgradert sine versjoner av log4j.
På spørsmålet hvor lang tid det ville ta å fikse alt, uttrykte teamet en vag mening. De sier det er vanskelig å vite. Hvis alt er offentlig avslørte kritiske råd som påvirker Maven-pakker, kan prosessen ta en stund. De sier mindre enn halvparten (48%) av artefaktene som en sårbarhet påvirket, er fikset. Men på log4j-fronten ser det ut til å være lovende med ca 13% som er fikset.
