Steven Vaughan-Nichols Seniorbidragsredaktør
Steven J. Vaughan-Nichols, aka sjvn, har skrevet om teknologi og teknologivirksomhet siden CP/M-80 var banebrytende PC-operativsystem; 300bps var en rask Internett-tilkobling; WordStar var toppmoderne tekstbehandler; og vi likte det.
Full bio Publisert i Linux og åpen kildekode 27. desember 2021 | Emne: Sikkerhet
Linux er overalt. Det er det alle skyene, til og med Microsoft Azure, kjører. Det er det som får alle de 500 av de 500 beste superdatamaskinene til å fungere. Pokker, selv desktop Linux vokser hvis du kan tro Pornhub, som hevder Linux-brukere vokste med 28%, mens Windows-brukere gikk ned med 3%.
Åpen kildekode-programvare vokser også med stormskritt. I følge Gartners 2021 Hype Cycle for Open-Source Software (OSS): «Gjennom 2025 vil mer enn 70 % av bedriftene øke sine IT-utgifter på OSS, sammenlignet med sine nåværende IT-utgifter. I tillegg, innen 2025, programvare som en tjeneste ( SaaS) vil bli den foretrukne forbruksmodellen for OSS på grunn av dens evne til å levere bedre operasjonell enkelhet, sikkerhet og skalerbarhet. % av nye interne applikasjoner vil bli utviklet på en åpen kildekode-database. Samtidig vil 50 % av eksisterende proprietære relasjonsdatabaseforekomster ha blitt konvertert eller blir konvertert til åpen kildekode DBMS.
Jeg kjøper de tallene. Jeg har fulgt Linux og åpen kildekode-programvare siden dag én. Overalt hvor jeg går og alle jeg snakker med erkjenner at paret driver programvareuniverset.
Men med stor kraft følger også stort ansvar som Spider-Man vet. Og, som mange utviklere nylig fant ut da flere sikkerhetssårbarheter med Apache Java-logging åpen kildekode-biblioteket log4j2 ble oppdaget, kommer også stor hodepine.
Log4j2-problemene er så ille som mulig. Etter National Vulnerability Database (NVD)-skalaen er den vurdert til 10.0 CVSSv3, noe som er helt forferdelig.
Det virkelige problemet er ikke så mye med åpen kildekode i seg selv. Det er ingenting magisk med åpen kildekodemetodikk og sikkerhet. Sikkerhetsfeil kan fortsatt skrive inn koden. Linus lov er at gitt nok øyeepler, er alle insekter grunne. Men hvis ikke nok utviklere ser etter, vil sikkerhetssårbarheter fortsatt forbli ubemerket. Som det jeg nå kaller Schneiers lov, “Sikkerhet er en prosess, ikke et produkt,” påpeker konstant årvåkenhet er nødvendig for å sikre all programvare.
Når det er sagt, er den virkelige smerten med log4j hvordan Java skjuler hvilke biblioteker dens kildekode og binærfiler bruker i en rekke Java Archive (JAR) variasjoner. Resultatet? Du bruker kanskje en sårbar versjon av log4j og vet ikke før den er blitt utnyttet.
Som Josh Bressers, Anchores visepresident for sikkerhet nylig forklarte, “En av utfordringene log4j-sårbarheten utgjør er faktisk å finne den. Java-applikasjoner og avhengigheter er vanligvis i et slags pakkeformat som gjør distribusjonen og kjøringen veldig enkel, men det kan gjør det vanskelig å finne ut hva som er inne i disse programvarepakkene.”
Heldigvis finnes det log4j-skannere som kan hjelpe deg med å oppdage defekte log4j-biblioteker i bruk. Men de er ikke perfekte.
Bak log4j rotet er et annet problem, det er “Hvordan vet du hvilke åpen kildekode-komponenter programvaren din bruker?” For eksempel har log4j2 vært i bruk siden 2014. Du kan ikke forvente at noen husker om de brukte den første versjonen i et program du fortsatt bruker i dag.
Svaret er et som åpen kildekode-fellesskapet begynte å ta på alvor de siste årene: Opprettelsen av Software Bills of Material (SBOM). En SBOM staver nøyaktig hvilke programvarebiblioteker, rutiner og annen kode som har blitt brukt i ethvert program. Bevæpnet med dette kan du undersøke hvilke komponentversjoner som brukes i programmet ditt.
Som David A. Wheeler, Linux Foundations direktør for Open Source Supply Chain Security, har forklart, ved å bruke SBOM-er og verifiserte reproduserbare bygg, kan du sørge for at du vet hva som er i programmene dine. På den måten, hvis det blir funnet et sikkerhetshull i en komponent, kan du ganske enkelt lappe den i stedet for å søke som en galning etter en eventuell problemkode før du kan fikse den.
“Et reproduserbart bygg,” forklarer Wheeler, er en “som alltid produserer de samme utdataene gitt de samme inputene, slik at byggeresultatene kan verifiseres. En verifisert reproduserbar build er en prosess der uavhengige organisasjoner produserer en build fra kildekoden og kontroller at de bygde resultatene kommer fra den påståtte kildekoden.”
For å gjøre dette, må du og utviklerne dine spore programmene dine i en SBOM ved å bruke Linux Foundations Software Package Data Exchange-format (SPDX). Deretter, for ytterligere å sikre at koden din virkelig er det den hevder å være, må du notarisere og verifisere SBOM-en din med tjenester som Codenotary Community Attestation Service og Tidelift Catalogs.
Alt dette er enkelt å si. Gjør det vanskelig. I 2022 kommer stort sett alle åpen kildekode-utviklere til å bruke mye tid på å sjekke koden for problemer og deretter bygge SPDX-baserte SBOM-er. Brukere som er bekymret for katastrofer av typen Solarwind og log4j sikkerhetsproblemer, vil kreve dette.
Samtidig jobber Linux-utviklere med å sikre operativsystemet ytterligere ved å gjøre Rust Linux sitt andrespråk. Hvorfor? Fordi, i motsetning til C, Linux sitt primære språk, er Rust mye sikrere. Spesifikt er Rust mye tryggere enn C til å håndtere minnefeil.
Som Ryan Levick, en ledende talsmann for skyutviklere fra Microsoft, forklarte: “Rust er fullstendig minnesikker.” Det er en stor avtale, siden, som Linux-kjerneutviklerne Alex Gaynor og Geoffrey Thomas påpekte på Linux Security Summit i 2019, kommer nesten to tredjedeler av Linux-kjernens sikkerhetshull fra minnesikkerhetsproblemer. Og hvor kommer de fra? Iboende problemer med C og C++.
Nå skal Linux skrives om i Rust. I hvert fall ikke dette tiåret, sjekk med meg igjen på 2030-tallet, men mye Linux-drivere og annen kode vil bli skrevet fremover i Rust.
Som Linus Torvalds fortalte meg mens han “på ingen måte “presser” for Rust,” er han “åpen for det med tanke på de lovede fordelene og unngå noen sikkerhetsfeller. Likevel konkluderte han: “Jeg vet også at noen ganger slår ikke løfter ut.”
Vi får se hvordan det hele går. Uansett hvordan detaljene går, en ting vet jeg sikkert. Vi kommer til å se at sikringskoden blir toppproblem for Linux- og åpen kildekode-utviklere i 2022. De har begge blitt for viktige til at det kan gå noen annen vei.
Relaterte historier:
2022-teknologi trendgjennomgang, del én: Åpen kildekode, sky, blokkjedeKodenotar: Notariser og verifiser programvaren din.Rust tar et stort skritt fremover som Linuxs andre offisielle språk Enterprise Software | Security TV | Data Management | CXO | Datasentre