Log4Shell-patch indeholder selv sårbarheder: Og hackere udnytter det

16. december 2021 kl. 09:494
Log4Shell-patch indeholder selv sårbarheder: Og hackere udnytter det
Illustration: anatolir/Bigstock.
En patch, der skulle løse Log4Shell-sikkerhedshullet, indeholder selv mindst to sårbarheder, og derfor anbefales det kraftigt at downloade en ny udgave så hurtigt som muligt.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Patch'en 'Log4J 2.15.0' skulle lukke sikkerhedshullet 'Log4Shell', men der er mindst to sårbarheder i den nye patch, og i hvert fald den ene af dem bliver i øjeblikket udnyttet til cyberangreb. Derfor anbefales det at installere den nye version '2.16.0' så hurtigt som muligt.

Det skriver Ars Technica.

Læs også: It-folk i panik verden over: Her er, hvad vi ved om Log4Shell

Såbarhederne, der begge går under CVE-nummeret CVE-2021-45046, gør det blandt andet muligt at udføre såkaldte denial-of-service-angreb, der kan lægge inficerede enheder ned.

Artiklen fortsætter efter annoncen

Men hvad værre er, at en information disclosure-fejl også gør det muligt at downloade data fra inficerede enheder.

»I vores forskning har vi vist, at 2.15.0 under visse omstændigheder stadig tillader eksfiltrering af følsomme data. Vi har videregivet tekniske detaljer om problemet til Apache Foundation, men i mellemtiden anbefaler vi kraftigt, at kunderne opgraderer til 2.16.0 så hurtigt som muligt,« skriver Nathan Sportsman, der er ansat ved it-sikkerhedsfirmaet Praetorian, i et blog-opslag.

Virksomheden har ligeledes lagt en proof-of-concept-video ud, der viser sårbarheden.

4 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
2
17. december 2021 kl. 07:29

Nu er sammenhæng imellem Best practices og virkelighed nogle gange meget langt fra hinanden. Og ideen om at udviklere den dag i dag stadig bruger log4j v. 1,2,17 der har været End of Life siden august 2015 er heller ikke super fed for nogen. Men bevares, det er nemt, lidt ligesom ikke at sanitere input fra felter, browser headers og hvor denne fejl ellers er set misbrugt i flæng.

1
16. december 2021 kl. 22:49

Hvis jeg har forstået det her problem rigtig så er sårbarheden i log4shell kun tilgængelig hvis man har en parameter/userinput der bruges som logger string?

Hvis det er tilfældet synes jeg ærligt ar verdenen går for meget amok. Jeg kan ikke komme i tanke om en case hvor det er god praksis.