FAQ Debian sulla sicurezza

Ho ricevuto un DSA da debian-security-announce, come posso aggiornare i pacchetti vulnerabili?
La firma degli annunci non è correttamente verificata!
Come è gestita la sicurezza in Debian?
Perché perdete tempo con una vecchia versione di quel pacchetto?
La versione del pacchetto indica che io sto utilizzando una versione vulnerabile!
Ho ricevuto un avviso, ma sembra mancare il pacchetto per una certa architettura.
Come è gestita la sicurezza per unstable?
Come è gestita la sicurezza per testing?
Come è gestita la sicurezza per contrib, non-free e non-free-firmware?
L'avviso dice che la soluzione in unstable è nella versione 1.2.3-1, ma unstable ha la 1.2.5-1, cosa succede?
Perché non ci sono mirror ufficiali di security.debian.org?
Ho visto DSA 100 e DSA 102. Dov'è il DSA 101?
Come posso contattare il team sicurezza?
Suppongo di aver trovato un problema di sicurezza, cosa dovrei fare?
Cosa dovrei fare con un problema di sicurezza in uno dei miei pacchetti?
Ho provato a scaricare un pacchetto elencato in uno dei Security Advisor ma ho avuto un errore file not found.
Ho trovato la soluzione ad un problema, posso caricarla su security.debian.org direttamente?
Ho trovato la soluzione ad un problema, posso caricarlo invece su proposed-updates?
Sono sicurissimo che il mio pacchetto va bene, posso caricarlo?
Come posso aiutare?
Qual è lo scopo di proposed-updates?
Come è composto il team della sicurezza?
Per quanto tempo sono assicurati gli aggiornamenti di sicurezza?
Come si può controllare che i pacchetti siano integri?
Cosa fare se un altro pacchetto non funziona dopo un aggiornamento di sicurezza?
Cosa è un identificatore CVE?
Debian emette un DSA per ogni id CVE?
Debian può assegnare identificatori CVE?
Debian ha una policy sulla divulgazione delle vulnerabilità?
Il nostro strumento di gestione delle vulnerabilità ha mostrato che i seguenti punti sono aperti (elenco di CVEs con vari punteggi CVSS). Quando saranno risolti?
Che significa local (remote)?

D: Ho ricevuto un DSA da debian-security-announce, come posso aggiornare i pacchetti vulnerabili?

R: Come indicato nel DSA, è opportuno aggiornare i pacchetti afflitti dalla vulnerabilità. Per farlo è sufficiente aggiornare (dopo aver rinfrescato l'elenco dei pacchetti disponibili con apt-get update) ogni pacchetto installato nel proprio sistema con apt-get upgrade oppure aggiornando un pacchetto in particolare con apt-get install pacchetto.

Nella email con l'annuncio è menzionato il pacchetto sorgente in cui era presente la vulnerabilità. Di conseguenza si dovrebbe aggiornare tutti i pacchetti binari creati da quel pacchetto sorgente. Per verificare quali sono i pacchetti binari da aggiornare visitare https://packages.debian.org/src:nome-pacchetto-sorgente e fare clic su [show ... binary packages] per la distribuzione che si sta aggiornando.

Potrebbe essere necessario riavviare un servizio oppure un processo in esecuzione. Il comando checkrestart contenuto nel pacchetto debian-goodies può essere utile per determinare quali.

D: La firma degli annunci non è correttamente verificata!

R: Molto probabilmente è un problema dal vostro lato. La lista debian-security-announce ha un filtro che accetta solo messaggi con una firma corretta proveniente da un iscritto al team della sicurezza.

È probabile che uno dei programmi utilizzati per la posta abbia cambiato leggermente il messaggio e quindi la firma. Verificate che il vostro programma non tocchi la codifica MIME del messaggio o cambi tab e spazi.

Problemi si sono verificati con fetchmail (con l'opzione mimedecode abilitata), formail (solo la versione di procmail 3.14.) ed evolution.

D: Come è gestita la sicurezza in Debian?

R: Una volta che il team riceve una notifica di un incidente, uno o più membri prendono in carico la segnalazione e valutano l'impatto sulla distribuzione stable di Debian (vale a dire cercano di capire se Debian sia o meno vulnerabile). Se il nostro sistema è vulnerabile allora lavoriamo ad una soluzione che lo risolva. Se non si è attivato da solo allora il manutentore del pacchetto viene contattato. Alla fine la soluzione viene verificata e creato un nuovo pacchetto che viene poi compilato su tutte le architetture stabili e poi caricato sul server. Dopo che tutto ciò è stato fatto, viene pubblicato l'annuncio.

D: Perché perdete tempo con una vecchia versione di quel pacchetto?

La più importante regola quando viene preparato un nuovo pacchetto che risolve un problema di sicurezza è di fare il minimo possibile di cambiamenti. I nostri utenti e gli sviluppatori fanno affidamento su un corretto funzionamento di una versione appena essa viene rilasciata, ed ogni eventuale cambiamento potrebbe creare problemi al sistema di qualcuno. Ciò è vero in particolar modo nel caso di librerie: siate sicuri che non cambieremo mai le Application Program Interface (API) o le Application Binary Interface (ABI), neanche con piccole variazioni.

Questo significa che adottare una nuova versione a monte [NdT: in inglese upstream version: la versione originale (generalmente mantenuta dagli autori) usata per la creazione del pacchetto Debian] non è una buona soluzione, invece andrebbero riportati verso la vecchia i cambiamenti significativi. Di solito i manutentori della versione a monte sono ben disposti ad aiutare, altrimenti il team sicurezza Debian potrebbe farlo al loro posto.

In alcuni casi non è possibile creare una soluzione, per esempio quando grandi quantità di codice sorgente dovrebbero essere modificate o riscritte. In tal caso potrebbe essere necessario migrare verso una nuova versione, ma ciò deve essere preventivamente concordato con il team della sicurezza.

D: La versione del pacchetto indica che io sto utilizzando una versione vulnerabile!

R: Invece di aggiornare il programma all'ultima versione preferiamo riportare solo le modifiche legate al problema sulla vecchia versione. La ragione per la quale facciamo ciò è che vogliamo fare in modo che la soluzione abbia il minore impatto possibile sul resto della distribuzione. Si può verificare se si sta utilizzando una versione sicura controllando il changelog del pacchetto o confrontando il numero completo di versione con quello indicato nel Debian Security Advisory.

D: Ho ricevuto un avviso, ma sembra mancare il pacchetto per una certa architettura.

R: In genere il team sicurezza rilascia un avviso con i pacchetti aggiornati per tutte le architetture supportate da Debian. Tuttavia, alcune di esse sono più lente di altre e può accadere che le compilazioni siano per la maggior parte pronte mentre manchino per altre; tali architetture rappresentano una piccola parte della nostra utenza. A seconda dell'urgenza del problema, si può decidere di pubblicare l'annuncio immediatamente. I pacchetti mancanti saranno aggiunti all'archivio non appena disponibili, ma non verrà pubblicato alcun ulteriore avviso in proposito. Naturalmente non rilasceremo mai un avviso dove non siano presenti i pacchetti per i386 o amd64.

D: Come è gestita la sicurezza per unstable?

R: La sicurezza per unstable è principalmente gestita dai curatori dei pacchetti, non dal Debian Security Team. Nel caso i curatori siano inattivi il team della sicurezza potrebbero inviare delle correzioni high-urgency security-only, in ogni caso il supporto per il rilascio stabile ha sempre la priorità. Se si vuole un server sicuro (e stabile) invitiamo caldamente a utilizzare la versione stable.

D: Come è gestita la sicurezza per testing?

R: La sicurezza per testing beneficia del lavoro fatto dall'intero progetto per unstable; c'è comunque un ritardo che al minimo è di due giorni e alcune volte le correzioni di sicurezza sono bloccate a causa delle transizioni. Il Security Team aiuta a sbloccare le transizioni che tengono fermi delle importanti correzioni per la sicurezza, tuttavia ciò non è sempre possibile e si possono verificare dei ritardi. In particolare nei mesi successivi a un nuovo rilascio stabile, quando in unstable arrivano molte nuove versioni, le correzioni di sicurezza possono avere ritardi. Se si desidera avere un server sicuro (e stabile) invitiamo caldamente ad utilizzare la versione stable.

D: Come è gestita la sicurezza per contrib, non-free e non-free-firmware?

R: La risposta breve è: non lo è. Contrib, non-free e non-free-firmware non sono parti ufficiali della distribuzione Debian e per questo non sono supportate dal team sicurezza. Alcuni pacchetti non-free sono distribuiti senza sorgenti o senza una licenza che permetta la distribuzione di versioni modificate. E in quei casi sono completamente impossibili i fix di sicurezza. Se c'è la possibilità di risolvere il problema e il manutentore del pacchetto o qualcun altro fornisce un pacchetto correttamente aggiornato, allora di solito il team sicurezza lo processa e rilascia un advisory.

D: L'avviso dice che la soluzione in unstable è nella versione 1.2.3-1, ma unstable ha la 1.2.5-1, cosa succede?

R: Cerchiamo di indicare la prima versione in unstable che risolve il problema. Qualche volta il maintainer ha nel frattempo caricato nuove versioni. Si confronti la versione in unstable con quella da noi indicata. Se è la stessa o superiore si dovrebbe essere al sicuro dalla vulnerabilità. Per essere sicuri controllare il changelog del pacchetto con apt-get changelog nome-pacchetto e cercare una voce che annuncia la correzione.

D: Perché non ci sono mirror ufficiali di security.debian.org?

R: Ci sono. Esistono alcuni mirror ufficiali, realizzati mediante alias DNS. Lo scopo di security.debian.org è di rendere disponibili gli aggiornamenti nella maniera più semplice e rapida possibile.

Incoraggiare l'uso di mirror non ufficiali potrebbe aggiungere un'inutile maggiore complessità che potrebbe causare frustrazione se i mirror non fossero tenuti aggiornati.

D: Ho visto DSA 100 e DSA 102. Dov'è il DSA 101?

R: Alcuni venditori (la maggior parte di GNU/Linux, ma anche di derivati BSD) coordinano a volte i Security Advisor stabilendo delle date affinché tutti i venditori possano rilasciare l'annuncio contemporaneamente. Questo è stato fatto per non discriminare i venditori che richiedono più tempo (in altre parole quando il venditore necessita di far passare il pacchetto attraverso lunghi test di QA o deve supportare diverse architetture o distribuzioni binarie). Anche il nostro team prepara gli annunci in anticipo. Ogni tanto altri problemi legati alla sicurezza sono stati gestiti prima che uscisse l'annuncio ufficiale (e quindi, che fosse assegnato il numero), per questo motivo capita che i numeri non siano tutti consecutivi.

D: Come posso contattare il team sicurezza?

R: Informazioni inerenti alla sicurezza possono essere inviate a [email protected] o a [email protected], lette ambedue dai membri del team sicurezza.

Chi vuole può crittare l'e-mail con la chiave Debian Security Contact (key ID 0x0D59D2B15144766A14D241C66BAF400B05C3E651). Per le chiavi OpenPGP personali di membri del team members, si usi il keyserver keyring.debian.org.

D: Suppongo di aver trovato un problema di sicurezza, cosa dovrei fare?

R: Se si scopre qualche problema di sicurezza, sia in un proprio pacchetto che in quello di altre persone, contattare il team sicurezza. Se il team sicurezza Debian conferma la vulnerabilità e se esiste la possibilità che anche altri venditori siano vulnerabili, il team di solito contatta anche gli altri venditori. Se la vulnerabilità non è ancora pubblica il team cerca di coordinare i security advisory con gli altri venditori, per mantenere le maggiori distribuzioni sincronizzate.

Se la vulnerabilità è già pubblicamente nota, assicurarsi di aprire un bug report nel Debian BTS, con il tag security.

Se si è un manutentore Debian, leggere sotto.

D: Cosa dovrei fare con un problema di sicurezza in uno dei miei pacchetti?

R: Se si scopre un problema di sicurezza in un pacchetto, sia proprio che di altre persone, contattare il team sicurezza tramite posta elettronica all'indirizzo [email protected]. I membri del team tengono traccia dei problemi di sicurezza irrisolti, possono aiutare i manutentori con problemi di sicurezza o risolverli essi stessi, sono responsabili dell'emissione dei security advisory e curano security.debian.org.

La Developer's Reference contiene le istruzioni complete su cosa fare.

È particolarmente importante che non si carichi verso qualsiasi distribuzione che non sia unstable senza un accordo preventivo con il team sicurezza, perché bypassarlo causerebbe confusione e maggior lavoro.

D: Ho provato a scaricare un pacchetto elencato in uno dei Security Advisor ma ho avuto un errore file not found.

R: Tutte le volte che un bugfix più nuovo sostituisce un pacchetto più vecchio su security.debian.org, ci sono alte probabilità che il vecchio pacchetto sia stato rimosso quando quello nuovo è stato installato. Da quel momento si avrà l'errore file not found. Non vogliamo distribuire pacchetti con bug di sicurezza conosciuti più a lungo di quanto sia assolutamente necessario.

Bisogna usare i pacchetti elencati negli ultimi security advisor, che sono distribuiti tramite la mailing list debian-security-announce. La cosa migliore è semplicemente eseguire apt-get update prima aggiornare il pacchetto.

D: Ho trovato la soluzione ad un problema, posso caricarla su security.debian.org direttamente?

R: No, non è possibile. L'archivio a security.debian.org è mantenuto dal team sicurezza, che deve approvare tutti i pacchetti. È necessario inviare le patch o il codice sorgente modificato al team sicurezza tramite l'indirizzo [email protected]. Saranno controllati dal team sicurezza ed eventualmente caricati, con o senza modifiche.

Se non si è pratici di aggiornamenti per la sicurezza e non si è sicuri al 100% che il pacchetto sia integro, usare questo metodo e non caricare nella directory incoming. Il team sicurezza ha poche possibilità di gestire pacchetti difettosi, specialmente se non hanno un numero di versione corretto. Attualmente i pacchetti non possono essere rifiutati ed il funzionamento di buildd diventerebbe problematico. Per favore si usi la posta elettronica e si aiuti non aggiungendo complicazioni al lavoro del team sicurezza.

La Developer's Reference contiene le istruzioni complete su cosa fare.

D: Ho trovato la soluzione ad un problema, posso caricarlo invece su proposed-updates?

R: Dal punto di vista tecnico, sì. Comunque, non si dovrebbe farlo, visto che ciò interferisce pesantemente con il lavoro del team sicurezza. I pacchetti sono copiati da security.debian.org nella directory proposed-updates automaticamente. Se un pacchetto con un numero di versione uguale o superiore è già installato nell'archivio, l'aggiornamento di sicurezza sarà rifiutato dal sistema di archiviazione. In tal caso, la distribuzione stable sarà preparata senza l'aggiornamento di sicurezza di quel pacchetto, a meno che i pacchetti sbagliati nella directory proposed-updates non siano stati rifiutati. Si contatti invece il team sicurezza includendo tutti i dettagli sulla vulnerabilità ed allegando i file sorgente (cioè i file diff.gz e dsc) all'e-mail.

La Developer's Reference contiene le istruzioni complete su cosa fare.

D: Sono sicurissimo che il mio pacchetto va bene, posso caricarlo?

R: Se si è veramente sicuri che il pacchetto non danneggi nulla, che sia la versione sia giusta (cioè maggiore della versione in stable e minore della versione in testing/unstable), che non sia cambiato il funzionamento del pacchetto nonostante sia stato corretto il problema di sicurezza, che sia stato compilato per la corretta distribuzione (che è oldstable-security o stable-security), che il pacchetto contenga il sorgente originale se è nuovo in security.debian.org, che la patch sia valida per la versione più recente e che essa riguardi solo il relativo problema di sicurezza (controllare con interdiff -z i file .diff.gz), che la patch sia stata controllata almeno tre volte e che debdiff non mostri alcun cambiamento, allora è possibile caricare i file nella directory incoming ftp://ftp.security.upload.debian.org/pub/SecurityUploadQueue direttamente a security.debian.org. Si prega di inviare anche un avviso con tutti i dettagli e i link a [email protected].

D: Come posso aiutare?

R: Controllando bene ogni problema prima di inviarlo a [email protected]. Se si è capaci di fornire delle patch allora questo accelererebbe il processo. Non limitarsi ad inoltrare messaggi su come verificare la presenza del problema perché noi li riceviamo già; cercare invece di aggiungere tutte le informazioni possibili.

Un buon modo per iniziare con il security work è di aiutare con il Debian Security Tracker (istruzioni).

D: Qual è lo scopo di proposed-updates?

R: Questa directory contiene i pacchetti che sono candidati ad entrare nella prossima distribuzione stable di Debian. Ogni volta che un manutentore carica un pacchetto per la distribuzione stable allora il pacchetto viene memorizzato nella stessa directory. Poiché stable è una versione che è ritenuta stabile allora non viene aggiornata automaticamente. Il team della sicurezza invia alla versione stable gli aggiornamenti dei pacchetti menzionati negli annunci, ma questi vengono inseriti nella directory proposed-updates. Ogni tanto il manager della distribuzione stabile controlla la lista dei pacchetti in proposed-updates e vaglia se un pacchetto sia pronto o meno per stable. Il tutto viene poi inserito nella revisione successiva di stable, come 2.2r3 o 2.2r4. I pacchetti non adatti saranno probabilmente rifiutati e cancellati da proposed-updates.

Si noti che i pacchetti caricati dai manutentori (e non dal team sicurezza) nella directory proposed-updates/ non sono supportati dal team sicurezza.

D: Come è composto il team della sicurezza?

R: Il team sicurezza Debian è composto da diversi membri e segretari. È lo stesso team sicurezza che invita le persone ad unirsi ad esso.

D: Per quanto tempo sono assicurati gli aggiornamenti di sicurezza?

R: Il team sicurezza supporterà una distribuzione stable fino a tre anni dopo il rilascio. Non è possibile supportare tre distribuzioni; supportarne due contemporaneamente è già abbastanza difficile.

D: Come si può controllare che i pacchetti siano integri?

R: Controllando la firma del file Release mediante la chiave pubblica usata per l'archivio. Il file Release contiene le checksums dei file Packages e Sources, che a loro volta contengono le checksums dei pacchetti binari e sorgenti. Istruzioni dettagliate su come controllare l'integrità dei pacchetti possono essere trovate nel Debian Securing Manual.

D: Cosa fare se un altro pacchetto non funziona dopo un aggiornamento di sicurezza?

R: Prima di tutto si dovrebbe capire perché il pacchetto non funziona e come il malfunzionamento è correlato con l'aggiornamento di sicurezza, poi si contatti il team sicurezza se il malfunzionamento è serio o lo stable release manager se non lo è. Stiamo discutendo circa i pacchetti che non funzionano dopo l'aggiornamento di sicurezza di un altro pacchetto. Se non si può capire cosa non va ma si ha una correzione, si contatti il team sicurezza anche se si potrebbe essere ridiretti allo stable release manager.

D: Cosa è un identificatore CVE?

R: Il progetto Common Vulnerabilities and Exposures assegna un nome univoco, chiamato identificatori CVE, per indicare una specifica vulnerabilità in modo da potersi riferire al problema in modo semplice e inequivocabile. Ulteriori informazioni possono essere trovate su Wikipedia.

D: Debian emette un DSA per ogni id CVE?

R: Il Debian security team tiene traccia di ogni id CVE rilasciato, lo lega ai pacchetti relevanti e valuta il suo impatto nel contesto di Debian, il fatto che a qualcosa sia assegnato un id CVE non implica necessariamente che il problema sia una seria minaccia per un sistema Debian. Queste informazioni sono tracciate nel Debian Security Tracker e per quei problemi che sono considerati seri viene emesso un Debian Security Advisory.

I problemi con un basso impatto che non implicano un DSA verranno risolti nel rilascio Debian successivo, in un rilascio minore delle distribuzioni stable o oldstable oppure sono inseriti in un altro DSA qualora sia emesso per una vulnerabilità più seria.

D: Debian può assegnare identificatori CVE?

R: Debian è una Numbering Authority di CVE e può assegnare gli identificatori ma per policy di CVE solo nel caso di problemi non ancora conosciuti. Coloro che sono a conoscenza di una vulnerabilità riguardante la sicurezza in un software per Debian e vorrebbe avere un identificatore per il problema possono contattare il Debian Security Team. Per i casi in cui la vulnerabilità sia già nota si consiglia di seguire la procedura indicata nel CVE OpenSource Request HOWTO.

D: Debian ha una policy sulla divulgazione delle vulnerabilità?

R: Debian ha pubblicato una policy sulla divulgazione delle vulnerabilità in quanto parte della sua partecipazione al programma CVE.

D: Il nostro strumento di gestione delle vulnerabilità ha mostrato che i seguenti punti sono aperti (elenco di CVEs con vari punteggi CVSS). Quando saranno risolti?

R: Debian non fornisce e non usa i punteggi CVSS da fonti esterne quando si controllano i problemi della sicurezza.

Si può controllare lo stato del singolo ID CVE nel Debian Security Tracker accedendo con l'ID.

La sezione «Note» conterrà informazioni aggiuntive, come il fatto che un problema di sicurezza non abbia richiesto un aggiornamento specifico, ma potrebbe venire risolto durante un successivo rilascio minore.

Un elenco di pacchetti per i quali è previsto un aggiornamento della sicurezza può essere trovato nella lista «dsa-needed».

Se si trova un errore nei dati del triage, per favore comunicatecelo. Il gruppo della sicurezza Debian non risponde normalmente alle richieste di informazioni specifiche, per quelle si dovrebbero contattare i produttori dello strumento di gestione delle vulnerabilità; dopotutto sono loro che vi hanno allertato sun un problema di sicurezza, non è stata Debian.

FAQ Debian sulla sicurezza deprecate

D: Che significa local (remote)?

L'informazione Tipo di problema nelle email DSA mails non è più usato da aprile 2014.
R: Alcuni avvisi riguardano vulnerabilità che non possono essere identificate con il classico schema di exploit locale e remoto. Alcune vulnerabilità non possono essere sfruttate da remoto, in altre parole non corrispondono ad un demone in ascolto su una porta di rete. Nel caso possano essere sfruttate da file speciali forniti eventualmente via rete anche se il servizio vulnerabile non è connesso permanentemente in rete, lo descriveremo come local (remote).

Tali vulnerabilità sono a metà strada tra le locali e le remote e spesso coprono archivi che possono essere forniti attraverso la rete, come allegati di posta o da una pagina di download.