Liam Tung Bidragyder
Liam Tung er en australsk forretningsteknologijournalist, der bor et par for mange svenske mil nord for Stockholm til hans smag. Han tog en bachelorgrad i økonomi og kunst (kulturstudier) ved Sydneys Macquarie University, men hackede sig (uden nordisk eller ondsindet kode for den sags skyld) sig ind i en karriere som enterprise tech-, sikkerheds- og telekommunikationsjournalist hos ZDNet Australia.
Fuld bio den 6. januar 2022 | Emne: Sikkerhed
Open source-software er overalt nu, men Log4j-fejlen, der påvirker Java-virksomhedsapplikationer, er en påmindelse om, hvad der kan gå galt i den komplicerede moderne softwareforsyningskæde.
Udfordringen med Log4j-fejlen (også kendt som Log4Shell) ) er ikke kun, at administratorer skal rette fejlen – som fik en 'kritisk' vurdering på 10 ud af 10 – men at it-folk ikke nemt kan opdage, om et produkt eller system er påvirket af sårbarheden i komponenten.
Google har beregnet, at cirka 17.000 Java-pakker i Maven Central-depotet – det mest betydningsfulde Java-pakkelager – blev fundet at indeholde det sårbare log4j-core-bibliotek som en direkte eller transitiv afhængighed.
Og nu har sikkerhedsfirmaet JFrog fundet mere ved at identificere yderligere pakker, der indeholder Log4j-sårbarheden, som ikke ville blive opdaget gennem afhængighedsscanning – det vil sige pakker, der indeholder sårbar Log4j-kode i selve artefakten.
Den fandt, at overordnet set er direkte inklusion af Log4j-kode i artefakter ikke så almindelig som brugen af Log4j gennem afhængigheder. Det tilføjer dog stadig hundredvis af pakker – omkring 400 – som direkte inkluderer Log4j-kode, hvilket åbner disse pakker for Log4j-sårbarheder.
“I mere end halvdelen af alle tilfælde (~65%) indgår Log4j-kode som klasser direkte (dvs. direkte inklusion/skygge), i modsætning til at inkludere komplette Log4j .jar-filer (dvs. fat jar), hvilket typisk er sådan det er. præsenteret i de resterende tilfælde. Disse tal indikerer, at værktøjer, der kun leder efter komplette .jar-filer, vil gå glip af de fleste tilfælde, hvor Log4j er inkluderet direkte,” står der.
Fejlen er en påmindelse om, hvorfor Microsoft og Google pløjer dollars ind i projekter, der styrker sikkerheden i open source-softwareprojekter, som er rygraden i dagens internetinfrastruktur. Tidligere forskning viser, at langt de fleste softwarefejl findes i softwarebiblioteker eller afhængigheder.
Sværhedsgraden af fejlen betyder, at administratorer kan være godt betjente ved at undersøge alle Java-applikationer, der kan indeholde Log4j-kode. Microsoft har udgivet scanningsværktøjer til at opdage sårbare Windows- og Linux-systemer, applikationer og enheder, og JFrog tilbyder endnu en mulighed.
JFrog understreger, at dets scanning når tilføjelseskoden frem for blot at der findes en version af softwarebiblioteket.
“Grunden til, at scanning af den fulde afhængighedsliste kan gå glip af forekomster af inkluderet Log4j-kode er, fordi afhængigheder kun specificerer eksterne pakker, der er nødvendige for at bygge eller køre den aktuelle artefakt. Hvis den sårbare kode indsættes direkte i kodebasen, er det ikke en afhængighed. , for mere præcis detektion af sårbar Log4j-kode, er vi nødt til at inspicere selve koden,” bemærker virksomheden i et blogindlæg.
Undersøgelsen fremhæver, hvor sårbare nutidens it-systemer er over for angreb på softwareforsyningskæden.
Vigtigheden af programmeringssproget Java kan ikke undervurderes. Det er fortsat et af verdens mest udbredte sprog og er det foretrukne sprog for virksomheder og inkluderer i sine økosystemprojekter som Microsofts implementering af OpenJDK. Microsoft bruger Java i Azure, SQL Server, Yammer, Minecraft og LinkedIn.
Sikkerhed
De største databrud, hacks i 2021 Copycat og fad-hackere vil være forbannelsen af forsyningskædesikkerhed i 2022 Sikkerhed vil være prioritet #1 for Linux- og open source-udviklere i år De 5 bedste VPN-tjenester i 2022 Security TV | Datastyring | CXO | Datacentre