Simon Justesen

Webmediet Ars Technica skriver, at det canadiske teleselskab Bell oprindeligt lovede abonnenter på deres Fibe-service, at de kunne lagre en video i 365 dage på deres PVR cloudservice. Det vil de pr. 1. maj (2024) skære ned til 61 dage.

Selvom dette finder sted i Canada, så er det et eksempel på, hvordan en serviceydelse kan ændre vilkår lynhurtigt. Det er ikke usandsynligt at noget lignende også vil ske - eller er sket - i Danmark. Derfor, hvis du er den heldige ejer af en harddiskoptager, så hold endelig fast på den.

–
Serviceøkonomien er det vilde vesten. Jeg prøver indimellem at hive eksempler frem her på bloggen, som jeg finder ude på det store internet. Formålet er, at få dig som læser til at fundere over, om det nu er klogt at digitalisere alting, eller om vi skal holde fast i noget af det gamle. Du kan finde det hele i kategorien “Serviceøkonomien”.

Kildelinks

Ars Technica: Telecom says it’s deleting DVR recordings over 2 months old starting May 1

Open Source-miljøet står for mig som noget smukt, hvor mennesker arbejder sammen på tværs af forskelle. Det er “the world done right”, når det fungerer. Fundamentet for Open Source er samarbejde og tillid til hinanden. Det må ikke svækkes. Nogensinde.

Den skærende kontrast er til OSS, at verden udenfor desværre i mange henseender alt for ofte præges af konflikter, konkurrencementalitet og magtkampe. Konkurrencementaliteten er så indgroet et samfundselement, at vi nogle gange knapt opdager, når vi bliver udsat for den.

Det lykkes - for det meste - projektejerne og bidragsyderne til Open Source Software (OSS) at parkere den slags ude i den virkelige verden, og fokusere på den fælles opgaveløsning. Det nylige Supplychain-angreb på xz-projektet kalder dog på, at der skal hankes op i sikkerheden helt generelt i OSS-projekter. Men hvordan?

I tilfældet med xz-projektet var bagdøren ikke bare et enkeltstående “hit-and-run” commit, men tilsyneladende metodisk orkestreret af en betroet bidragsyder, der havde bidraget til projektet gennem en lang periode.

Hændelsen er forfærdentlig, det er mig ubegribeligt, at nogen aktivt forsøger at destabilisere det gode, tillidsbaserede samarbejde. Men det er et bevis på, at virkeligheden har indhentet Open Source-miljøet. OSS-miljøet må stå sammen, reagere, og vise, at man ikke accepterer folk, der vil underminere frisindet og idylen.

Spørgsmålet er, hvordan man bedst forener frivillig, interessedrevet udvikling med et øget fokus på sikkerhed.

Mange proprietære, closed source projekter indeholder Open Source-komponenter. Netop fordi OSS bruges i så stort omfang, også i lukkede miljøer betyder, at alle burde have et incitament for, at OSS-miljøet kommer styrket ud af det her.

For at blive konkret - hvad er der egentlig af muligheder? Et sted at starte, kunne være at få integreret kodeskanningsværktøjer i sit workflow, også i små og mellemstore projekter. Selvom dit projekt lige nu er et lille hyggeprojekt, så kan den slags hurtigt gribe om sig.

Enter, OWASP Foundation. OWASP er en non-profitorganisation, der arbejder for at højne sikkerheden i OSS-projekter - og de har lavet en fin liste over åbne og closed-source kodescanningsprojekter.

Listen findes her:
https://owasp.org/www-community/Source_Code_Analysis_Tools

“Why do you seek Imperial favor?”.

Åbningssekvensen med Admiral Thrawn og Morgan Elsbeth giver kuldegysninger på den absolut fedeste mulige måde, for det er Lars Mikkelsens ikoniske stemme, du hører.

Spænd sikkerhedsselen, for traileren er måske den mest hæsblæsende Star Wars-trailer til dato. Det bliver et gensyn med mange gamle kendinge. Jeg tror det bliver rigtig fedt, det her, men døm selv:

Det er ikke så lang tid siden, at Version2 kunne berette at de danske kommuners IT-chefer udtrykte bekymring omkring prisudviklingen på Microsoft-software, og “at det vil være en »fuldstændig uoverskuelig udfordring« at skifte leverandør”*

Ja, det er det da, hvis man smider håndklædet i ringen på forhånd. Det rammer alle skatteydere, at man ikke har sørget for tilstækkelig konkurrence på området i 40 år eller mere.

Anderledes fremsynede er de i den nordtyske delstat Schlesvig-Holstein, hvor de har taget arbejdstøjet på, og langsomt, men sikkert begynder at vikle sig fri: Her vil man udskifte Microsoft Office-pakken med LibreOffice (gratis, frit tilgængeligt kode) på 30.000 computere.

Microsoft bidrager selv til Open Source-kodebaser i et kontrolleret omfang, og ejer Github, verdens største kodedelingssite. Det til trods, så har IT-giganten valgt at beholde mange af deres store programpakker og serversoftware som proprietær kode, selvom konkurrenterne ofte går Open Source-vejen.

Det har dog nærmest været glædeståre-fremkaldende at se Microsoft på commit-listen til forskellige dele af Linux-kernel’en. Det ville være utopi i Gates/Ballmer-æraen, hvor man så Linux som en trussel. Virkeligheden er en anden i dag, hvor Microsoft driver cloud-platformen Azure. Et sted, hvor Linux har godt fat. Azure er givetvis også den primære årsag til at Microsoft <3 Linux. Forfriskende at se, at de har valgt integrationsvejen indtil videre.

Forretningsstrategier er ikke statiske

Man skal dog altid have for øje, at virksomheders forretningsstrategier har det med at skifte, alt efter hvem, der sidder for bordenden, eller hvordan markedet skifter. Vidste du f.eks at Apple engang har tilladt kloner af Apple-computere? Det tillod man, indtil Steve Jobs var tilbage som CEO efter sit eventyr med NeXT. Han kunne se at klon-markedet ramte Apple selv på økonomien, og skyndte sig at fjerne muligheden for, at de kunne køre nyeste version af SystemOS (forgængeren til MacOS). Dermed mistede klonerne sit eksistensgrundlag, og Apples økonomi blev forbedret. I dag styrer Apple hele værdikæden og det ses f.eks på dyre hardwarepriser.

Der er ingen, der siger - og det har jeg vist skrevet før - at kommunerne behøver smide Microsoft helt på porten. For vi kommer ikke uden om, at de laver godt software, og folk, der arbejder med det, har opbygget en masse erfaring gennem årene. Men kommunerne og staten skal sætte sig i en position, hvor det er nemmere at forhandle.

Det ville gavne det danske samfunds økonomi og mangfoldigheden på softwareområdet, at man ved, der er alternativer. Den nuværende kurs, hvor kommunerne og staten vælger kontinuerligt at putte sig selv i håndjern er ikke holdbar.

Åben kode, åbne standarder

Åben kode og åbne standarder kan søge for, at det er lettere at skifte leverandør. Er der et fil-format, der ikke kan åbnes i LibreOffice? Fint, lav en kommunal udgave, en såkaldt fork, af LibreOffice. Så kan du sætte folk til at integrere det direkte i koden - enten kommunens egne folk eller virksomheder udefra - og rulle en ny, tilpasset opdatering ud til kollegaerne. Yay! Fleksibilitet. Er filformatet tilstrækkeligt generelt, kan du indsende det til LibreOffices hovedrepository, og måske få det med i næste udgave af LibreOffice. Den fleksibilitet får du aldrig ikke, så længe Microsoft Office er closed-source.

Langsigtet strategi

Kommunerne skal tænke lokalt og langsigtet, hvis de vil have styr over finanserne. Det duer simpelthen ikke, at man indlader sig for meget med produkter, der har en flydende prisstruktur, hvorfor ikke kultivere lokale eller regionale Open Source-miljøer ift. udvikling og support? Jeg ved, hvad du tænker… Du vil vide, om FOSS-produkter er til at stole på. LibreOffice har eksisteret siden 2011, men er en fork af StarOffice og OpenOffice, så grundstammen er endnu ældre = det er klippestabilt og levedygtigt. Tager stat og kommuner selv ejerskab over en LibreOffice-fork, bestemmer man helt selv, hvor længe produktet skal leve.

De virksomheder, der i dag satser 100% på Microsoft-support kunne brede sig ud over flere områder, og og så supporte f.eks LibreOffice eller lign. kontorpakker eller skabe deres egen udviklingsafdeling baseret på Open Source-produkter. Bum, pludselig får den lokale virksomhed lidt mere power, og man kan langsomt få løsnet op for et fastlåst marked.

Uanset, så ville det være fordelagtigt for alle, hvis virksomheder, der dominerer et hvilken som helst marked, mærker noget konkurrence, så der er (endnu) et incitament for at give nogle fordelagtige priser og god, nærværende service.

Kildelinks

Document Foundation: German state moving 30,000 PCs to LibreOffice
Version2: Kommunernes Microsoftudgifter eksploderet
Tech Republic: How Linux took over everything, including Microsoft Azure
OS2 - Offentligt digitaliseringsfællesskab
Wikipedia: Apple II Clones

Link: English autotranslation (Google translate)

Bag overskriftens kryptiske talrække gemmer der sig den sikkerhedsadvisering, der har været genstand for megen omtale, de sidste mange dage. Det viser sig nemlig, at nogen har sneget en bagdør ind i bestemte udgaver af sourcekoden til xz-utils, der findes på mange Unix-varianter (Linux, BSD’erne m.fl.). Bagdøren findes i version 5.6.0 og 5.6.1 - tarball-udgaven, men ikke i selve Git-repository’et (se opslag på Open Wall, link nederst)

Et lumsk angreb

Det er et rigtig nasty supply-chain-attack, fordi det består af to dele. Dels bruges xz i pakkebygningsfasen til at patche funktionsbiblioteket liblzma med ondsindet kode. Men det går skridtet videre… For når liblzma efter patchingen bliver linket sammen med andre softwarepakker, så vil sårbarheden også eksistere i de pakker, der bygges efterfølgende, og som trækker på funktioner fra liblzma.

Ifølge Hackaday, som jeg linker til nedenunder, gik koden som bagdøren udløser specifikt efter at modificere virkningen af funktionen RSA_public_decrypt.

Funktionen RSA_public_decrypt bruges bl.a. til at validere ssh-nøgler, så som Hackaday også nævner, så kunne det for en person med ondsindede intentioner være en mulighed for at gøre OpenSSH’s auth-proces svagere, og dermed nemmere forbigå de normale sikkerhedsprocedurer, når man logger ind på en server via SSH.

Opdaget ved et tilfælde

For open source-miljøet er det en rigtig ærgerlig situation. Først og fremmest godt at det blev opdaget af en årvågen udvikler. Men også en brat opvågning, fordi der måske har været en naivistisk tilgang til kodedeling, ift. til koderevision, ansvarsfordeling og tillid i Open Source-miljøet helt generelt. Særligt med tanke på, hvordan verden udenfor Open Source-miljøet på bedrøvelig vis tager sig ud i disse tider.

Der er endnu ingen, der med 100% sikkerhed ved, om det ondsindede kode er bestilt arbejde af en stat eller en enkelt persons komplot, men uanset hvad resultatet af undersøgelsen bliver, så bør det give det anledning til ændringer i sikkerhedsprocedurene hos de Linux/Unix-distributioner, der hiver pakker ind udefra.

De pakker udgør fundamentet for f.eks en Linux-distribution, som distribueres til millioner af brugere - erhverv og hobbyister - som dagligt bruger Linux på deres computere - servere-, IoT- eller desktopsystemer. Derfor er Linux-distributionernes udgivere også sidste sidste bastion overfor sikkerhedshuller, og bør give pakkerne det sidste tjek inden udgivelse. Det er måske netop nu, at der skal et skævt magisk AI-sovs ind over arbejdsgangene. Det er ikke sikkert, AI kan løse problemet, men det kan udpege problemområder og lette arbejdsbyrden.

Vi kan sagtens blive enige om, at det på papiret er de enkelte upstream-projekter, der selv skal sørge for, at deres kode er testet for sikkerhedshuller og clean. Men det ville forudsætte, at alle er sikkerhedseksperter, og det kan på ingen måde forventes. Det, der mudrer sagen yderligere til her, er jo, at den person der - tilsyneladende - har injiceret malwaren i projektet har været en betroet bidragsyder på xz-projektet i en del år.

Forskellige tilgange til test

Alle projekter har forskellige test-metoder, nogle mere strukturerede og tilbundsgående end andre. Men bottomline er, at pakkerne, der ender ude hos slutbrugerne skal efterprøves bedre. Hvis det betyder, at mængden af nyudviklede funktioner i en distribution bliver færre og at antallet af udgivelser falder, så må det være sådan, det er.

Måske er det på tide at samle kræfterne et formaliseret samarbejde imellem distributionerne, der tester pakker, som kommer ind upstream? De enkelte distributioner kan ikke overkomme den byrde isoleret set. Der er immervæk tusindvls af pakker i f.eks en Linux-distribution, der skal testes, og det - ideelt set - hver gang, der lander en opdatering til en pakke.

Nogle af de community-baserede Linux-distributioners release- og sikkerhedsteams består af få personer, mens det forholder sig anderledes hos de erhvervsrettede. Men selv de har brug for en håndsrækning fra fællesskabet. Om sikkerhedsbristen, der ligger bag CVE-2024-3094 ville blive opdaget nemmere i et sådan samarbejde, må stå hen i det uvisse - men det må alt andet lige give blod på tanden ift. at få skabt bedre systemer, der kan trawle kode igennem for brister - automatiserede såvel som manuelle.

Tornhøj tillid

Min tillid til Open Source-økosystemet er dog ikke svækket - tværtimod. Man kan aldrig undgå sådanne brister, den her var en af de ubehageligt lumske.

Havde det været et operativsystem baseret på proprietær, lukket kode, så kunne sådan en sikkerhedsbrist givetvis få lov at eksistere et stykke tid. Det er og bliver en illusion, at fordi man ikke offentliggør sin kode, så er man bedre sikret. I bedste fald giver det måske arbejdsro.

Det er sket før, at sikkerhedsbrister ikke er blevet patchet tidsnok i closed-source systemer, som Ars Technicas artikel her nævner.

Debatten omkring dette sikkerhedshul afslører også, hvor hårde folk kan være ved hinanden, og vi skal for alt i verden undgå at folk brænder ud. Netop debatkulturen ift. open source og dette sikkerhedsbrud, vil jeg prøve at behandle i et kommende blogindlæg, for det er et studie for sig.

Links

Tråd fra OpenWall
NISTs CVE-beskrivelse med referencer
Hackadays artikel
Low Level Learning: et kig på sagen fra en sikkerhedseksperts perspektiv