Eftersläpning av paketversioner - en säkerhetsrisk?

Permalänk

Eftersläpning av paketversioner - en säkerhetsrisk?

Har funderat på den eftersläpning som finns från det att ett program uppdateras till det att den officiella repositoryn får denna version. Det fallet jag tänker på är när Firefox uppdaterades från 10.0.1 till 10.0.2 för några månader sedan (https://www.mozilla.org/security/known-vulnerabilities/firefo...). Man rekommenderades att uppdatera omedelbart eftersom det fanns en allvarlig säkerhetsrisk i 10.0.1 som klassades "Critical". När jag så försökte uppdatera Firefox i Fedora 16 som jag körde då så fanns inte 10.0.2 tillgänglig förrän flera dagar senare, möjligen en hel vecka efter release. På en Windows-burk hade detta skett automatiskt eller genom att gå in på "Om Firefox"->"Uppdatera" efter releasen.

Jag tycker man bör prioritera att få ut sådana här uppdateringar inom max ett dygn, finns det distar som gör det snabbare? Någon mer som tycker det är en stor brist idag?

Permalänk
Hedersmedlem

Ett vanligt argument för *nix är just att säkerhetsfixar går ut så snabbt (som du säger: ofta på någon dag, med få undantag åtminstone inom en vecka), så jag kan inte säga att jag tycker det är ett generellt problem. Vissa stora, ändå marknadsledande, andra produkter har en historia av att dröja månader för kritiska säkerhetsbrister, utan att detta för den sakens skull får samhällets infrastruktur att kollapsa.

Ifall distarna hade börjat slänga ut otillräckligt testade patchar till slutanvändare så hade det slutat i förskräckelse snabbt, speciellt som dessa system ofta används på platser med höga krav på stabilitet (inte bara "önskan om" som för en hemanvändare), så att det går en dag eller tre är snarare att föredra. Självklart finns specifika motexempel att finna, men i allmänhet tror jag inte det är en svårförsvarad åsikt. Fler ögon på patcharna leder till högre kvalité.

Man måste ju inte heller använda distributionens paket, så om du anser att hålet i Firefox är tillräckligt farligt för att inte våga använda browsern så kan du installera upstreamversionen så länge. Möjligheten att hålla koll på liknande säkerhetshändelser för de 10 000+ paket ingår i distributioner är ju dock obefintlig på personlig basis, så för bästa resultat så får man helt enkelt lita på att distributionen sköter sig. På samma sätt får man helt enkelt lita på att det eventuella företag som ligger bakom ens produkt sköter sig.

Har man extrema krav på stabilitet så kan man hålla sig till en långsam (med helt nya programvaruversioner, inte säkerhetsfixar) distribution som t ex Debian Stable, där liknande säkerhetshål som i Firefox 10 ofta undviks genom att bara köra väldigt mogna programvaruversioner som kontinuerligt får portade säkerhetsfixar.

Vill man ha en helt säker dator så kan man som första steg sluta använda den . Buggar och hål kommer alltid att finnas, så fort man vill ha någon som helst funktionalitet. Man ska jobba med att minimera risker, men att helt utesluta dem inkräktar för mycket på användningsområdena.

Visa signatur

Nu med kortare användarnamn, men fortfarande bedövande långa inlägg.

Permalänk
Medlem

Det kan ju vara åt andra hållet också, distarna som inte är så snabba på att uppdatera slipper få in nya säkerhetsrisker i de nya versionerna innan de har upptäckts. "Om Firefox -> Uppdatera" låter inte särskilt automatiskt tycker jag, då måste man ju själv aktivt ha koll på alla programvaruuppdateringar och eventuella säkerhetsproblem.

Själv kör jag Arch Linux och har fått känslan att de är snabba på uppdateringar när det kommer nya versioner av paket. Typ 1-2 dagar kanske? Hur kan man veta hur snabba de är egentligen? Jag har mycket sämre koll än de paketansvariga...

Tycker man det är en stor brist får man väl själv vara mer aktiv och påminna de paketansvariga, eller själv bli paketansvarig får ett programvarupaket man vill ha koll på, t.ex. via AUR om man kör Arch Linux. Kan inte direkt klaga på de som själva ställer upp och frivilligt hjälper oss andra med att uppgradera programvarupaket.

Var det inte Debian som hade en allvarlig brist i OpenSSH under lång tid? Något med en medföljande nyckel som inte automatiskt ersattes av en nyskapad nyckel. Det kunde man fixa själv genom att manuellt skapa en ny nyckel men alla gjorde väl inte det.

Permalänk
Hedersmedlem
Skrivet av ronnylov:

Var det inte Debian som hade en allvarlig brist i OpenSSH under lång tid? Något med en medföljande nyckel som inte automatiskt ersattes av en nyskapad nyckel. Det kunde man fixa själv genom att manuellt skapa en ny nyckel men alla gjorde väl inte det.

Det var OpenSSL och inte OpenSSH, men jo, Debian och alla dess derivat (vilket är rätt många). Var ett exempel på "för få ögon" på den patchen (till stor del pga att kommunikationen mellan Debianpakethandhavaren och OpenSSL mer eller mindre inte existerade); två kommenterade rader minskade entropin så pass mycket att brute-force-attacker på nycklar blev möjliga (vilket främst möjliggör man-in-the-middle-attacker och lättare att brute-force:a SSH-åtkomst om "endast nyckel"-inloggning var tillåten).

Det var ju dock inte ett känt säkerhetshål som existerade under lång tid. När det upptäcktes så blev en patch skriven och utrullad inom en dag. Nycklar behövde genereras om, så det ledde till användarkrångel, men hanteringen när väl sårbarheten blev känd var exemplarisk. Det var ingen som försökte mörka och säga att "det är inte så farligt" osv, snarare slogs det upp stort av Debian själva.

Visa signatur

Nu med kortare användarnamn, men fortfarande bedövande långa inlägg.

Permalänk
Medlem
Skrivet av phz:

Det var OpenSSL och inte OpenSSH, men jo, Debian och alla dess derivat (vilket är rätt många). Var ett exempel på "för få ögon" på den patchen (till stor del pga att kommunikationen mellan Debianpakethandhavaren och OpenSSL mer eller mindre inte existerade); två kommenterade rader minskade entropin så pass mycket att brute-force-attacker på nycklar blev möjliga (vilket främst möjliggör man-in-the-middle-attacker och lättare att brute-force:a SSH-åtkomst om "endast nyckel"-inloggning var tillåten).

Det var ju dock inte ett känt säkerhetshål som existerade under lång tid. När det upptäcktes så blev en patch skriven och utrullad inom en dag. Nycklar behövde genereras om, så det ledde till användarkrångel, men hanteringen när väl sårbarheten blev känd var exemplarisk. Det var ingen som försökte mörka och säga att "det är inte så farligt" osv, snarare slogs det upp stort av Debian själva.

Ja så var det. Mindes inte detaljerna omkring det.

Permalänk
Skrivet av phz:

Ifall distarna hade börjat slänga ut otillräckligt testade patchar till slutanvändare så hade det slutat i förskräckelse snabbt, speciellt som dessa system ofta används på platser med höga krav på stabilitet (inte bara "önskan om" som för en hemanvändare), så att det går en dag eller tre är snarare att föredra. Självklart finns specifika motexempel att finna, men i allmänhet tror jag inte det är en svårförsvarad åsikt. Fler ögon på patcharna leder till högre kvalité.

Visst hinner patcharna granskas under en längre tid, helt rätt, men jag tycker att en kritisk säkerhetsbrist ska patchas och distribueras direkt efter avslöjande eftersom nyttan överväger. Det bör finnas en "motorväg" för dessa patchar. Hellre täppa till den gamla säkerhetsbristen och riskera att införa en ny bugg eftersom buggen kan hanteras på vanligt vis. För Windows fungerar det ju på det sättet för Firefox uppdaterar sig självt.

Skrivet av phz:

Vill man ha en helt säker dator så kan man som första steg sluta använda den . Buggar och hål kommer alltid att finnas, så fort man vill ha någon som helst funktionalitet. Man ska jobba med att minimera risker, men att helt utesluta dem inkräktar för mycket på användningsområdena.

Självklart, det är vanliga människor som skriver programmen. Det blir fel ibland. Det jag tycker kan förbättras är att snabba upp just distributionen av säkerhetskritiska patchar.

Skrivet av ronnylov:

"Om Firefox -> Uppdatera" låter inte särskilt automatiskt tycker jag, då måste man ju själv aktivt ha koll på alla programvaruuppdateringar och eventuella säkerhetsproblem.

Mycket riktigt. Jag är rätt säker på att Firefox för Windows idag uppdaterar sig automatiskt dock.

Permalänk
Hedersmedlem
Skrivet av Striktarn:

Visst hinner patcharna granskas under en längre tid, helt rätt, men jag tycker att en kritisk säkerhetsbrist ska patchas och distribueras direkt efter avslöjande eftersom nyttan överväger. Det bör finnas en "motorväg" för dessa patchar. Hellre täppa till den gamla säkerhetsbristen och riskera att införa en ny bugg eftersom buggen kan hanteras på vanligt vis. För Windows fungerar det ju på det sättet för Firefox uppdaterar sig självt.

Men vem ska avgöra om det är "kritiskt" om inte just många ögon? Det går inte att dels säga att man vill ha en process där ändringar som träder i kraft är tillräckligt testade, samtidigt som man ger tillåtelse för att helt gå förbi dessa kontroller "då och då". Tiden ska givetvis vara så kort som möjligt (som sagt: dagar är bättre (och även i högriskfall godtagbart) än månader), men att tumma på kvalité för att minska tider är inte möjligt utan att kompromissa säkerheten i stort.

Skrivet av Striktarn:

Självklart, det är vanliga människor som skriver programmen. Det blir fel ibland. Det jag tycker kan förbättras är att snabba upp just distributionen av säkerhetskritiska patchar.

Återigen, vem ska bestämma vad som är säkerhetskritiskt? Det måste pakethanteraren (personen/gruppen, inte "programmet som sköter pakethanteringen") göra, om man inte vill ge full access till en distributions paketsystem för varenda extern mjukvaruutvecklare. Det vore ett säkerhetshål som heter duga.

Om du litar på Firefoxteamet så mycket att du vill låta dem göra liknande beslut för ditt system så kan du installera versionerna direkt från dem, men distributionen kan inte per automatik gå in och ge dessa rättigheter för alla slutanvändare. Det vore oansvarigt, då de inte kan garantera att de sett över/testat ändringarna innan de satt sin stämpel på det.

Microsoft jobbar med att ha mycket längre ledtider innan fixar rullas ut (de släpper öht bara patchar en viss veckodag). "En vecka" ses som en sorts drömtid i den kontexten.

MSRC senior program manager Steve Adegbite:

Citat:

It's not enough to point the finger at one entity and say "Fix it." Those of us who belong to the security ecosystem must own the problem, and share in the solution.

Samma tänk här: skulle de börja rusha ut fixar så skulle de få mångdubbelt större problem när någon halvbra patch går genom nätet och börjar orsaka oväntade problem.

Långa ledtider är givetvis inte bra i sig, men om de anser att det är vad som krävs för att deras process ska vara tillräckligt säker så får det ju vara så. Världen med öppen källkod (i vilken ju t ex Mozilla ingår) anser dock allmänt att just korta ledtider, inklusive tillräckliga kontroller av patchar, är en av deras stora fördelar. En större studie skulle dock behövas för att säkerställa detta samband kvantitativt, men personligen litar jag starkt på kompetensen hos de som sköter t ex Debianprojektet.

Visa signatur

Nu med kortare användarnamn, men fortfarande bedövande långa inlägg.

Permalänk
Medlem
Skrivet av phz:

Ifall distarna hade börjat slänga ut otillräckligt testade patchar till slutanvändare så hade det slutat i förskräckelse snabbt, speciellt som dessa system ofta används på platser med höga krav på stabilitet (inte bara "önskan om" som för en hemanvändare), så att det går en dag eller tre är snarare att föredra. Självklart finns specifika motexempel att finna, men i allmänhet tror jag inte det är en svårförsvarad åsikt. Fler ögon på patcharna leder till högre kvalité.

Idag började jag bygga lite servrar med RHEL 6 som har support fram till 2020-11-30. I just detta fall är det rätt också troligt att dom kommer köras fram till år 2020... Det enda som kan få oss att uppgradera operativsystemet är om en ny version av applikationen som körs på servern kräver nya mjukvaror som inte finns i RHEL6. Jag skulle aldrig installera en ny major version av något paket och riskera att saker och ting inte fungerar, tom att uppdatera minor-versioner kan kännas lite skrämmande ibland...

Kort sagt är det skillnad på datorer och datorer.