Debians frågor och svar om säkerhet

Jag tog emot en DSA via debian-security-announce, hur kan jag uppgradera de sårbara paketen?
Signaturen på era bulletiner gick inte igenom verifieringen ordentligt!
Hur hanteras säkerhet i Debian?
Varför håller ni på med en gammal version av det där paketet?
Versionsnumret för ett paket tyder på att jag fortfarande kör en sårbar version!
Jag har tagit emot en bulletin, men det verkar saknas paket för en processorarkitektur.
Hur hanteras säkerheten för unstable (utvecklingsutgåvan)?
Hur hanteras säkerheten för testing (uttestningsutgåvan)?
Hur hanteras säkerhet för contrib, non-free och non-free-firmware?
Bulletinen säger att den instabila utgåvan rättats i version 1.2.3-1, men unstable har 1.2.5-1, vad menas med det?
Varför finns det inte några officiella speglar av security.debian.org?
Jag har sett DSA 100 och DSA 102, var har DSA 101 tagit vägen?
Hur når jag säkerhetsgruppen?
Det verkar som jag upptäckt ett säkerhetsproblem, vad skall jag göra nu?
Vad skall jag göra om jag har säkerhetsproblem i ett av mina paket?
Jag försökte hämta ett paket som listas i en av säkerhetsbulletinerna, men jag får felmeddelandet filen kunde inte hittas.
Jag har en rättelse, kan jag sända den direkt till security.debian.org?
Jag har en felrättelse, kan jag sända in till proposed-updates istället?
Jag är rätt säker på att mina paket är okej, hur sänder jag in dem?
Hur kan jag hjälpa till med säkerheten?
Varför finns proposed-updates?
Hur är säkerhetsgruppen uppbyggd?
Hur länge tillhandahålls säkerhetsuppdateringar?
Hur kan jag säkerställa paketens integritet?
Vad gör jag om ett annat paket går sönder efter en säkerhetsuppdatering?
Vad är en CVE-identifierare?
Tilldelar Debian en DSA för varje CVE-id?
Kan Debian tilldela CVE-identifierare?
Har Debian en policy för avslöjande av sårbarheter?
Vårt verktyg för sårbarhetshantering har visat att följande säkerhetsproblem är öppna (lista på CVEer med olika CVSS-poäng). När kommer dessa att fixas?
Vad betyder local (remote)?

F: Jag tog emot en DSA via debian-security-announce, hur kan jag uppgradera de sårbara paketen?

S: Så som DSA-mailet säger, bör du uppgradera paketen som påverkas av tillkännagivna sårbarheter. Du kan göra detta genom att helt enkelt uppgradera alla paket (efter att du har uppdaterat listan på tillgängliga paket mha apt-get update) i ditt system med apt-get upgrade eller genom att uppgradera endast ett enskilt paket, med apt-get install package.

E-postmeddelandet med tillkännagivandet nämner källkodspaketet där sårbarheten fanns. Därför bör du uppdatera alla binära paket från det källkodspaketet. För att kontrollera vilka binära paket som behöver uppdateras, besök https://packages.debian.org/src:source-package-name och klicka på [show ... binary packages] för distributionen som du uppdaterar.

Det kan även vara nödvändigt att start om en tjänst eller en körande process. Kommandot checkrestart som inkluderas i paketet debian-goodies kan hjälpa dig att avgöra vilka.

F: Signaturen på era bulletiner gick inte igenom verifieringen ordentligt!

S: Detta är med största sannolikhet ett problem på din sida. Sändlistan debian-security-announce har ett filter som bara tillåter meddelanden med en giltig signatur från en av säkerhetsgruppens medlemmar att posta på den.

Med största sannolikhet har någon e-postprogramvara på din sida gjort små ändringar i meddelandet så att signaturen inte är giltig. Se till att din programvara inte utför någon MIME-(av)kodning eller konvertering av blanksteg och tabbtecken.

Kända syndare är fetchmail (med mimedecode-flaggan aktiverad) och formail (endast från procmail 3.14) samt evolution.

F: Hur hanteras säkerhet i Debian?

S: När säkerhetsgruppen först får en indikation om en incident undersöker en eller flera medlemmar den och ser hur det påverkar den stabila utgåvan av Debian (dvs. om den är sårbar eller inte). Om vårt system är sårbart arbetar vi med en rättelse för problemet. Ansvarige för paketet kontaktas också, om denne inte redan själv har kontaktat säkerhetsgruppen. Slutligen testas rättelsen och nya paket förbereds, vilka sedan kompileras på alla arkitekturer i den stabila utgåvan och sedan sänds in. När allt detta är gjort publiceras en bulletin.

F: Varför håller ni på med en gammal version av det där paketet?

Den viktigaste riktlinjen att följa när man skall skapa nya paket som rättar säkerhetsproblem är att göra så få ändringar som möjligt. Våra användare och utvecklare är beroende av att en utgåva fungerar på ett givet sätt när den väl har släppts, så alla ändringar vi gör kan resultera i att någons system slutar fungera. Detta gäller speciellt för bibliotek: se till att du aldrig ändrar programmeringsgränssnittet (API) eller binärgränssnittet (ABI), oavsett hur liten ändringen är.

Detta innebär att det inte är en bra idé att gå över på en ny uppströmsversion, utan att de relevanta ändringarna istället måste bakåtanpassas. Oftast är uppströmsförfattarna villiga att hjälpa till om det är nödvändigt, om inte kan Debians säkerhetsgrupp hjälpa till.

I vissa fall är det inte möjligt att bakåtanpassa en säkerhetsrättelse, till exempel när stora mängder källkod måste ändras eller skrivas om. Om det sker kan det vara nödvändigt att gå över till en ny uppströmsversion, men detta måste samordnas med säkerhetsgruppen på förhand.

F: Versionsnumret för ett paket tyder på att jag fortfarande kör en sårbar version!

S: Istället för att uppgradera till en ny utgåva bakåtanpassar vi säkerhetsrättelser till versionen som medföljde den stabila utgåvan. Skälet till att vi gör detta är för att vara säkra att den nya versionen ändrar så lite som möjligt så att saker inte oväntat ändras eller går sönder på grund av säkerhetsrättelsen. Du kan se om du kör en säker version av ett paket genom att se på paketets ändringslogg, eller genom att jämföra dess exakta versionsnummer med den version som beskrivs i Debians säkerhetsbulletin.

F: Jag har tagit emot en bulletin, men det verkar saknas paket för en processorarkitektur.

S: Oftast släpper säkerhetsgruppen en bulletin med uppdaterade paket för alla arkitekturer som Debian stödjer. Vissa arkitekturer är dock långsammare än andra och det kan hända att paket för de flesta arkitekturer är färdiga medan andra ännu saknas. Dessa mindre arkitekturer representerar en mindre del av vår användarbas. Beroende på hur kritiskt problemet är kan vi besluta att släppa bulletinen i förväg. De saknade paketen kommer installeras så snart de blir tillgängliga, men ingen ytterligare information om detta kommer ges. Självklart kommer vi aldrig släppa en bulletin där i386- eller amd64-paket saknas.

F: Hur hanteras säkerheten för unstable (utvecklingsutgåvan)?

S: Säkerheten för unstable hanteras primärt av de paketansvariga och inte av Debians säkerhetsgrupp. Även om säkerhetsgruppen kan ladda upp brådskande rättelser av endast säkerhetsproblem när den paketansvarige verkar vara inaktiv, så är den stabila utgåvan alltid första prioritet. Om du vill ha en säker (och stabil) server så rekommenderas du starkt att hålla dig till den stabila utgåvan.

F: Hur hanteras säkerheten för testing (uttestningsutgåvan)?

S: Säkerheten i testing tjänar på säkerhetsinsatserna som hela projektet utför för unstable. Dock så finns det en migrationsfördröjning på minst två dagar och ibland så kan säkerhetsrättelser hållas av övergångar. Säkerhetsgruppen hjälper till att hålla igång dessa övergångar genom att hålla tillbaka viktiga säkerhetsuppdateringar, men ibland är detta inte möjligt och fördröjningar kan ske. Speciellt i månaderna som följer en stabil utgåva så kan säkerhetsuppdateringarna för uttestningsutgåvan hamna bakom, då många nya versioner laddas upp till den instabila utgåvan. Om du vill ha ett säkert (och stabilt) system så rekommenderas du starkt att hålla dig till den stabila utgåvan.

F: Hur hanteras säkerhet för contrib, non-free och non-free-firmware?

S: Det korta svaret är att den inte hanteras. Contrib, non-free och non-free-firmware är inte officiellt en del av Debiandistributionen och hör inte dit, och stöds därför inte av säkerhetsgruppen. Vissa icke-fria programvaror distribueras utan källkod eller utan licens som gör det möjligt att distribuera ändrade versioner. I de fallen är det inte möjligt att göra några säkerhetsrättelser alls. Om det är möjligt att rätta problemet, och paketansvarige eller någon annan tillhandahåller korrekta uppdaterade paket, kommer säkerhetsgruppen vanligtvis hantera dem och publicera en bulletin.

F: Bulletinen säger att den instabila utgåvan rättats i version 1.2.3-1, men unstable har 1.2.5-1, vad menas med det?

S: Vi försöker ange den första version i den instabila utgåvan där felet är rättat. Ibland har paketansvariga sänt in ännu nyare versioner sedan dess. Jämför versionsnumret i den instabila utgåvan med versionen vi anger, och om den är samma eller högre så bör du vara säker från det här problemet. Om du vill säkerställa detta, kan kontrollera paketets förändringslogg med apt-get changelog paketnamn och söka efter posten som tillkännager rättningen.

F: Varför finns det inte några officiella speglar av security.debian.org?

S: Det finns det faktiskt. Det finns flera officiella speglar, som implementerats som DNS-alias. Målet med security.debian.org är att göra säkerhetsuppdateringar tillgängliga så fort och enkelt som möjligt.

Om vi skulle rekommendera användandet av speglar skulle det ge ytterligare komplexitet som normalt inte behövs och som kan orsaka frustration i de fall de inte är à jour.

F: Jag har sett DSA 100 och DSA 102, var har DSA 101 tagit vägen?

S: Flera distributörer (de flesta av Linux, men även BSD-derivat) samordnar säkerhetsbulletiner för vissa incidenter och kommer överens om specifika tidsscheman så att alla distributörer kan släppa bulletiner samtidigt. Detta bestämdes för att inte diskriminera mot distributörer som behöver mer tid (t.ex då distributören måste sända paket genom långvariga kvalitetsstyrningstester, eller måste stöda flera arkitekturer eller binärdistributioner). Vår egen säkerhetsgrupp skriver bulletiner i förväg, och ibland måste andra säkerhetsproblem hanteras innan den parkerade bulletinen kan släppas, vilket därmed tillfälligtvis kan göra att en eller flera bulletinnummer utelämnas.

F: Hur når jag säkerhetsgruppen?

S: Säkerhetsrelaterad information kan sändas till [email protected] eller [email protected], bägge dessa adresserna läses av säkerhetsgruppen.

Om så önskas kan e-post krypteras med Debians säkerhetskontaktsnyckel (nyckel-id 0x0D59D2B15144766A14D241C66BAF400B05C3E651). För enskilda gruppmedlemmars OpenPGP-nycklar, se nyckelservern keyring.debian.org.

F: Det verkar som jag upptäckt ett säkerhetsproblem, vad skall jag göra nu?

S: Om du får kännedom om ett säkerhetsproblem, antingen i ditt paket eller i någon annans, skall du alltid ta kontakt med säkerhetsgruppen. Om Debians säkerhetsgrupp bekräftar sårbarheten och det är sannolikt att även andra distributioner är sårbara kontaktar de vanligen de som ansvarar för dessa. Om sårbarheten ännu inte är allmänt känd kommer de försöka samordna säkerhetsbulletinerna med de andra distributionerna så att alla större distributioner hålls synkroniserade.

Om sårbarheten redan är allmänt känd, se till att du sänder in en felrapport i Debians felrapporteringsystem och märker det med security.

Om du är Debianutvecklare, se nedan.

F: Vad skall jag göra om jag har säkerhetsproblem i ett av mina paket?

S: Om du får kännedom om ett säkerhetsproblem, antingen i ditt paket eller i någon annans, skall du alltid ta kontakt med säkerhetsgruppen via e-post på [email protected]. De håller reda på oavklarade säkerhetsproblem, hjälper paketansvariga med säkerhetsproblem eller rättar själva problemen, är ansvariga för att sända säkerhetsbulletiner och att underhålla security.debian.org.

Utvecklarreferensen innehåller detaljerad information om vad man skall göra.

Det är speciellt viktigt att du inte sänder in paket till andra distributioner än den instabila utan att det först har blivit godkänt av säkerhetsgruppen, eftersom det kan orsaka frustration och ökande arbetsbörda att förbigå dem.

F: Jag försökte hämta ett paket som listas i en av säkerhetsbulletinerna, men jag får felmeddelandet filen kunde inte hittas.

S: Närhelst en ny felrättelse ersätter ett gammalt paket på security.debian.org är det mycket möjligt att det gamla paketet kommer tas bort när det nya installeras, varför du får detta filen kunde inte hittas-fel. Vi vill inte distribuera paket med kända säkerhetsfel längre än absolut nödvändigt.

Använd paketen från de senaste säkerhetsbulletinerna, vilka distribueras genom sändlistan debian-security-announce. Det bästa är att helt enkelt köra apt-get update innan du uppgraderar paketet.

F: Jag har en rättelse, kan jag sända den direkt till security.debian.org?

S: Nej, det kan du inte. Arkivet på security.debian.org underhålls av säkerhetsgruppen, som godkänner alla paket. Du bör istället sända patchar eller hela källkodspaket till säkerhetsgruppen via [email protected]. De kommer att granskas av säkerhetsgruppen och sedan sändas in, antingen med eller utan ändringar.

Utvecklarreferensen innehåller detaljerad information om vad man skall göra.

F: Jag har en felrättelse, kan jag sända in till proposed-updates istället?

S: Tekniskt sett kan du det, men du bör inte göra det eftersom detta stör ut säkerhetsgruppens arbete. Paket från security.debian.org kommer automatiskt att kopieras till proposed-updates. Om ett paket med samma versionsnummer redan har installerats i arkivet kommer säkerhetsuppdateringen att avvisas av arkivsystemet, vilket får till följd att den stabila versionen inte kommer få in säkerhetsuppdateringen för paketet, såvida inte fel paket i proposed-updates förkastades. Kontakta säkerhetsgruppen och sänd med alla detaljer gällande sårbarheten och bifoga källkodsfilerna (dvs. diff.gz- och dsc-filerna) till ditt brev.

Utvecklarreferensen innehåller detaljerad information om vad man skall göra.

F: Jag är rätt säker på att mina paket är okej, hur sänder jag in dem?

S: Om du är helt säker på att inget gick sönder, att versionsnumret är vettigt (dvs. större än versionen i den stabila utgåvan och mindre än det i uttestnings-/den instabila utgåvan), att paketets beteende inte förändrades trots det motsvarande säkerhetsproblemet, att du kompilerade det mot rätt utgåva (alltså oldstable-security eller stable-security), att paketet innehåller den ursprungliga källkoden om paketet är nytt för security.debian.org, att du kan bekräfta att ändringen mot den senaste versionen är ren och bara ändrar det motsvarande säkerhetsproblemet (kontrollera med interdiff -z och de båda .diff.gz-filerna), att du korrekturläst ändringen åtminstone tre gånger, och att debdiff inte visar några ändringar så kan du sända filerna direkt till incoming-katalogen ftp://ftp.security.upload.debian.org/pub/SecurityUploadQueue direkt på security.debian.org. Sänd dessutom en bekräftelse med alla detaljer och länkar till [email protected].

F: Hur kan jag hjälpa till med säkerheten?

S: Kontrollera alla problem innan du rapporterar dem till [email protected]. Om du kan tillhandahålla patchar snabbar det upp processen. Skicka inte bara vidare brev från bugtraq, eftersom vi redan tar emot dem – men sänd gärna ytterligare information om problem som rapporterats på bugtraq.

Ett bra sätt att komma igång med säkerhetsarbete är att hjälpa till med Debians säkerhetsspårare (instruktioner).

F: Varför finns proposed-updates?

S: Denna katalog består av paket som föreslås komma in i nästa underutgåva av Debians stabila utgåva. Närhelst paket sänds in av en utvecklare för den stabila utgåvan hamnar de i katalogen proposed-updates. Eftersom den stabila utgåvan är menad att vara stabil görs inga automatiska uppdateringar. Säkerhetsgruppen sänder in de rättade paket som avhandlas i bulletinerna till den stabila utgåvan, men de hamnar i proposed-updates först. Med några månaders mellanrum går den ansvarige för den stabila utgåvan genom paketen i proposed-updates och diskuterar huruvida paketen är lämpade för den stabila utgåvan eller inte. Dessa paket samlas till en underutgåva (t.ex 2.2r3 eller 2.2r4). Paket som inte uppfyller kraven kommer troligen nekas och även tas bort från proposed-updates.

Observera att paket som sänds in av paketansvariga (inte av säkerhetsgruppen) till katalogen proposed-updates/ inte stöds av säkerhetsgruppen.

F: Hur är säkerhetsgruppen uppbyggd?

S: Debians säkerhetsgrupp består av flera medlemmar och sekreterare. Säkerhetsgruppen utser själv vilka personer som skall delta i den.

F: Hur länge tillhandahålls säkerhetsuppdateringar?

S: Säkerhetsgruppen kommer att ge stöd till en den stabila utgåvan tre år efter dess utgivning. Det är inte möjligt att ge stöd för tre distributioner, att stödja två samtidigt är redan tillräckligt komplicerat.

F: Hur kan jag säkerställa paketens integritet?

S: Proceduren innefattar kontroll av Release-filens signatur mot den öppna nyckel som används för arkivet. Release-filen innehåller kontrollsummorna för Packages- och Sources-filerna, vilka innehåller kontrollsummor för binär- och källkodspaket. Detaljerade instruktioner för hur man kontrollerar paketens integritet finns i Debian Securing Manual.

F: Vad gör jag om ett annat paket går sönder efter en säkerhetsuppdatering?

S: Först och främst bör du ta reda på varför paketet går sönder och hur det har samband med säkerhetsuppdateringen. Därefter kontaktar du säkerhetsgruppen om det är allvarligt, eller den ansvarige för den stabila utgåvan om det är mindre allvarligt. Vi talar om paket som går sönder efter en säkerhetsuppdatering av andra paket. Om du inte lyckas komma fram till vad det är som händer, men har ett sätt att korrigera problemet, tar du också kontakt med säkerhetsgruppen. Det är dock möjligt att du blir hänvisad till den ansvarige för den stabila utgåvan.

F: Vad är en CVE-identifierare?

S: Projektet Common Vulnerabilities and Exposures tilldelar unika namn som kallas CVE-identifierare till specifika säkerhetssårbarheter, för att göra det lättare att unikt hänvisa till ett specifikt problem. Mer information finns på Wikipedia.

F: Tilldelar Debian en DSA för varje CVE-id?

S: Debians säkerhetsgrupp håller reda på varje CVE-identifierare, kopplar den till det relevanta Debian-paketet och bedömer dess effekter i ett Debian-sammanhang - endast det faktum att ett problem har tilldelats en CVE-identifierare behöver inte betyda att problemet är ett allvarligt hot mot ett Debiansystem. Denna information spåras i Debians säkerhetsspårare (Debian Security Tracker) och för de problem som anses vara allvarliga så kommer en säkerhetsbulletin (DSA) att ges ut.

Problem med liten påverkan som inte kvalificerar för en DSA kan rättas i nästa utgåva av Debian i en punktutgåva av den aktuella stabila eller gamla stabila utgåvan eller så inkluderas de i en DSA som ges ut för ett allvarligare problem.

F: Kan Debian tilldela CVE-identifierare?

S: Debian är en CVE-numreringsmyndighet (CVE Numbering Authority) och kan tilldela identifierare, men per policy endast till ännu icke avslöjade problem. Om du har ett säkerhetsproblem för mjukvara i Debian som fortfarande inte är avslöjat och vill få en identifierare för detta, kontakta Debians säkerhetsgrupp. För fall där säkerhetsbristen redan är publik så rekommenderar vi proceduren som beskrivs i CVE OpenSource Request HOWTO.

F: Har Debian en policy för avslöjande av sårbarheter?

S: Debian har publicerat en policy för avslöjande av sårbarheter som en del av deras deltagande i CVE-programmet.

F: Vårt verktyg för sårbarhetshantering har visat att följande säkerhetsproblem är öppna (lista på CVEer med olika CVSS-poäng). När kommer dessa att fixas?

S: Debian tillhandahåller inte CVSS-poäng och använder inte CVSS-poäng från externa källor vid undersökning av säkerhetsproblem.

Du kan kontrollera status för varje enstaka CVE-ID i Debians säkerhetsspårare genom att söka med hjälp av ID.

Avdelningen "anteckningar" kommer att innehålla ytterligare information, exempelvis att ett säkerhetsproblem inte kräver en säkerhetsuppdatering i Debian, men kan rättas i en efterföljande punktutgåva.

En lista på paket där en säkerhetsuppdatering är planerad kan hittas i listan dsa-needed.

Om du hittar ett fel i triage-data välkomnas du att rapportera detta. Debians säkerhetsgrupp kommer i allmänhet inte att reagera på förfrågningar efter mer specifik information, utan du bör istället kontakta tillverkaren av ditt verktyg för säkerhetshantering, eftersom det är dom som uppmärksammade dig på ett säkerhetsproblem, och inte Debian.

Övergivna frågor i Debian Säkerhets-FAQ

F: Vad betyder local (remote)?

Fältet Problemtyp i DSA-meddelanden används inte sedan April 2014.
S: Vissa bulletiner beskriver sårbarheter det inte är möjligt att placera i den klassiska uppdelningen mellan lokalt och utifrån nåbart utnyttjande. Vissa sårbarheter kan inte utnyttjas utifrån, t.ex är inte kopplade till en server som lyssnar på en nätverksport. Om de kan utnyttjas genom speciella filer som kan komma via nätverket trots att den sårbara tjänsten inte är permanent ansluten till nätverket skriver vi local (remote).

Dessa sårbarheter ligger någonstans mellan lokala och utifrån nåbara sårbarheter, och handlar ofta om arkiv som kan komma över nätverket, t.ex e-postbilagor eller filer från en hämtningssida.