I maj måned opstod et sikkerhedshul i open source DevOps softwaren Salt, som kompromitterede en lang række servere verden over. Mange servere blev sat til at mine bitcoins, men hackere kunne lige så vel have udsat virksomhederne for Ransomware eller totale wipes af databaser.
Da sikkerhedshullet relaterede til den mest centrale server i Salt-teknologien, nemlig Salt Master serveren, gav sikkerhedshullet effektivt adgang til root access på alle servere (kaldet minions i Salt) konfigureret af Salt.
I forlængelse af dette bragte Version2 en artikel med overskriften 'Open source blottede sikkerhedshul i tusindvis af servere', som indikerer at open source software skulle være mere usikkert end proprietært software. Netop denne opfattelse møder vi med jævne mellemrum i vores arbejde med open source software hos Magenta.
Seneste eksempel på dette kommer til udtryk hos danske sundhedsmyndigheder, trods anbefalinger fra EU-kommissionens eHealth-netværk, som skitseret i en anden nylig artikel bragt af version2.
Opfattelsen bunder som regel i idéen om, at adgang til kildekode skulle gøre et produkt nemmere at hacke. Hackerangreb baseres dog sjældent på kendskab til kildekode eller systemer, men på en omgåelse af systemets almindelige protokoller, f.eks. gennem buffer overflows.
Adgang til kildekoden kan måske nok afsløre de mest iøjnefaldende og trivielle sikkerhedshuller, men kun hvis de faktisk findes - og kun hvis resten af infrastrukturen ikke er sikret ordentligt. Åben kildekode styrker mulighederne for at løse sikkerhedshuller proaktivt, og gør dermed også sikkerhedshuller hurtigere at fikse.
I stedet for et lukket udviklingsteam har man et globalt community på flere tusinde mennesker, der proaktivt vedligeholder softwaren og holder øje mod potentielle farer. I stedet for at have et eksternt sikkerhedsbureau til at foretage vurderingen, kan man lade de tusindvis af dygtige
udviklere, der skal benytte softwaren have kritiske øjne på. Det ene udelukker i øvrigt ikke det andet.
Eksemplet med sikkerhedshullet i Salt i maj måned var ikke kritisk, fordi Salt er open source software, men fordi det var en helt central del af infrastrukturen hos de virksomheder der benytter Salt.
Version2’s artikel om forløbet påpeger helt korrekt at »da Salt er open source-software, var patchen nemlig spækket med oplysninger om problemet.« I dette tilfælde benyttede hackere informationer fra patchen som udgangspunkt for at bryde ind i systemet, men havde hacket været udviklet på baggrund af en reverse engineered patch til proprietær software, var sikkerhedshullet formentlig fløjet helt under radaren hos de mange kunder, der burde opgradere hurtigst muligt.
Der er mange forskellige måder at udgive patches til open source software, fx ved at release en patch som en binær fil og først efter nogle uger udgive kildekoden til den. SaltStack, virksomheden bag Salt, er nok blevet en hel del klogere på, hvordan man bør håndtere kritiske sikkerhedshuller efter denne incident, men de fejltrin, de begik, kunne de ligeså vel have begået, hvis deres software havde været proprietær.
Hos Magenta har vi drevet open source virksomhed i 21 år og udviklet alt fra websider til store infrastrukturprojekter som open source. På samme måde drives vores egen infrastruktur af open source projekter.
Salt er en central del af vores implementering af den DevOps filosofi, der sikrer høj kvalitet, hurtige releases og vidensdeling, og derfor var vi også i højeste alarmberedskab, da vi så hvor hårdt en række andre virksomheder var blevet ramt.
Vi kunne se i vores IP-logs, at vores servere også var forsøgt angrebet, men uden held: Vi havde patchet sikkerhedshullet inden de aktive angreb startede, og efter en grundig undersøgelse af evt. yderligere sårbarheder på de relevante servere, konkluderede vi, at vi havde handlet proaktivt og dermed sikret vores infrastruktur i tide.
Naturligvis har det været en sund anledning til at sikre vores infrastruktur endnu bedre.
Det er vigtigt at gøre sig klart, at alt software er sårbart. Proprietær software har også sikkerhedshuller, patches bliver reverse engineered, og infrastruktur kompromitteres.
Uanset om man bruger open source eller proprietære løsninger, skal man sikre sin infrastruktur bag flere lag af sikkerhed. På den måde sikrer man, at selvom ét link går i stykker, så holder kæden. Det skal man gøre uagtet om man baserer sin infrastruktur på open source-løsninger eller på proprietær software.
Tiltag som overvågning, eksterne sikkerhedsscanninger, penetrationstests, netværkssikkerhed og -afgrænsninger er eksempler på tiltag, man kan tage for proaktivt at sikre sin software og infrastruktur. Når man som de danske sundhedsmyndigheder ønsker at indhente følsom data på brugere af app’en Smittestop, så er det helt naturligt at koden skal være tilgængelig som open source.
At sende app’en gennem et sikkerhedstjek giver ikke brugerne af app’en en forståelse for, hvordan deres data håndteres. Det giver ikke civilsamfundet indsigt i, hvilke mekanismer der rører sig under overfladen. Og hvis det eksterne sikkerhedstjek viser, at app’en er fuldkommen sikker, hvad er så egentlig risikoen ved at gøre koden tilgængelig som open source?
Hvilke kanaler bruger I til at holde øje med / få nyheder om sårbarheder?
Kunne være fedt at høre, hvad folk bruger af kanaler! Synes det er lang tid siden, jeg har set en snak om, hvorfra folk henter sådanne nyheder. Fx: https://linuxsecurity.com/ https://thehackernews.com/search/label/Linux%20Vulnerability
Men man skal omvedt også passer på man ikke bare blindt acceptere open source og gå ud fra at koden ikke kan være inficeret med skadelig kode eller have sikkerhedshuller bare fordi "source-koden er jo offentlig tilgængelig".
1: For det første kan du ikke regne med at nogen rent faktisk kigger source-koden igennem
2: Hvis du ikke selv kompilere dine binaries ud fra denne offentlige source-code, så kan man overhovedet ikke være sikker på at selvsamme course-code er brugt til de færdig-kompileret binaries de fleste vælge at bruge/downloade. En smart ondsindet bandit frigiver en CLEAN source-code, men kompilere de frigivet binaries med ondsidet kode.
Så igen som altid, skal man vurdere udgiveren af softwaren om det er én man har tillid til, uanset om det er close- eller open-source (og glemt alt om anti-virus software)
Man kan endda postulere at der er større risiko for at open-source er mere inficeret vs. proprietær software med henvisning til "no free lunch" Det har dog heldigvis ikke vist sig at være tilfældet i prakis indtil videre, hvor der stik mod reglen, netop er masser af free lunch :-P
Det kan nævnes at blandt andet GitHub er så flinke at scanne open source projekter (der hostes på GitHub) efter kendte sårbarheder. Det fanger naturligvis ikke alle fejl, men en det kræver en god slat arbejde at køre de samme analyser på sin kildekode, hvis den kun ligger i en lokal GitLab eller, gud forbyde, i en privat Dropbox.
Man kan betale sig til samme hjælp i private GitHub repos, men ved nogen om det er muligt at give GitHub adgang til at lave de samme analyser på ens private repositorier ad andre veje? Fx. via en deploykey til BitBucket?
Der findes en del af den slags produkter, ex Rapid7 og Snyk — faktisk kommer GutHubs sikkerhedsscanner fra et opkøb af en af disse. Jeg har bare glemt hvilken :-)
Det spørgsmål satte jeg mig for at teste for nogle år siden.
https://www.fsf.org/blogs/community/who-actually-reads-the-code
I betragtning af, at GNU Parallel på ingen måde er sikkerhedssoftware, er jeg faktisk ret imponeret af, at selv afkrogene af koden blev læst på under 2 år.
1: For det første kan du ikke regne med at nogen rent faktisk kigger source-koden igennem
2: Hvis du ikke selv kompilere dine binaries ud fra denne offentlige source-code, så kan man overhovedet ikke være sikker på at selvsamme course-code er brugt til de færdig-kompileret binaries de fleste vælge at bruge/downloade. En smart ondsindet bandit frigiver en CLEAN source-code, men kompilere de frigivet binaries med ondsidet kode.
Det er med meget stor personlig risiko at skulle gøre sådan noget. En af fordelene ved Open source er at, sårbarheder der er placeret med vijle, kan spores til den enkelte udvikler der har committed. Et project der accepterer en maintainer med dårlige hensigter vil hurtigt få et dårligt rygte. For et closed source project vil sådan noget sjældent blive offentliggjort både på grund af risikoen for projektet men også af privatlivs hensyn. I et lukket projekt kan udvikleren, der med vilje har placeret sårbarheder, være beskyttet af injurie lovgivning og kan derfor plædere for uvidenhed. Et open source project der udgiver binære filer, som ikke svarer til kildekoden, vil fremover være afsløret i et uhørt underslæb (da det nemt kan spores i fremtiden). Det er en risiko som intet open source projekt kan leve med. Slet ikke et projekt der er drevet af folk med dårlig hensigter.
Men der er intet i vejen for en russer opretter et projekt med ondsindet kode, evt. kun i den binary fil, under et falsk navn.
Lad os bare tage 7zip? Det er sikkert installeret på millioner of computere, og hvor mange har selv kompileret ? Hvem kender Igor Pavlov? Det ville være den perfekte scam fra Putin og Co, Håber det ikke, så har jeg selv et problem, men det er vanskelige at være sikker,
Jeg taler ikke imod open-source, der er bare ikke blåstempling i sig selv, som nogen måske kan ha' tilbøjelighed til at tro.
Jeg taler ikke imod open-source, der er bare ikke blåstempling i sig selv, som nogen måske kan ha' tilbøjelighed til at tro.
Nu har vi så ikke talt om hvilken præcis nuance af blå stemplingen foretages med...
Om software A er bedre end software B er en meget konkret vurdering og den kan falde ud begge veje.
I lang tid var Eagle (i den grad closed source) bedre en KiCAD, nu ser det ud til at stå lige eller måske en smule fordel til KiCAD (jeg er ikke printudlægningsspecialist!)
Men om Closed Source er værre eller "bedre" (eller som i blogindlægget, mere "sikkert") end Open Source er et forkert spørgsmål at stille, på samme måde som "hvad er højest, Runde tårn eller et tordenskrald?"
Closed Source er "Take it or leave it", alt hvad man ved er "what it says on the tin" og hvad eventuelle andre brugere er villige til og må sige om produktet og leverandøren for deres licensaftaler.
Open Source tillader os at åbne motorhjælmen og kigge på undervognen.
Det er den eneste førsteordens forskel der er.
Om man så synes om det man ser i FOSS, er et helt andet spørgsmål.
Der er FOSS software som jeg har gået i en stor bue udenom, efter at have kigget på kildekteksten, f.eks OpenSSL og Perl.
Der er FOSS software jeg har downloadet og læst igennem, fordi det var skrevet af programmører der var bedre end jeg som jeg kunne lære noget af, f.eks PostFix og Tcl.
Man kan håbe, og håbet er lysegrønt som mange skimmelsvampe, at folk der ved andre kan læse deres kildetekst gør sig mere umage, men det er ikke en teori der er blevet underbygget af nogen data jeg har set.
En af fordelene ved Open source er at, sårbarheder der er placeret med vijle, kan spores til den enkelte udvikler der har committed. Et project der accepterer en maintainer med dårlige hensigter vil hurtigt få et dårligt rygte.
Idéen er at holde sourcekoden clean, og kun plante bagdør i binary. Det kan gøres på måder der er jævnt svære at spore, og kan affejes med "byggeserveren blev hacket".
Idéen er at holde sourcekoden clean, og kun plante bagdør i binary. Det kan gøres på måder der er jævnt svære at spore, og kan affejes med "byggeserveren blev hacket".
Det må jeg jo medgive. Men problemet lader i højere grad til at have noget at gøre med conceptet automatiseret udrulning end med conceptet open source.
2: Hvis du ikke selv kompilere dine binaries ud fra denne offentlige source-code,
For en 15 års tid siden brugte jeg Gentoo i en periode. Den installerede ingen binaries, men hentede kildekoden og compilede den. På det tidspunkt tog det 24 timer at installere LibreOffice (som var klart den største pakke).
Jeg spekulerer på, om det har ændret sig. Hvor lang tid tager det at compile al software til en normal distribution på en normal computer?
Som minimum ville jeg forvente, at distributionerne gjorde dette, så hvis jeg henter en binary til Debian, så forventer jeg, at den bruger den offentlige source (evt. med Debian patch), at signaturen på source coden er checket, og at den bliver compilet på Debian's egne maskiner.
Dermed ville man være sikret mod en udvikler, som laver tricket med at offentliggøre en kildekode uden bagdør, men en binary med bagdør.
For en 15 års tid siden brugte jeg Gentoo i en periode. Den installerede ingen binaries, men hentede kildekoden og compilede den. På det tidspunkt tog det 24 timer at installere LibreOffice (som var klart den største pakke).
Du har dog stadig bootstrap binaries, og så er vi tilbage til "Reflections on trusting trust" :-)
Du har dog stadig bootstrap binaries, og så er vi tilbage til "Reflections on trusting trust" :-)
Ja, men så det pludselig ikke en tilfældig udvikler, der kan lave tricket. Så er det begrænset til de, der distribuerer bootstrap binaries (og de, som laver firmwaren og de som laver CPU'en og de som laver harddisk boot chippen og så videre). For mig at se begrænser det voldsomt antallet, der kan lave tricket.
Og som du husker, så var det jo "den ondsindede bandit", vi talte om (og ikke "Reflections on trusting trust"): https://www.version2.dk/blog/open-source-lige-saa-sikkert-proprietaer-so...
