Bristande säkerhet i öppna källkod-projekt

Sant, men samtidigt säger ju all erfarenhet att "ja, det går bra så länge man gör rätt" men samtidigt då att folk rent generellt inte konsekvent gör rätt, dvs det går regelbundet åt pipan.
Men för att en mer konkret riskbedömning ska bli vettig måste man ju titta på mer än enbart vilket språk som använts.

Och sedan är ju rapportens fokus på "open source" då snarast baserat på att det var lättare att skriva rapporten med ett sådant fokus. Inte att rapportens faktiska poäng och slutsatser är varken mer eller mindre viktigt/relevant för open source än annat.

En liten detalj i sammanhanget är att saker som OpenSSL och SQLite i 99% av användningen är bibliotek som byggs in i andra produkter.

Medan VSCode och Wordpress inte riktigt hör till den kategorin. Wordpress är ju inte direkt känt för att vara säkert heller.

Om de välanvända C-baserade biblioteken plötsligt skulle ändra implementationsspråk så skulle de program som använder dem direkt få en rejäl mängd problem med sina integrationer till dessa. Det är med andra ord hela ekosystemet som behöver ändra riktning.

OpenSSL och SQLite är licensierade på ett vis så att de enkelt kan byggas in i proprietär mjukvara. Vilket görs i extremt stor utsträckning. Så det hela är inte direkt ett Open Source-problem, utan ett problem för hela mjukvaruindustrin. Det kommer kosta enorma summor och årtionden av tid att vända den skutan.

Men för dem som inte gillar att saker är skrivna i C så är det ju bara att kavla upp ärmarna och börja koda ersättningar i andra språk. Eller kanske se till att det kastas pengar på problemet, i stället för att skriva gnälliga rapporter.

C är för övrigt ett riktigt skitspråk. Det är visserligen, till skillnad från många alternativ, standardiserat. Men standarden lämnar mycket som odefinierat beteende. C++ är väl kvantitativt bättre på den punkten, men lider av samma sak. Standardiseringen och därmed att det finns ett flertal implementationer av kompilatorer (för alla tänkbara arkitekturer) är en stor anledning till att C blivit så stort. Nätverkseffekten av att man kan köra C-kod överallt (inte bara på en x86 ’ed Windows) är enorm.

Säkerhet är komplext vilket även The Cybersecurity and Infrastructure Security Agency (CISA) säger i deras utbildningsmaterial, speciellt när man blandar in driftsäkerhet.

När det gäller öppen vs stängd källkod så kan man argumentera för de olika. Men jag tycker det är helt fel att säga att exakt samma gäller överallt.

Ta linuxkärnan, denna granskas av hur många individer som helst. Forskare på universitet kan på betalt arbetstid få ägna sig att leta säkerhetshål och de får hur mycket beröm som helst när de upptäckter något.

Sedan har vi det där lilla programmet, där det kanske endast finns en enda aktiv utvecklare, några få använder programvaran. Typ ingen alls kommer kolla igenom koden, liksom det är något de får göra på deras egna fritid.
De med onda syften kan dock ägna tid att granska koden...

Ett problem utanför detta men som påverkar valet. Är att vem kör annans ej "väldigt pålitlig företags" programkod idag? Alltså Microsoft, Adobe, Apple litar nog många på. Pelle på internet som har skapat sitt program, ja den vill ingen köra.
Enda chansen för Pelle är att göra koden öppen så folk kan se koden och kompilera sin egen exefil.

Det sista tycker jag är tråkigt att det har blivit så, det förstör en hel del för oss som skulle kunna göra diverse nyttoprogram. Någon säger, ja men skapa en webbtjänst. Jovisst, men då vågar folk inte ladda upp någon data där.
T.ex. en applikation man har skapat för att hitta dubbletter och felaktigheter i xml konfigurationsfiler.

"Minnessäkra språk" hindrar naturligtvis inte alls logiska fel i koden.

Det som har blivit väldigt tydligt under de senare åren är hur stor andel av säkerhetsrelaterade problem som har sin grundorsak i problem som undviks i de "minnessäkra språken". Undviks i detta fall betyder inte att programmet fungerar korrekt, men man får en tydlig indikation (program-krasch med backtrace) istället för ett tyst fel som potentiellt kan utnyttjas som säkerhetshål.

En av de saker som ofta nämns är från Microsoft data

"~70% of the vulnerabilities Microsoft assigns a CVE each year continue to be memory safety issues"

Den siffran skulle gå att i stort sett få ned till 0 % med "minnessäkra språk".

Sen som @KAD, är ju väldigt vanligt i de flesta "minnessäkra språk" att använda existerande bibliotek skrivna i C eller C++. Som exempel är C#/.NET specifikt designat för att göra det otroligt enkelt och effektivt att använda bibliotek som exponerar ett C API.

Vore därför spännande att se hur t.ex. C# står sig mot ett språk som Go på denna punkt. I Go finns också explicit stöd för att använda C-bibliotek, men p.g.a. en av hur huvudfinesserna i Go är designad och hur de interagerar med OS-anrop så är det inte speciellt effektivt att hoppa mellan "Go-världen" och "C-världen".

Det har haft den positiva effekten att väldigt många bibliotek som i de flesta andra språk bara är tunna wrappers kring existerade C-bibliotek, är typiskt helt Go-native i Go. Uppenbara nackdel är att det har krävts en hel del extrajobb att nå dit...

Är någon förvånad? Myndigheter kommer plötsligt med ett önskemål om att alla bör byta språk och en kort tid därefter har många valt att avvakta…

Kan hålla med om att C, givet vad vi lärt oss genom åren, inte har en optimal design. Framförallt inte för dagens krav! Men orsaken till varför det i praktiken är programmeringsvärldens lingua franca kommer mycket av hur bra det trots allt är givet sin historik och ålder.

Hoppades väldigt mycket på Rust, men att använt det en del tror jag tyvärr det nog är för komplext för att någonsin bli lika populärt som C.

Finns massor med direkt lysande idéer i Rust, flera som andra börjar "kopiera". Får se hur det går för Zig som verkar vara betydligt enklare än Rust och där målet väldigt mycket är att skapa ett "modernt" C (specifikt designat som OS/embedded språk).

Av de språk som är någorlunda populära, är det något förutom Rust som inte har undefined/implementation-defined delar i sin specifikation (i de fall det ens finns en specifikation)?

Och även i Rust, där man nog ändå gjort det rätta, får man ibland vara pragmatiskt i form av att "release builds" och "debug builds" kan uppföra sig olika (fast det är definierat att vara så, d.v.s fortfarande inte "undefined behavior").

Ett exempel:

fn add(a: u8, b: u8) -> u8 { a + b }

fn main() {
    let a = 100;
    let b = 200;
    println!("{} + {} = {}", a, b, add(a, b));
}

Detta uppför sig olika i debug och release (skulle kosta för mycket prestanda att ha debug-beteendet i release). Och för att nämna Zig igen, där har man bestämt sig att inte definiera precis varenda fall just då det blir rätt komplext för att hantera ofta rätt irrelevanta fall. Men kan vara så att Rust har rätt här, time-will-tell

Det skrivet: är naturligtvis biased när det kommer till C, spenderade nästan 20 år med språket inom OS-kernels och embedded-utveckling...

Detta måste väl vara ett av Swec’s lågvattenmärken till artikel? Peka ut opensource-projekt som osäkra när det i realiteten sannolikt finns magnituder fler kommersiella och closed source-projekt som bättre hade passat titeln.

Om något så bidrar öppen källkod till ökad säkerhet. Jag tycker mig exempelvis läsa betydligt oftare om säkerhetsproblem i Windows än i Linux…

Jag jobbar i branschen och jag fattar gisten av artikeln, men tycker vinklingen är ganska vidrig.

Flera medier har liknande artikel.
Det är bra att belysa problem med open source som många tror är säkert. Att det är riskabelt att ladda hem program från mindre aktörer är känd och likaså att programvaror som Microsoft Windows inte är buggfria.

Och open source kan bidra till bättre säkerhet, men det blir inte alltid bättre säkerhet.

Säg att du utveckla en driver för kommunikation med en frekvensomvandlare emot ett webbgränssnitt. Du säljer denna driver till några få kunder. Är det då bättre eller sämre säkerhet att du har lagt ut koden öppen? För att det ska bli bättre så krävs liksom att folk ska lägga ner en obetald fritid på att hjälpa dig hitta brister.
Annars har du bara offentliggjort eventuella brister som du kan ha skapat. Det finns hur många exempel på program som helst, där fördelarna med att lägga ut koden kan diskuteras.

*edit*
Min gissning är att många kommersiella iOT produkter för megastora företag är så dåligt kodade så det skulle vara katastrofalt om de la ut källkoden och inte fick hjälp med kodgranskning. Ta den där smarta tvättmaskinen, ja det är knappast något som forskare på universitet kan få så mycket anslag till för att på betalt arbettid leta upp brister i denna.

Hade de varit mer säkra som closed source menar du?

Saken är den att det inte har med open source att göra, alls. Enda anledningen att det nämns är för att det är den delen som faktiskt är synlig. All closed source är per definition ej synlig, så därför har man ingen data om det och då kan det ju inte finnas några problemen där. Det är högklassig logik och ”journalistik”

”Osäkra språk används fortfarande i hög utsträckning av open source-projekt”. Det hade varit en mer rimlig titel. Nu drar man slutsatser som inte går att dra utifrån den faktan som finns. Behöver det ens förklaras?

Om ingen lägger ner tid och gör något bättre så kommer det inte bli bättre, nej det är ganska självklart. Skillnaden är att i ena fallet så finns möjligheten, i andra fallet finns problemen kvar men det finns inte möjlighet för andra att hjälpa till att hitta och fixa dessa.

Security by obscurity har aldrig funkat.

Aaah! Det kanske är det som är tricket, v1.0.0 är nya 0.0.1, det är rätt briljant faktiskt 😎

Det du har där är en lista av kända sårbarheter och topparna är också mjukvara som bygger på öppen källkod. Och varför har man hittat så många sårbarheter? Jo, för källkoden är öppen och många letar fel.

Annars kan jag hålla med tidigare inlägg, titeln på denna artikel är under all kritik. Att man använder språk med manuell minneshantering betyder inte att projektet har "bristande säkerhet". Nu har jag bara läst abstrakt/executive summary, men rapporten påpekar inte heller att FOSS-projekt har bristande säkerhet.