Liam Tung Contributor
Liam Tung är en australisk affärsteknikjournalist som bor några för många svenska mil norr om Stockholm för hans smak. Han tog en kandidatexamen i ekonomi och konst (kulturstudier) vid Sydneys Macquarie University, men hackade sig (utan norrön eller skadlig kod för den delen) in i en karriär som företagsteknik-, säkerhets- och telekommunikationsjournalist med ZDNet Australia.
Fullständig bio den 6 januari 2022 | Ämne: Säkerhet
Programvara med öppen källkod finns överallt nu, men Log4j-bristen som påverkar Java-företagsapplikationer är en påminnelse om vad som kan gå fel i den komplicerade moderna mjukvaruförsörjningskedjan.
Utmaningen med Log4j-bristen (även känd som Log4Shell) ) är inte bara att administratörer behöver korrigera felet – som fick ett “kritiskt” betyg på 10 av 10 – utan att IT-folk inte lätt kan upptäcka om en produkt eller ett system påverkas av sårbarheten i komponenten.
Google har beräknat att cirka 17 000 Java-paket i Maven Central-förvaret – det mest betydande Java-paketförrådet – visade sig innehålla det sårbara log4j-core-biblioteket som ett direkt eller transitivt beroende.
Och nu har säkerhetsföretaget JFrog hittat mer genom att identifiera ytterligare paket som innehåller Log4j-sårbarheten som inte skulle upptäckas genom beroendeskanning — det vill säga paket som innehåller sårbar Log4j-kod i själva artefakten.
Den fann att på det hela taget är direkt inkludering av Log4j-kod i artefakter inte lika vanligt som användningen av Log4j genom beroenden. Det lägger dock fortfarande till hundratals paket – cirka 400 – som direkt inkluderar Log4j-kod, vilket öppnar dessa paket för Log4j-sårbarheter.
“I mer än hälften av alla fall (~65%) ingår Log4j-kod som klasser direkt (dvs. direkt inkludering/skuggning), i motsats till att inkludera kompletta Log4j .jar-filer (dvs fat jar), vilket vanligtvis är hur det är presenteras i resten av fallen. Dessa siffror indikerar att verktyg som bara letar efter fullständiga .jar-filer kommer att missa de flesta fall där Log4j ingår direkt”, står det.
Bugen är en påminnelse om varför Microsoft och Google plöjer in pengar i projekt som stärker säkerheten för programvaruprojekt med öppen källkod, som är ryggraden i dagens internetinfrastruktur. Tidigare forskning visar att de allra flesta mjukvarubrister finns i mjukvarubibliotek eller beroenden.
Felets svårighetsgrad innebär att administratörer kan vara väl betjänade genom att undersöka alla Java-applikationer som kan innehålla Log4j-kod. Microsoft har släppt skanningsverktyg för att upptäcka sårbara Windows- och Linux-system, applikationer och enheter, och JFrog erbjuder ytterligare ett alternativ.
JFrog betonar att dess skanning når tilläggskoden snarare än att det bara finns en version av programbiblioteket.
“Anledningen till att genomsökning av den fullständiga beroendelistan kan missa instanser av inkluderad Log4j-kod är för att beroenden endast anger externa paket som behövs för att bygga eller köra den aktuella artefakten. Om den sårbara koden infogas direkt i kodbasen är det inte ett beroende. Därför är det inget beroende. , för mer exakt upptäckt av sårbar Log4j-kod måste vi inspektera själva koden”, noterar företaget i ett blogginlägg.
Undersökningen visar hur sårbara dagens IT-system är för attacker på mjukvaruförsörjningskedjan.
Vikten av programmeringsspråket Java kan inte underskattas. Det är fortfarande ett av världens mest använda språk och är det bästa språket för företag, och inkluderar i sina ekosystemprojekt som Microsofts implementering av OpenJDK. Microsoft använder Java i Azure, SQL Server, Yammer, Minecraft och LinkedIn.
Säkerhet
De största dataintrången, hackarna 2021 Copycat och modehacker kommer att vara förbannelsen av säkerhet i leveranskedjan 2022 Säkerhet kommer att vara prioritet #1 för Linux- och öppen källkodsutvecklare i år De 5 bästa VPN-tjänsterna 2022 Security TV | Datahantering | CXO | Datacenter