It-folk i panik verden over: Her er, hvad vi ved om Log4Shell

It-folk i panik verden over: Her er, hvad vi ved om Log4Shell
Illustration: Beebright/Bigstock.
Fortolkede strenge i logging-meddelelser står bag det værste sikkerhedshul i lang tid.
15. december 2021 kl. 03:45
errorÆldre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Sikkerhedshullet Log4Shell er en af de værste af slagsen, der har været set i længere tid. Lige nu forsøger angribere over hele verden at udnytte sårbarheden, som har CVE-nummeret CVE-2021-44228 og findes i Java-biblioteket Log4j.

Det blev fundet af sikkerhedsfolk hos den kinesiske cloud-leverandør Alibaba d. 24 november. En rettelse blev udsendt d. 6. december, og hullet blev offentliggjort d. 9.

Log4j er et logging-framework med 20 år på bagen. Det er et frontstykke, eller facade, der gør det muligt at anvende en række forskellige logging-systemer i Java-programmer, samt i andre sprog på JVM-platformen, og Log4j byder også selv på et underlæggende logging-system.

Det giver fleksibilitet i forhold til de forskellige behov, som programmer kan have når der skal skrives meddelelser til en logfil eller en database.

Log4j er et middleware-produkt, som findes i megen Java-baseret software. Derfor kan hullet findes i et stort antal systemer og produkter.

Imødegåelse

Ifølge John Graham-Cumming, som er teknisk chef i sky-firmaet Cloudflare, er der fire måde at imødegå sårbarheden på:

Log ind og få adgang
Du kan læse indholdet ved at logge ind eller oprette dig som ny bruger.
Debatten
Log ind for at deltage i debatten.
settingsDebatindstillinger
20
17. december 2021 kl. 00:31

Exploited blev åbenbart præsenteret på Black Hat allerede i 2016https://twitter.com/th3_protoCOL/status/1469644923028656130?s=20

Her en video med en demo af en gammel version af Minecraft.https://www.youtube.com/watch?v=7qoPDq41xhQMinecraft selv indikerer dog at den først er rettet med 1.18.1 https://help.minecraft.net/hc/en-us/articles/4416199399693-Security-Vulnerability-in-Minecraft-Java-Edition

Måske det ikke er så slemt som man skulle tro. I hvertfald har hackere allerede haft 5 år til at udnytte den.

19
16. december 2021 kl. 16:37

Er der rent faktisk nogen garantier for hvor meget ny code bliver reviewet?

Og det er desværre det, der er dilemmaet.

Der er ingen garantier for grundighed per review eller per linie kode nogen steder.

Hverken i Windows, Linux, iOS, npm, drupal, wordpress, java, php, python, .net, webkit, you name it.

Derfor er stærkste benchmark ved valg af framework historik.

Retrospektivt kan man desuden godt udpege en given bug, som værende et hændeligt uheld eller decideret uhæderligt håndværk. Som eksempelvis moderne offentlige websites, som uauthentikeret tillader opslag på CPR numre fra URL parametre og lignende.

Har de det?

Ja. De platforme jeg er orienteret om, har procedurer for hvad der bliver reviewet, og anmærkning af moduler, som ikke indgår i økosystemets codereviews og sikkerhedsopdateringer.

Således er man i det mindste oplyst, hvis man vælger at benytte et modul, som er uofficielt og dermed ikke reviewet af trediepart.

Virker det? Ja, det fungerer ret godt.

Og især i forhold til alternativet, som er at købe silicium og bage sin chip, OS og applikation fra bunden.

18
16. december 2021 kl. 16:21

Bortset fra at det var med vilje da det giver øget fleksibilitet. Man har bare ikke gennemskuet at det også kunne misbruges.

17
16. december 2021 kl. 16:05

Sådan som jeg læser beskrivelsen svarer det mere eller mindre tilprintf(str);versusprintf("%s",str);

eller den gammelkendte SQL-injection ved streng-concatenering versus prepared statements.

I så fald er fejlen sådan set ikke i log4j, men i programmet som bruger log4j. Er der nogen som har gravet i CVEen og kan af- eller bekræfte?

16
16. december 2021 kl. 12:47

SDLC

https://en.wikipedia.org/wiki/Synchronous_Data_Link_Control

15
16. december 2021 kl. 12:36

Der er ingen der har øjensekunder nok i et helt liv, til at overskue hvad en komplet systemopdatering indeholder.

Det er jeg helt enig i. Derfor ...

Men det er sandt, at man skal vurdere inden man downloader et bibliotek, om det er en kilde man har tillid nok til.

... var det netop ovenstående jeg beskrev.

Jeg medgiver, at udviklerne af atomvåben affyringsoftware skal have højere sikkerhedsmargin. Men alle andre er underlagt markedskræfter og desuden ønsket om den udvikler-livskvalitet, der følger med at udvikle produkter baseret på solide frameworks.

De fleste udviklere har en udtalt mangel på forståelse for hvad deres system kan gøre ved resten af verden. log4j svagheden kan bruges til at komme indenfor døren. Herefter bruger man så andre svagheder til at hoppe videre.

Pointen er at så længe applicationer ikke er sikkerhedsmæssigt skilt ordentligt ad så skal der bare et enkelt dårligt æble i kurven før det kan sprede sig til alle. Derforbør man også stille meget høje krav til alle systemer der er i nærheden af atomvåben affyringssoftware. På samme måde: hvis du har blot et kritisk system på dit netværk og ikke ordentlig opdeling af dit nætværk så skal du stille skærpede krav til alle dine systemer. Og selv hvis du har ordentlig opdeling af netværket så bør man stille skærpede krav ... defence in depth.

Alle udviklere er 100% afhængige af andre frameworks sikkerhed og kvalitet, og alle store økosystemer har over de sidste dekader udviklet procedurer for codereview og håndtering af sikkerhedshændelser.

Har de det? Er der rent faktisk nogen garantier for hvor meget ny code bliver reviewet? Sker det ikke ganske ofte at revieweren har travlt og blot skipper hen over den sidste halvdel? Eller at han bliver træt efter de første 200 linjer (jeg mindes at der er lavet undersøgelser der viser at efter ca. 200 linjer kode så falder antallet af fundne fejl drastisk).

14
16. december 2021 kl. 11:54

Man bør tænke sig godt om, inden man baserer et kritisk system på meget kompleks platform, som måske nok gør det nemt for programmørerne.

Omvendt er det både dumt og umuligt at skrive sine egne standard biblioteker fra bunden.

Men endnu vigtigere så har vi brug for at gøre op med "jeg snupper lige et library fra internettet" kulturen. Hver gang nogen hiver et library ind ad døren skal det vurderes. Hver gang det opdateres skal man vurdere opdateringen.

I Narnia. Der er ingen der har øjensekunder nok i et helt liv, til at overskue hvad en komplet systemopdatering indeholder. Men det er sandt, at man skal vurdere inden man downloader et bibliotek, om det er en kilde man har tillid nok til.

Om det så er Windows rutinemæssige opdateringer, apt update, framework opdateringer af applikationer eller manuelle opdateringer af diverse downloadede libraries.

Jeg medgiver, at udviklerne af atomvåben affyringsoftware skal have højere sikkerhedsmargin. Men alle andre er underlagt markedskræfter og desuden ønsket om den udvikler-livskvalitet, der følger med at udvikle produkter baseret på solide frameworks.

Alle udviklere er 100% afhængige af andre frameworks sikkerhed og kvalitet, og alle store økosystemer har over de sidste dekader udviklet procedurer for codereview og håndtering af sikkerhedshændelser.

Derfor kan man som udvikler kun og alene vurdere på et frameworks eller en leverandørs historik, om det er en platform man ønsker at fortsætte sin tillidsfulde afhængighed af.

Da Oracle uden at blinke tyrede millioner af brugere under bussen ved at installere AskToolbaren bag deres ryg i forbindelse med en Java opdatering, mistede mange tilliden til nogensinde at ville røre ved Java eller Oracle igen, -hvis det kunne undgås.

Men typisk gifter man sig med sit framework, fordi det ikke er økonomisk og tidsmæssigt muligt at omskrive sin applikationspark, som jo faktisk er i drift.

11
16. december 2021 kl. 10:20

Hvad det det med Java at gøre ??? Udover at det vist et have det er sproget bag hullet. Kunne ligger så godt være i c, python og mange andre sprog

Jeg er ikke enig med Erik i hans provokation, men det store problem i dag er at folk henter source code fra internettet uden at vurdere kvaliteten. Eller endnu værre blot henter binaries uden nogensinde at have overvejet hvem der har skrevet koden, hvilke kvalitetskrav der var stillet, hvem der har kompileret koden, hvem der distribuerer binaries, etc. etc. etc. Java er klart den største "synder" fordi økosystemet omkring Java er størst. Det er både det fantastiske ved Java og det mest problematiske.

Et af de største sikkerhedsproblemer i dag er at folk kører koden de end ikke vidste eksisterede i deres browser (i form af JavaScript). Alt hvad de gør er at klikke sig ind på et website og derefter sker download af kode og eksekvering helt automatisk. Samme browser kører på en maskine der har bunker af vigtig information, adgang til andre vigtige services, etc. Beskyttelsesmuren mellem internettets garbage code og kritisk kode på computeren er papirstynd.

På samme måde henter udviklere megabytes af kode fra internettet uden at overveje kvaliteten. Samme kode ender med at køre på kritiske systemer der igen har adgang til kritiske systemer og data. Grundlæggende er det varianter af samme problemstilling.

Log4j hullet er et kæmpe problem og det skal fikses. Men log4j har givetvis haft 1000 gange mere code-review (organiseret eller ad-hoc) i forhold til det meste kode på nettet. Der er ingen grund til at tro at der ikke ligger værre ting og roder derude. Libraries og applicationer der har 3 udviklere og hvor ingen andre nogensinde ser koden. Ikke fordi den er closed source men blot fordi ingen har interessen.

Vi har brug for segregering af vores netværk. Log4j hullet ville være langt mindre problematisk hvis de fleste servere ikke kunne connecte til internettet. Men endnu vigtigere så har vi brug for at gøre op med "jeg snupper lige et library fra internettet" kulturen. Hver gang nogen hiver et library ind ad døren skal det vurderes. Hver gang det opdateres skal man vurdere opdateringen. Og så er vi nødt til at få struktureret reviews af open source software sådan at vi bedre ved hvad vi kan forvente. Sådan at jeg fx. ved hvor mange der har reviewet log4j koden. Closed source er en helt anden problematik som vi tager en anden dag.

Det vil ikke løse alle problemer. Men med en række andre tiltag vil det skubbe os i den rigtige retning.

10
15. december 2021 kl. 13:30

Hvad det det med Java at gøre ??? Udover at det vist et have det er sproget bag hullet. Kunne ligger så godt være i c, python og mange andre sprog

9
15. december 2021 kl. 13:00

Jeg ved godt det var en provokation. Jeg mente det ikke helt bogstaveligt.

Når man hælder tonsvis af ukendte kode ind i et system, så må man også være forberedt på problemer. Man bør tænke sig godt om, inden man baserer et kritisk system på meget kompleks platform, som måske nok gør det nemt for programmørerne.

7
15. december 2021 kl. 11:46

Fyr all JAVA-freaks og lad dem gå til hånde på hospitalerne.

6
15. december 2021 kl. 11:15

Panik opstår hvor der er usikkerhed og uklarhed

Jeg kunne tydeligt forestille mig en ikke teknisk CxO finde det uklart, hvad sårbarheden går ud på og have det uklart om det er noget der er i deres teknologi-stak.

Jeg kunne også forestille mig, at det ikke er alle IT leverandører/afdelinger, som har 100% styr på deres tredjepartsafhængigheder og have krystalklare procedurer for at opgradere og efterfølgende teste at systemerne stadig virker. Især hvis man ikke har brugt tid på at snakke om Secure Development Lifecycle (SDL) eller Software Development Lifecycle (SDLC).

Det sammenholdt med nedenstående, synes jeg ikke det er utænkeligt at der har været panik rundt omkring - jeg har dog samme beretning som dig. Ingen panik.

Bemærk i øvrigt at rigtigt mange ting leveres med Log4j v.1.x selv om den er jf. Apache EOL.

5
15. december 2021 kl. 11:02

Panik eller ej. V2 skal i det mindste have point for at fremme denne information i modsætning til CW, som af uransagelige grunde gemmer disse vigtige informationer bag deres betalingsvæg.

Hvis rubrikkens "panik" skulle vække bare én småslumrende systemadmin et sted, så er det fint med mig.

4
15. december 2021 kl. 10:01

Bemærk i øvrigt at rigtigt mange ting leveres med Log4j v.1.x selv om den er jf. Apache EOL.

thisisfine.png

3
15. december 2021 kl. 09:40

...hos Apache er anbefalingen nu at opgradere til 2.16.

Bemærk i øvrigt at rigtigt mange ting leveres med Log4j v.1.x selv om den er jf. Apache EOL.

2
15. december 2021 kl. 09:15

De alvorlige sikkerhedshuller er dem som vi ikke har opdaget endnu!

1
15. december 2021 kl. 08:00

Boulevardpressen har ikke levet forgæves...

Jeg formoder at stort set alle læsere på version2.dk har fulgt Log4Shell, og at en god del af os sidder i roller hvor det også har været et emne til behandling i arbejdtiden. Jeg har hverken set eller hørt om panik nogen steder. En resigneret sukken og en del hårdt arbejde, men ingen panik.

Panik opstår hvor der er usikkerhed og uklarhed, og denne sårbarhed har ikke haft nogen af delene med sig. Vi ved alle sammen at den her type sårbarheder kommer med jævne mellemrum, og vi ved alle sammen at de ikke går væk af at man løber forvirret rundt og panikker.

Min personlige tese er at panikken i virkeligheden findes blandt journalister der skal finde på en tilpas click-baity overskrift...