7. April 2024

Softwaresikkerhed i OSS-projekter

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

4. April 2024

Den tyske delstat Schlesvig-Holstein udskifter 30.000 MS Officepakker med LibreOffice

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

2. April 2024

CVE-2024-3094

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

28. Marts 2024

WebAssembly Components

This article in english (Google Translate)

Det er påskeferie, og jeg har ladet sofaen opsluge mig, mens jeg ser teknologi-konferencer. Det er megahyggeligt, når det samtidig regner udenfor. Jeg synes, på det filosofiske plan, at det er fantastisk, man kan sidde på sin sofa, og nørde den slags konferencer fra rundt om i verden - og så kan man “spole”, hvis der er koncepter, man ikke lige fanger.

Hvis du har fulgt bloggen her i noget tid, så ved du nok, at jeg nævner WebAssembly ofte. Jeg er totalt fan af det multiplatformsparadigme, som det bringer med sig, og ikke mindst “BYOPL - Bring Your Own Programming Language” … Okay, det akronym fandt jeg selv på. Nu er WASM-specifikationen imidlertid klar til sin næste fase, og her er en video fra WASM I/O ‘24, hvor Ryan Levick præsenterer WebAssembly Components.

Link: Ryans egen Youtube kanal om Rust.

27. Marts 2024

Programmering i Swift på Linux, 1. del

Link: English autotranslation by Google Translate

Programmeringssproget Swift er født dybt nede i Apples kælder på 1 Inifinte Loop i Cupertino, CA. Swift virker aldeles glimrende på Linux, og jeg kan personligt godt lide programmeringssproget, fordi det er let og swift at kode i … (cue til dåselatter). Det er let at følge flowet i ens programmer, og er man vant til C-lignende sprog, så vil man givetvis hurtigt føle sig hjemme.

Med libadwaita-bindings til GNOME, så kan du opbygge dine layouts i noget, der ligner SwiftUI på Linux. Jeg har lyst til at øse SwiftUI og Androids Jetpack Compose udover alt, for efter mere end 20 år med HTML-markup, så opdager man, hvor godt deklarativ kode går i spænd med et layoutsystem.

Jeg har testet version 5.10 som findes her:
https://www.swift.org/download/#releases

Swift v5.10 menes at være den sidste store version, inden version 6, som kommer til at bringe flere større ændringer med sig.

Filen, du downloader virker stor og skræmmende, når du pakker den ud. Det er, fordi det er Swift-compileren og hele det bagvedliggende miljø, du får med i pakken. Du kan smide de udpakkede filer hvorsomhelst, bare du opdaterer din path. Jeg bruger f.eks konsekvent /home/simon/sdk til compilere og libraries, der ikke installerer sig selv i /usr/local eller /opt for så slipper jeg for at slås med mapperettigheder.

For at finde ud af, hvilken tarball du skal bruge, kan du skrive

lsb_release -a

som vil liste de saftige detaljer omkring dit operativsystem. Jeg kører Ubuntu 22.04.4 LTS, så jeg downloader tar-filen, der passer dertil.

Download filen, og udpak den et sted i dit $HOME-directory.

Dernæst skal du tilføje Swift til din path i $HOME/.bashrc - læg mærke til at jeg skriver en absolut sti til Swifts-bin mappe, det gør jeg som helgardering i det tilfælde, at $HOME-variablen ikke skulle være tilstede.

export PATH="/home/simon/sdk/swift5/usr/bin":$PATH

Til sidst skriver du:

source ~/.bashrc

for at gøre de seneste .bashrc-ændringer tilgængelige for den aktive terminal
… og herefter burde du kunne skrive swift i terminalen og få et svar ;-)

Vil du starte et nyt projekt kan du skrive

mkdir <dit projekt>
cd <dit projekt> 
swift package init --type executable

Du kan køre programmet med

swift run <dit valgte projektnavn>

Skal du finde packages, kan du med fordel besøge Swift Package Index. Det vil fremgå af pakkernes infosider, om de understøtter Linux.

Mange understøtter udelukkende Apple-økosystemet, men de fleste low-level libraries understøtter Linux, så det er et plus. Som et lille cowboy-trick kan du skrive f.eks ‘platform:linux’ i søgefunktionen, og få vist Linux-understøttede packages. Til min store overraskelse er web-frameworket Vapor Linux-venligt.

Men.. Det var det for nu! Nu er du klar til del 2, som jeg skriver hurtigst muligt :)