Liam Tung Bidragsyter
Liam Tung er en australsk forretningsteknologijournalist som bor noen for mange svenske mil nord for Stockholm for hans smak. Han tok en bachelorgrad i økonomi og kunst (kulturstudier) ved Sydneys Macquarie University, men hacket seg (uten norrønt eller ondsinnet kode for den saks skyld) seg inn i en karriere som enterprise tech-, sikkerhets- og telekommunikasjonsjournalist hos ZDNet Australia.
Full bio 6. januar 2022 | Emne: Sikkerhet
Åpen kildekode-programvare er overalt nå, men Log4j-feilen som påvirker Java-bedriftsapplikasjoner er en påminnelse om hva som kan gå galt i den kompliserte moderne programvareforsyningskjeden.
Utfordringen med Log4j-feilen (også kjent som Log4Shell). ) er ikke bare at administratorer trenger å korrigere feilen – som fikk en “kritisk” vurdering på 10 av 10 – men at IT-folk ikke enkelt kan oppdage om et produkt eller system er påvirket av sårbarheten i komponenten.
Google har beregnet at omtrent 17 000 Java-pakker i Maven Central-depotet – det viktigste Java-pakkelageret – ble funnet å inneholde det sårbare log4j-core-biblioteket som en direkte eller transitiv avhengighet.
Og nå har sikkerhetsfirmaet JFrog funnet mer ved å identifisere flere pakker som inneholder Log4j-sårbarheten som ikke vil bli oppdaget gjennom avhengighetsskanning — det vil si pakker som inneholder sårbar Log4j-kode i selve artefakten.
Den fant at direkte inkludering av Log4j-kode i artefakter generelt sett ikke er like vanlig som bruk av Log4j gjennom avhengigheter. Imidlertid legger det fortsatt opp til hundrevis av pakker – rundt 400 – som direkte inkluderer Log4j-kode, noe som åpner disse pakkene for Log4j-sårbarheter.
“I mer enn halvparten av alle tilfeller (~65%) er Log4j-kode inkludert som klasser direkte (dvs. direkte inkludering/skyggelegging), i motsetning til å inkludere komplette Log4j .jar-filer (dvs. fat jar), som typisk er slik det er presentert i resten av tilfellene. Disse tallene indikerer at verktøy som kun leter etter komplette .jar-filer vil gå glipp av de fleste tilfellene der Log4j er inkludert direkte,” heter det.
Feilen er en påminnelse om hvorfor Microsoft og Google pløyer dollar inn i prosjekter som styrker sikkerheten til programvareprosjekter med åpen kildekode, som er ryggraden i dagens internettinfrastruktur. Tidligere forskning viser at de aller fleste programvarefeil finnes i programvarebiblioteker eller avhengigheter.
Alvorlighetsgraden av feilen betyr at administratorer kan bli godt betjent ved å undersøke alle Java-applikasjoner som kan inneholde Log4j-kode. Microsoft har gitt ut skanneverktøy for å oppdage sårbare Windows- og Linux-systemer, applikasjoner og enheter, og JFrog tilbyr ett alternativ til.
JFrog understreker at skanningen når tilleggskoden i stedet for bare det faktum at en versjon av programvarebiblioteket er til stede.
“Grunnen til at skanning av hele avhengighetslisten kan gå glipp av forekomster av inkludert Log4j-kode er fordi avhengigheter kun spesifiserer eksterne pakker som er nødvendige for å bygge eller kjøre gjeldende artefakt. Hvis den sårbare koden settes inn direkte i kodebasen, er det ikke en avhengighet. Derfor , for mer presis gjenkjenning av sårbar Log4j-kode, må vi inspisere selve koden,” bemerker selskapet i et blogginnlegg.
Undersøkelsen fremhever hvor sårbare dagens IT-systemer er for angrep på programvareforsyningskjeden.
Betydningen av programmeringsspråket Java kan ikke undervurderes. Det er fortsatt et av verdens mest brukte språk og er det beste språket for bedrifter, og inkluderer i sine økosystemprosjekter som Microsofts implementering av OpenJDK. Microsoft bruker Java i Azure, SQL Server, Yammer, Minecraft og LinkedIn.
Sikkerhet
De største datainnbruddene, hackingene i 2021 Copycat og kjepphackere vil være forbannelsen av forsyningskjedesikkerhet i 2022 Sikkerhet vil være prioritet #1 for Linux og åpen kildekode-utviklere i år De 5 beste VPN-tjenestene i 2022 Security TV | Databehandling | CXO | Datasentre