1. Maj 2024

Et kig på MS-DOS 1.25 - 4.00

English autotranslation (Google Translate)

Microsoft har for nylig frigivet tidlige udgaver af operativsystemet MS-DOS som Open Source (under MIT-licens). Det giver et spændende indblik i, hvordan man strikkede et operativsystem sammen i start-80′erne.

Der er en heftig omgang maskinkode og lidt C. Det, der slår mig ved første hurtige gennemsyn er, hvordan fil-strukturen i projektet udvikler sig fra v1.0 til v.4.0 og hvordan det - tilsyneladende - kun er relativt lidt i den tidlige kode, der er dokumenteret. Det er ret typisk for solo-programmører eller små teams, fordi man har ret meget styr på, hvad koden gør. Det er også interessant at se, at dynamisk linking gjorde sit indtog allerede i MS-DOS 4. Du kan finde indscannet dokumentation i ‘MSDOS4.0-ozzie’.

En anden interessant detalje er, at koden til MS-DOS 1.25 har Seattle Computer Products (SCP) påskrevet som udvikler i headeren på assembler-filerne. Hvordan er de endt der? Jo - find kaffen og slåbrokken:

Lang historie kort

IBM ville ind på markedet for microcomputere, og var i 1980 i forhandlinger med Digital Research om at købe en Intel 8086-kompatibel udgave af deres operativsystem CP/M. Hvis du aldrig har hørt om Digital Research før, så er det fordi IT-medierne har glemt computerens barndom. Digital Research’ CP/M var alle steder i 70′erne. Faktisk meget lig Microsofts Windows-dominans i dag.

Før CP/M blev operativsystemer typisk skrevet direkte til den computerhardware, de skulle køre på, hvilket betød store kompatiblitetproblemer mellem maskinerne. CP/M udlignede de forskelle med stor succes.

På grund af diverse forviklinger gik handlen mellem IBM og Digital Research dog i vasken, og så henvendte IBM sig istedet til Microsoft. Microsoft havde på daværende tidspunkt intet operativsystem, men så muligheden for en lukrativ handel. Så de henvendte sig til Seattle Computer Products, som lavede en x86-kompatibel klon af CP/M, ved navn 86-DOS. Den købte Microsoft, og gik i gang med at udvikle Microsoft og IBMs fælles 86-DOS variant. Varianten blev omdøbt til IBM PC-DOS.

Hvordan kom MS-DOS så ind i billedet? Jo, Microsoft lavede et snedigt træk: De havde set det opblomstende marked af IBM-kloner, og da IBM havde ikke sikret sig eksklusiv-retten til Microsofts kode, kunne Microsoft uden videre licensere deres egen version - jeps, MS-DOS - til fabrikanterne af IBM-kompatible computerkloner, and the rest is history, som man siger. IBMs PC DOS 5 er iflg. Wikipedia den sidste version, Microsoft arbejdede på, derefter overtog IBM selv udviklingen.

Hvor er koden til f.eks 5.00, 6.22 og 7.0?

Mit gæt er, at man endnu ikke vil udgive den, fordi der stadig er hardware i drift med de versioner, og fordi man mener, der kan være en potentiel sikkerhedsrisiko.

Links

Github: Microsoft MSDOS 1.25-4.00
Wikipedia: MS-DOS
Wikipedia: PC-DOS
Wikipedia: DR-DOS
Wikipedia: 86-DOS

19. April 2024

Hvad mangler FreeBSD… Eller BSD’erne generelt?

Jeg faldt over denne Youtube-video af “Robonuggie”, der ofte beskæftiger sig med FreeBSD-videoer. Selvom jeg primært er Linux-mand, så følger jeg BSD’erne lidt på sidelinien, og har tidligere testet både FreeBSD på server og desktop. Jeg vil så gerne se dem lykkes, for det betyder mere frit valg blandt operativsystemerne til alle.

Men hvor FreeBSD virkelig excellerer på serverfronten, så kniber det på desktopsiden, hvor der mangler driversupport til forskelligt hardware f.eks Wifi7-enheder, hvilket “Robonuggie” også nævner i sin video.

Det er på driversupporten *BSD’erne og Linux differentierer sig fra hinanden. Hvor Linux tillader proprietær binær kode i kernel’en, så er det no-go hos FreeBSD, og det har formentlig den betydning, at større hardwareproducenter vender BSD’erne ryggen, fordi producenterne vil beskytte deres kode og patenter. BSD-folkene må så udvikle deres egen åbne driver ved hjælp af trial-and-error, og den slags tager tid.

Vidste du, at en BSD-licens er mindre restriktiv end GPL-licenserne i forhold til modkrav, hvis du bruger kode fra et GPL-projekt? GPL-licenserne bestemmer bl.a. at afledt kode skal offentliggøres under samme licens, så forbedrer du f.eks kernel’en, så skal du tilbyde forbedringerne upstream. Det lyder måske meget stringent og kedeligt, men det sikrer, at upstream-projektet udvikler sig.

Der mener jeg faktisk at hhv. MIT/BSD-licenserne er for løse - og det påvirker også BSD’ernes “vækst”. Åbne, frie licenser fungerer godt i undervisnings- og forskningsmiljøer, og blandt opensource-mindede individer, men det ses tydeligt at en del kommercielle virksomheder nyder godt af den gratis arbejdskraft uden nødvendigvis at bidrage tilbage til projekterne.

Derfor er der også en lidt, synes jeg, opgivende undertone i Robonuggies video, for det er tydeligt, at FreeBSD og de andre vaianter sakker længere og længere bagud, hvis man ser det hele som en konkurrence, og det er virkelig synd, for det er solide systemer, når de kører.

Fremtiden for FreeBSD?

Jeg har ikke føling med BSD-fællesskabet, så jeg ved ikke hvor aktive de forskellige varianter er. Mit kendskab stammer primært fra nogle måneders serverdrift, og lidt desktop-leg. Derfor skal mine “mavefornemmelser” tages med et gran salt.

Udefra set er det dog ikke første gang, jeg mærker en frustration over manglen på hardwaresupport.

Det er vigtigt at pointere her, at det hverken er *BSD-projekternes fejl, men verden omkring dem, der er skruet forkert sammen. Dele af den kommercielle IT-industri hævder, at man beskytter sin kode for at kunne innovere, men man ynder i virkeligheden for det meste at genopfinde hjulet flere gange og forhaler i virkeligheden fælles udvikling.

BSD-projekterne kan langtfra kaldes for døde eller døende, for de har mange dedikerede loyale støtter indenfor mange områder. Men BSD-projekterne virker umiddelbart isolerede fra hinanden, og derfor kan man også nogle gange se f.eks OpenBSD og NetBSD diske op med bedre driversupport på nogle områder, før samme ændringer lander i FreeBSD, som Robonuggie bemærker i løbet af videoen. Dermed bliver de indbyrdes konkurrenter, hvor de måske burde arbejde mere sammen på de mest vitale områder. Men forks, dvs. nye varianter af et eksisterende projekt oprettes ofte, fordi “forkerne” (hæ…) er uenige i retningen, det oprindelige projekt tager. Så der er givetvis kodesmede, der slet ikke har interesse i, at til at bidrage til det gamle projekt.

Skal BSD’erne det blive en succes på desktop-fronten, så skal man nok forlige sig med, at det aldrig bliver godt som generalist-system, medmindre det lykkes at åbne op for mere generel hardwareunderstøttelse. Og så skal man differentiere sig endnu mere fra Linux, end man gør i dag. Giv mig som “Linux-mand” større incitament for at kigge mod BSD’erne… Challenge. Da jeg brugte hhv. GhostBSD og FreeBSD i en periode, følte jeg mig egentlig godt hjemme, både ports (byg fra sourcekode) og package-systemet (binære, pre-kompilerede pakker) virker solide, jeg savnede bare det miljø, jeg kendte.

Nogle ser f.eks gerne Wayland erstatte X11-displayserveren på BSD’erne, men måske skal skal man gå en helt tredje vej. Der har f.eks været snak om at lave en X12-udgave. Det vil formentlig være en mindre omvæltning end at skulle erstatte det hele med Wayland. Udfordringen er så bare, at det er den vej, store desktop GUI-projekter såsom Gnome og KDE kigger.

Linux’ akilleshæl er helt klart den store fragmentering. Der er 5-7 store distroer og mange små, med mere eller mindre individuelle konfigurationer. Nogle projekter virker mere som reskinning fremfor, at man prøver nye veje. Antallet af nye distributioner, pakkeformater mv. er tårnhøjt og forvirrer nybegyndere. Fleksibiliteten er et fænomenalt salgsargument, men kan også være en hæmsko alt efter perspektiv. Den fragmentering har BSD-projekterne ikke helt (endnu), og der kunne man måske vinde på at standardisere komponenter på tværs af projekterne, så de samlet set hænger bedre sammen end det er tilfældet for Linux-økosystemet.

Jeg ser fordelen i BSD’erne i nicheområderne: Virksomheder kan bruge f.eks FreeBSD som fundament til at skabe sit eget økosystem over tid, ligesom Apple har gjort det med MacOS (Note: MacOS bygger på en anden BSD-variant, DarwinBSD, en NeXTStep-fork… Ikke FreeBSD), og deres egen hardwarestack. Sony Playstation 3s OS var en hybrid mellem FreeBSD og NetBSD, mens PS4s OrbisOS var en fork af FreeBSD 9 iflg. Wikipedia - det er bare nogle få eksempler, hvor man har kunnet bruge BSD’erne som fundament. Jeg er på ingen måde fan af den lukkethed Apple og Sony bragte med deres egne BSD-varianter, men illustrerer blot muligheden for at skabe sit eget findes.

Anyway, hav FreeBSD og de andre projekter i baghovedet, når du skal lege med nye projekter, evt. i en virtuel maskine. De fortjener i den grad mere opmærksomhed end de hidtil har fået.

God weekend :)
/Simon out.

Links

FreeBSD
DarwinBSD
PureDarwin, moderne OpenDarwin fork
BSD Hardware Info

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