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

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.

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.

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

Sådan som jeg læser beskrivelsen svarer det mere eller mindre til

printf(str);

printf("%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?

SDLC

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).

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.

Det gælder faktisk også log4j, i hvert fald det med de 3 udviklere.

Jeg brugte faktisk nogle timer på at kigge på koden for år tilbage. Dengang så den fin ud. Men jeg spottede naturligvis ikke jndi problemet ... (eller gjorde jeg og gemte det i min hacker toolbox i 15 år? :-) ).

Libraries og applicationer der har 3 udviklere og hvor ingen andre nogensinde ser koden

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.

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 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.

Baseret på hvor bredt fejlen rammer er mit gæt dit forslag ikke er specielt gennemtænkt

Link indeholder liste af systemer som ramt ( den er ikke udtømmende):https://github.com/NCSC-NL/log4shell/tree/main/software

Giver et prej om hvor voldsomt det kan rammer.

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

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.

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.

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

thisisfine.png

...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.

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

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...