Gentoo Logo

Guida per il Coordinatore dei GLSA

Indice:

1.  Prerequisiti

Account

Deve essere definito un determinato numero di account prima di lavorare come coordinatore di GLSA. Per generare un GLSA è necessario ottenere un account GLSAMaker. Per gestire bug di sicurezza bisogna avere un account su Bugzilla, aggiornato con privilegi di editbugs. Per poter inviare un GLSA bisogna avere un indirizzo del tipo tuonome@gentoo.org (in questo caso per essere uno sviluppatore Gentoo). Questo indirizzo email dovrà poi essere autorizzato ad inviare messaggi al mailing-group gentoo-announce. Per rendere definitivi degli XML di un GLSA è necessario che al proprio account di sviluppatore sia abilitata la possibilità di poter eseguire "commit access" verso la directory GLSA nel CVS repository di Gentoo. Infine è necessario un nick IRC. Gli sviluppatori Gentoo sono tenuti a mostrare il proprio nick nel canale #gentoo-security ogni qual volta siano on-line.

Nota: Tutti i nomi utilizzati dovrebbero essere costanti in modo tale da rendere più semplice l'autenticazione.

La chiave GPG

A questo punto bisogna creare una chiave GPG per il proprio account email tuonome@gentoo.org. È possibile generare una chiave specifica o aggiungere l'indirizzo @gentoo.org ad una chiave già esistente. Successivamente il proprio key ID dovrebbe impostato in LDAP, controllando inoltre che il proprio nome e lo key ID appaiano nell'elenco degli sviluppatori. È molto importante che la chiave venga pubblicata almeno sul server delle chiavi subkeys.pgp.net, tuttavia la si può pubblicare anche su altri.

Ambiente

Bisogna installare un ambiente CVS sulla propria macchina locale in modo tale da poter effettuare i commit dei propri GLSA. Ciò viene reso possibile eseguendo il checkout di una parte del CVS repository di Gentoo verso una directory data. (per esempio ~/gentoo_cvs):

Codice 1.1: Configurazione ambiente CVS

you@home you $ mkdir gentoo_cvs
you@home you $ cd gentoo_cvs
you@home gentoo_cvs $ export CVS_RSH="ssh"
you@home gentoo_cvs $ export CVSROOT="yourname@cvs.gentoo.org:/var/cvsroot"
you@home gentoo_cvs $ cvs checkout gentoo/xml/htdocs/security

Sottoscrizioni a Mailing-list

Per poter inviare messaggi verso le liste dove saranno pubblicate le GLSA, bisogna iscrivere il proprio account tuonome@gentoo.org ad esse:

Lista Pagina d'iscrizione
bugtraq@securityfocus.com http://www.securityfocus.com/archive
full-disclosure@lists.grok.org.uk https://lists.grok.org.uk/mailman/listinfo/full-disclosure

Nota: Ci si può iscrivere ad una versione di tipo digest (raccolta) della Full-Disclosure.

Come sviluppatori di sicurezza si verrà aggiunti alla lista gentoo-core e al mailgroup security@gentoo.org. È consigliabile iscriversi anche a gentoo-announce, gentoo-dev e gentoo-security.

2.  Tipi di bug di Sicurezza e componenti di Bugzilla

Tutti bug di sicurezza sono reperibili nella categoria Gentoo Security di Bugzilla. Se si individua un bug di sicurezza che ha un nome di categoria errato, si prega di correggerlo immediatamente. Vi sono differenti tipologie di bug di sicurezza, e ciascuno ha il proprio componente.

Vulnerabilità

Le vulnerabilità sono bug di sicurezza relativi alla versione originaria di un software o bug introdotti nell'impacchettamento degli ebuild di Gentoo. Questi bug sono riportati nei GLSA. I bug relativi al kernel hanno la loro propria categoria e non dovrebbero essere archiviati come Vulnerabilità (vulnerability).

Kernel

Le vulnerabilità sono trattate utilizzando una procedura a parte. Per distinguerle facilmente dagli altri bug, esse vengono archiviate sotto la categoria Kernel. I bug relativi al Kernel non risultano nei GLSA.

Configurazione Predefinita

I pacchetti Gentoo dovrebbero avere le impostazioni predefinite più sicure possibile. I bug che toccano le configurazioni predefinite sono inseriti quando tali configurazioni, fornita con il pacchetto, possono essere migliorate in termini di sicurezza. I bug relativi alla Configurazione Predefinita non generano alcun GLSA.

Auditing

Le Vulnerabilità rilevate dagli sviluppatori di Gentoo dovrebbero essere controllate più volte prima di essere rese note (verso le liste degli sviluppatori originali del software o le liste inerenti la sicurezza). Esse vengono archiviate come bug confidenziali (Confidential Bugs - si veda qui di seguito) e con il componente Auditing. Quando l'individuazione del bug è stata verificata, questo viene commutato a Vulnerabilità.

Bug di tipo limitato ("Restricted")

A volte un bug viene comunicato al Team di Sicurezza di Gentoo sotto promessa di quest'ultimo di mantenerlo segreto fino ad un pubblico rilascio, tipicamente conosciuta come data d'embargo odata di rilascio coordinato. I bug limitati hanno la checkbox "Gentoo Security" selezionata, e quindi possono essere raggiunti solo da membri del Team di Sicurezza di Gentoo. Gli attori esterni (il manutentore del pacchetto, il tester dell'architettura) possono essere aggiunti in base nominale, gli alias non dovrebbero mai essere utilizzati (questo perché gli alias sono troppo larghi e non permettono commenti ai bug).

Vi sono tre differenti tipi di bug "restricted" (con limitazioni. ndt). I primi (e i più segreti) sono i bug CLASSIFIED (classificato, ndt). Un bug è definito classified quando contiene informazioni che non dovrebbero mai venir rilasciate. Questo include citazioni di email personali inviate a mailing-list ristrette o patch intermedie non rese pubbliche. I bug classificati vengono identificati dalla keyword CLASSIFIED, nella loro Status Whiteboard. Una volta CLASSIFIED, un bug non può tornare allo stato non classificato a meno che almeno due responsabili della sicurezza siano d'accordo nel declassare il suddetto bug. I bug CLASSIFIED non dovrebbero mai essere aperti (resi cioè "UNRESTRICTED").

Il secondo tipo di bug è CONFIDENTIAL. questi sono bug contenenti informazioni che dovrebbero essere tenute segrete fino ad una data di emissione coordinata precedentemente concordata. Nessun aspetto del bug (nome del pacchetto colpito, descrizione, patch proposte e qualsiasi altra cosa) dovrebbe mai uscire allo scoperto. Le patch NON devono essere inserite nel CVS di portage.

Il terzo (e meno segreto) tipo di bug "Restricted" è dato dai bug SEMI-PUBLIC (semipubblico, ndt). I bug semipubblici dovrebbero restare segreti, ma le patch potrebbero essere inserite in portage. Questo accade di solito quando la vulnerabilità non è sconosciuta dalla maggioranza del pubblico ma è accessibile da chiunque (per esempio una patch sul CVS originale del software).

3.  Gestione pubblica della vulnerabilità del bug

Regole della "Status Whiteboard"

Il pannello di stato in Bugzilla consente al team di Sicurezza di tener traccia dei passi effettuati verso la risoluzione del bug di sicurezza. Dovrebbe seguire il seguente modello "RATING [status] coordinatore", dove:

Elemento Contenuto Esempio
RATING Il rating della vulnerabilità, in base alle regole di politica correnti B3
[status] Lo stato effettivo del bug, con informazioni aggiuntive(opzionali) [ebuild+]

Sono considerati validi i seguenti tipi di status:

Status Descrizione
upstream In attesa che uno sviluppatore pubblichi in "upstream" (provenienza originale del software, ndt) una nuova versione o patch
upstream+ Nessuna risposta dagli sviluppatori originali del software ("upstream")
ebuild In attesa che il mantenitore del pacchetto di Gentoo fornisca un ebuild corretto
ebuild+ Nessuna risposta ricevuta dal mantenitore, si prende in considerazione un aggiornamento di sicurezza
stable In attesa che le architetture contrassegnino il pacchetto con le keyword appropriate
stable+ Alcuni team di architettura stanno impiegando troppo tempo per contrassegnare il pacchetto in manera appropriata
glsa? Il team di sicurezza deve decidere se è necessario un GLSA
glsa In attesa che il coordinatore invii il suo GLSA
glsa+ Il GLSA è in ritardo, ogni coordinatore di GLSA può correggerlo ed inviarlo
cleanup Si aspetta che il manutentore del pacchetto rimuova le versioni vulnerabili dall'albero di portage
cleanup+ Nessuna risposta dal manutentore del pacchetto. Il team di sicurezza potrebbe rimuovere le versioni vulnerabili dall'albero di portage se necessario

Sono ammesse le seguenti informazioni aggiuntive:

Informazione aggiuntiva Descrizione Stati Corrispondenti
tomask Quando un package.mask è stato richiesto verso il pacchetto upstream+, ebuild+
masked se il pacchetto era stato segnato "masked" come soluzione temporanea upstream+, ebuild+
tempglsa Quando un GLSA temporaneo è stato pubblicato come soluzione temporanea upstream+, ebuild+
blocked Quando il bug è bloccato da un altro bug (qualsiasi)

Esempi:

C0 [stable]
B1 [stable blocked]

Determinare lo stato di partenza del bug

Quando la correzione non è disponibile dallo sviluppatore originale e/o non è stata rilasciata una patch ufficiale per risolvere il problema, il bug si trova in stato [upstream]. Se è disponibile una correzione, il bug si trova nello stato [ebuild]. Se la correzione è stata inserita in portage, il prossimo passo è quello di stabilizzare, quindi il bug assume lo stato [stable]. Quando una correzione è presente in portage con tutte le parole chiave correttamente configurate e se il problema è abbastanza severo da garantire un GLSA, il bug è nello stato [glsa]. Se il problema non è abbastanza severo, il voto per il GLSA è il prossimo passo, quindi lo stato sarà [glsa?].

Stato dei bug in [upstream]

Nello stato [upstream], si è in attesa della pubblicazione di una versione corretta o di una patch decente. Questo stato richiede controlli regolari degli sviluppatori originali per informazioni: mailing list di sviluppo e annunci, siti internet, database di bug database, VCS ove possibile, sono tutte fonti importanti d'informazioni. Patch non ufficiali devono essere considerate soltanto se lo sviluppatore originale non reagisce alla vulnerabilità, e devono essere controllate più volte per assicurarsi che non siano maligne. Quando viene annunciata una nuova versione di una correzione, o viene rilasciata una nuova patch, il bug entra nello stato [ebuild].

Se dal ramo di sviluppo originale non v'è reazione né patch alcuna, si entra nello stato [upstream+]. L'unica opzione consiste nell'applicare una security-mask al pacchetto vulnerabile e pubblicare un glsa temporaneo se necessario. Si veda la politica corrente per ulteriori dettagli inerenti alla procedura d'approvazione del security-masking. Il pannello di stato dovrebbe quindi essere flaggato con le keyword masked e/o tempglsa e la severità del bug impostata ad enhancement.

Bug in stato [ebuild]

In stato [ebuild], bisogna identificare il manutentore del pacchetto, ed imporgli di generare una correzione. Le fonti per identificare il gruppo o lo sviluppatore responsabile della manutenzione del pacchetto sono il file metadata.xml, presente in portage nella directory relativa del pacchetto, ed il file Changelog che mostra chi ha effettuato gli ultimi aggiornamenti di versione. Mettere in cc: il gruppo e il mantenitore responsabile del pacchetto inerente al bug e chiedere che venga fornita un ebuild per la versione della correzione corrente. Controllare periodicamente che un ebuild non sia stato inserito in portage senza alcun commento riguardo il bug (a volte accade). Quando l'ebuild appare, il bug entra in stato [stable].

Se il manutentore non lo rivela, si arriva allo stato [ebuild+]. In casi di una versione correttiva disponibile, testare se un semplice incremento di versione funziona (basta rinominare l'ebuild alla versione necessaria e farne l'emerge). Se è disponibile solamente una patch, testare se quest'ultima viene applicata correttamente. A questo punto trovare uno sviluppatore con accesso al repository gentoo-x86 per eseguire l'incremento di versione e segnare l'ebuild ~ per testarlo.

Se l'incremento di versione non è facile e/o si rileva un problema con l'ebuild in questione, l'unica opzione consiste nell'applicare una security-mask al pacchetto non mantenuto e pubblicare un GLSA temporaneo, se necessario. Si veda la politica corrente per ulteriori dettagli inerenti la procedura d'approvazione del security-masking. Il pannello di stato dovrebbe quindi essere flaggato con le keyword masked e/o tempglsa e la bug severity impostata a enhancement.

Bug in stato [stable]

Nello stato [stable], bisogna determinare di quali chiavi l'ebuild fornito necessita prima che il GLSA venga pubblicato. Ciò può essere ingannevole. Bisogna considerare ogni versione attualmente presente in portage in modo che l'ebuild abbia le stesse o più keyword "stable" di qualsiasi altro pacchetto presente nel portage. Ecco un esempio:

Versioni Keyword
Influenzate x86 ~ppc ~ia64
Influenzate x86 ppc
Influenzate ~x86 ~ppc ~ia64
La correzione deve avere: x86 ppc ~ia64

Nota: È possibile usare http://packages.gentoo.org per aiutarsi nel determinare le keyword necessarie. Qualora i pacchetti interessati fossero stati rimossi troppo presto dal manutentore del pacchetto stesso, usare l'accesso ViewVC per cercare nell'archivio delle vecchie keyword.

Una volta determinate (ed inserite come riferimento nel bug) le keyword necessarie, mettere in CC i team di sviluppo delle varie architetture, chiedendo loro di contrassegnare l'ebuild come "stable" o "testing" di conseguenza. Per assicurarsi che i team delle architetture prendano in carico il bug, non dimenticarsi di aggiungere "STABLEREQ" al campo "Keywords" del bug. Gli alias per le varie architetture sono del tipo architettura@gentoo.org (x86@gentoo.org, ppc@gentoo.org...). Tutte le architetture (incluse quelle "non supportate") devono essere contattate. Ma si tenga conto che solo le architetture "supportate" (come definite da regolamento) sono necessarie prima che il bug possa avanzare allo stato [glsa]. Controllare periodicamente per verificare se vi sono nuove keyword nell'ebuild, dato che talvolta queste vengono modificate senza lasciare nessun commento nel bug. Non appena le keyword richieste sono state inserite nel bug per tutte le architetture supportate, il bug entra nello stato [glsa].

Se i team di sviluppo per le relative architetture impiegano troppo tempo nel testare o cambiare le proprie keyword, o rifiutano di contrassegnare come stabile un pacchetto per problemi non ancora risolti, il bug assume lo stato di [stable+]. Bisogna rintracciare i mantenitori delle varie architetture affinché contrassegnino come stabile il pacchetto o diano supporto nel testing dello stesso. Bisognerebbe inoltre convincere gli sviluppatori per le varie architetture che se scoprono un bug in un'ebuild che era già presente nelle precedenti versioni "stable", l'ebuild dovrebbe essere contrassegnata come "stable" anche se non è attualmente stabile, come specificato nel regolamento. Se non possono essere rintracciate le keyword, l'unica opzione rimanente è quella di applicare una security-mask al pacchetto: non esiste alcuna versione accettabile non affetta dal bug, quindi è come se nessuna correzione accettabile sia stata fornita nel ramo di sviluppo originale.

Bug in stato [glsa]

Nello stato [glsa], il bug di sicurezza è stato corretto. Bisogna pubblicare il GLSA o semplicemente chiudere il bug senza GLSA. Il regolamento determina in quali casi un GLSA sia necessario e in quali casi non lo è. Vi sono anche situazioni nelle quali è necessario un voto per definire se un GLSA è necessario o meno([glsa?]). Se almeno due membri del Team di sicurezza votano per "no GLSA", allora nessun GLSA dovrebbe essere pubblicato. Il bug rimane in stato [glsa] finché non viene pubblicato il GLSA.

Quando è necessario un GLSA, ma non è stato pubblicato nulla, il bug entra nello stato [glsa+]. Questo è il caso quando ci sono ritardi durante la scrittura della bozza, revisione, o invio dell' advisory. Qualsiasi membro del team di sicurezza potrebbe prendere il comando e concludere il GLSA.

Bug nello stato [cleanup]

Questo stato non è in ordine come gli altri. Esso viene usato per denotare che il manutentore deve rimuovere gli ebuild vulnerabili dall'albero di portage.

Ad esempio il pacchetto foo è vulnerabile in versioni precedenti a 1.23. La versione 1.24 viene aggiunta all'albero di portage ed è già stabile (ad esempio la stabilizzazione è stata fatta prima che si conoscesse la vulnerabilità), solo i vecchi ebuild devono essere rimossi. Il prossimo stato in questo caso sarà [glsa] o [glsa?] in base alla severità.

Un altro caso potrebbe essere quando un pacchetto è stato aggiornato e tutti gli steps sono stati eseguiti (ad esempio il GLSA è stato inviato o il team ha deciso di non inviarne), ma gli ebuild vulnerabili dovrebbero essere rimossi per evitare che gli utenti, accidentalmente, possano installarli; il bug dovrebbe rimanere aperto e avere uno stato di [cleanup]. Questo non è solitamente necessario ma può essere utilizzato in base al caso quando il team di sicurezza ha un elevato interesse a rimuovere gli ebuild velnerabili per qualsiasi ragione.

4.  Gestione delle vulnerabilità dei bug "confidential"

Regole del pannello di stato (Status Whiteboard)

I bug confidenziali dovrebbero seguire questo modello: RATING [status] coordinatore / KEYWORD CRD, dove:

Elemento Contenuto Esempio
RATING Il rating della vulnerabilità, facendo riferimento alle politiche correnti B3
[status] Lo stato effettivo del bug, con informazioni aggiuntive (opzionali) [ebuild+]
KEYWORD Il livello confidenziale del bug, può essere CLASSIFIED, CONFIDENTIAL, SEMI-PUBLIC CLASSIFIED
CRD La data di rilascio coordinato per la rivelazione dei bug. Se non viene fornito un'orario, prendere come riferimento 14.00 UTC 2009-01-06 18:00 UTC

I seguenti stati supplementari sono accettati per i bug confidenziali:

Stato Descrizione
preebuild Il mantenitore del pacchetto specifico è stato chiamato a preparare un'ebuild che non deve essere inserita nel tree del CVS, ma allegata al bug
prestable I collaudatori di una specifica architettura sono stati chiamati a testare un ebuild non ancora pubblico

Maneggiare bug confidenziali

I bug semipubblici dovrebbero essere trattati come bug pubblici, a parte il fatto che nessun gruppo di sviluppo o alias per le varie architetture dovrebbe essere messo in CC tranne gli sviluppatori specifici per quel bug.

I bug confidenziali e classificati richiedono maggiore attenzione. L'ebuild e i file per correggere la vulnerabilità NON dovrebbero essere aggiunti all'albero di portage, e nessun aspetto di qusti bug dovrebbe essere discusso in pubblico. Patch o archivi tarball provenienti da overlay di portage possono comunque essere allegati al bug. I collaudatori dovranno installare il proprio overlay per testarlo. L'idea con questi bug è di preparare l'ebuild e farlo testare entro la data di rilascio concordata, in modo tale da poterlo rilasciare con tutte le keyword necessarie insieme al GLSA nello stesso istante in cui il rilascio dell'ebuild diventa pubblico.

5.  Preparare bozze di GLSA con GLSAMaker

Regole Generali

Il GLSA dovrebbe utilizzare il nome del software colpito prestando attenzione a maiuscole/minuscole, non utilizzando, quindi il nome di pacchetto Gentoo. Per esempio, dovreste utilizzare "MySQl" e non "mysql". I nomi in minuscolo dovrebbero essere utilizzati solo se il software ha un nome tutto in minuscolo o se il software è identificato dal nome del suo comando (ad esempio "traceroute").

Non copiare nessuna parte di una descrizione già esistente, ma utilizzarle come fonti d'informazione per il GLSA. Se viene copiato, per esempio, una descrizione di un software da un sito internet, si prega di utilizzare una citazione e le virgolette.

Titolo, Sinossi, Keyword

Il titolo deve essere corto (< 60 caratteri nella maggior parte dei casi) ed indicare il nome dell'applicazione (non la categoria). Dovrebbe consentire d'identificare chiaramente la vulnerabilità senza entrare nei dettagli. La versione dovrebbe essere omessa, tranne nei rari casi in cui sia permesso identificare un pacchetto più chiaramente. I pacchetti multipli colpiti dovrebbero essere separati da una virgola. Gli esempi includono:

MySQL: creazione insicura di un file temporaneo
Exim: verify=header_syntax buffer overflow
Apache 1.3: Heap overflow in mod_redirect
MPlayer, xine-lib: Vulnerabilities in RTSP stream handling

La sinossi è una corta (< 160 caratteri) ma completa descrizione della vulnerabilità. Gli esempi includono:

Due utilità MySQL creano file temporanei con percorsi fissi, consentendo ad un attaccante di utilizzare un collegamento simbolico per ingannare MySQL nel sovrascrivere dati importanti.
Sono stati rilevati vulnerabilità multiple, inclusi buffer overflow eseguibili da remoto, nel codice comune tra Mplayer e la libreria xine

La categoria delle keyword GLSA è solitamente impostata a "Ebuild" e dovrebbe contenere il nome del principale software vulnerabile (per esempio "MySQL"). Altri tipi di keyword includono "Portage" (per bug del portage) e "Infrastructure" (compromissioni dei servers).

Accesso, Severity

L'accesso dovrebbe essere "Locale" o "Remoto". Le vulnerabilità locali possono essere gestite solo da un utente locale del sistema in questione. Per esempio implica eseguire uno script per elevare i privilegi, oppure accedere ad una directory temporanea per far partire un attacco tramite collegamento simbolico. Le vulnerabilità remote sono quelle che possono essere eseguite da un attaccante con o senza un account sul sistema bersaglio. Le vulnerabilità remote possono essere sia attive (sfruttando un server in ascolto per inviare codice maligno) o passive (attirare un utente per collegare il software residente sul client ad un server "maligno" o ad aprire file con codice analogo).

La severità è un'indicazione di quanto in profondità arrivi la vulnerabilità. Viene definita nella Vulnerability Treatment Policy, nella tabella "Evaluate the vulnerability type". Si noti che dipende solo dal massimo rischio, non al fattore comune della configurazione delle opzioni al rischio. Un buffer overflow che consenta l'esecuzione di codice arbitrario in un raro client software, solo quando si utilizza una specifica opzione di configurazione, teoricamente rimane una severità Alta". Un DoS in tutte le configurazioni di Apache teoricamente resta severità "Normale". In rari casi la severità può essere corretta, quando molti membri del team di sicurezza sono d'accordo, verso un livello più alto. Per esempio, una vulnerabilità che consentisse il deface di un sito internet in Apache ed in tutte le configurazioni dovrebbe probabilmente essere a severità "Alta" piuttosto che "Normale"

Pacchetti vulnerabili, inalterati

Questa sezione fornisce informazioni sulle versioni dei pacchetti che sono rimasti inalterati o vulnerabili alla vulnerabilità descritta nell'informativa corrente. Prestare attenzione particolare a quei numeri, perché rappresentano una delle poche zone dove ogni errore implica un'errata pubblicazione.

Ci sono diversi campi che compongono il valore di una versione. Il campo contenente il nome del pacchetto deve elencare il nome del pacchetto e la categoria ("net-mail/exim"). Riguardo il campo "Architetture", inserire "*" quando la descrizione della versione si applica a tutte le architetture contrassegnate nell'ebuild. Utilizzare voci multiple per architetture differenti se la descrizione della versione è differente di architettura in architettura. Il campo "Auto" deve essere impostato a "true" se il pacchetto è aggiornabile via emerge. Per i campi versione possono esservi molteplici casistiche.

Importante: In questa sezione (e soltanto in questa sezione), le architetture dovrebbero essere scritte così come compaiono nelle keyword (cioè "x86", "amd64", "sparc"...), e non in maiuscolo.

Il caso più semplice si verifica quando la vulnerabilità è presente in tutte le vecchie versioni ed è corretta in tutte le versioni più recenti rispetto alla versione di una specifica correzione. In questo caso, usare ">= prima versione corretta" come inalterata e "<= ultima versione colpita" come vulnerabile. Controllare più volte che non esista un'ebuild fra l'ultima versione colpita e la prima versione corretta. Qualora ci si trovasse in dubbio, usare ">= prima versione corretta" come inalterata e "<= prima versione corretta" come vulnerabile.

Un caso più complesso si verifica quando la vulnerabilità si presenta soltanto in alcune versioni recenti. Si propone l'esempio di un pacchetto dove la versione 1.2.8-r2 non è stata colpita, le versioni 1.2.9, 1.2.9-r1 e 1.2.9-r2 sono state colpite e la versione 1.2.10 è stata corretta. In questo caso ci sono due possibilità.

Inalterata Vulnerabile
>=1.2.10 ==1.2.9 ==1.2.9-r1 ==1.2.9-r2
<=1.2.8-r2 >=1.2.10 <1.2.10

Per concludere, quando il pacchetto non ha una versione corretta, omettere l'opzione "inalterato" (unaffected) per quel pacchetto ed impostare "Auto" a "no".

Importante: Quando le versioni delle correzioni sono complesse, controllare più volte che le versioni XML e TXT del GLSA elenchino correttamente le proprie versioni

Background, Descrizione, Impatto

La sezione Background fornisce le informazioni sul pacchetto a rischio. Descrive brevemente cos'è e fornisce tutte le informazioni utili a comprendere la parte del pacchetto vulnerabile. La sezione Background dovrebbe essere più corta della sezione di descrizione o della sezione impatto (Impact). Tra gli esempi da seguire si include:

Il K Desktop Environment (KDE) è un potente ambiente grafico desktop della Free Software Foundation. KDE usa gli URI handlers per innescare vari programmi quando vengono ricevute delle URL specifiche.
CVS (Concurrent Versions System) è un sistema open-source di controllo di versione network-transparent. Contiene sia una client utility che un server.
Metamail è un programma che decodifica la posta codificata MIME. Viene quindi spesso automaticamente invocato quando una email viene letta o ricevuta.

La sezione "descrizione" descrive più in dettaglio qual è la vulnerabilità senza dire cosa accade quando questa viene sfruttata. Dovrebbe essere comprensibile da persone senza grandissime basi di sicurezza. A volte non si trovano affatto le informazioni sulla vulnerabilità, in questi casi lasciare la descrizione breve. Tra i buoni esempi si include:

Il Telnet URI handler in Opera non controlla l'esistenza di caratteri '- ' iniziali nell'hostname. Di conseguenza, un link maligno del tipo telnet:// potrebbe essere capace di passare opzioni al telnet stesso. Un esempio sarebbe "telnet://-nMyFile". Se MyFile esiste nella home directory dell'utente e l'utente che clicca sul link ha i permessi di scrittura su di esso, i contenuti del file saranno sovrascritti con'output delle informazioni del telnet trace. Se MyFile non esiste, il file verrà generato nella home directory dell'utente.
L'utility di bug reporting di MySQL(mysqlbug) genera un file temporaneo per loggarvi i bug reports. Un utente locale "maligno" con diritti di scrittura su /tmp potrebbe generare un link simbolico dal nome mysqlbug-N puntante ad un file protetto, come /etc/passwd, in modo tale che qualora mysqlbug generasse l'ennesimo file di log, finirebbe con il sovrascrivere l'obiettivo (in questo esempio, /etc/passwd). Una vulnerabilità simile esiste con la mysql_multi utility, che genera una file temporaneo denominato mysql_multi.log
Vulnerabilità multiple sono state scovate e riparate nell'RTSP che gestisce il codice in comune alle versioni recenti di questi due pacchetti. Queste vulnerabilità includono parecchi buffer overflow sfruttabili da remoto.

La sezione "Impact" descrive l'effetto globale delle vulnerabilità descritte nella sezione "descrizione", una volta sfruttate. Dovrebbe focalizzarsi sul massimo rischio possibile. Buoni esempi sono:

Un attaccante remoto, presentandosi come RTSP stream server, può eseguire codice in modo arbitrario con i diritti dell'utente del software che sta eseguendo lo stream (MPlayer o qualsiasi altro player che utilizzi xine/xine-lib). Un altro attaccante può attirare un utente per usare un URL "maligna" o una playlist per ottenere lo stesso identico risultato
Questa vulnerabilità ha due possibili effetti. In primo luogo, può generare nuovi file nella home directory dell'utente. In secondo luogo, e molto più pericolosao, può sovrascrivere i file esistenti per i quali l'utente ha i permessi di scrittura. Un attaccante con una certa conoscenza della home directory dell'utente potrebbe essere in grado di distruggere file importanti salvati in quella directory.

Workaround, Soluzione

Il workaround descrive se esiste un qualsiasi maniera semplice (tranne l'aggiornamento alla versione correttiva) per evitare di essere vittime della vulnerabilità. I buoni esempi includono:

Come workaround provvisorio, bypassando il supporto del Kerberos 4, potreste spegnere il kadmin del Kerberos 4 facendo partire il kadmind con l'opzione -- no-kerberos4.
Ad oggi non esistono workaround conosciuti.

La sezione "Risoluzione" spiega in termini umanamente comprensibili che cosa bisogna fare per essere completamente protetti dalla vulnerabilità. Questa sezione deve assomigliare a quanto segue:

Codice 5.1: Esempio di risoluzione

Tutti gli utenti di Heimdal dovrebbero effettuare l'aggiornamento all'ultima versione stabile:
<code>
# emerge sync
# emerge --ask --oneshot --verbose ">=app-crypt/heimdal-0.6.2"

Qualora vi fossero più architetture, dovrebbe assomigliare a questa

Codice 5.2: Esempio per architetture multiple

Gli utenti di OpenOffice.org su SPARC dovrebbero:
<code>
# emerge sync
# emerge --ask --oneshot --verbose ">=app-office/openoffice-1.1.0-r3"</code>
</p>
<p>

Gli utenti di OpenOffice.org su PPC dovrebbero:
</p>
<code>
# emerge sync
# emerge --ask --oneshot --verbose ">=app-office/openoffice-1.0.3-r1"

Se il GLSA riguarda una libreria condivisa, includere il seguente paragrafo all'estremità della sezione "risoluzione" per avvisare circa la necessità di effettuare la ricompilazione degli eseguibili collegati.

I pacchetti che dipendono da questa libreria possono avere bisogno di essere ricompilati. Strumenti come revdep-rebuild possono aiutare nell'identificare alcuni dei questi pacchetti.

Riferimenti

La sezione "Riferimenti" dovrebbe fornire i collegamenti alle informazioni di riferimento sulla vulnerabilità in questione. Quando un numero CVE (CVE-xxxx-xxx) è disponibile, dovrebbe essere fornito (con il numero CVE completo nel Titolo, "Title"). Si può anche collegare un advisory di uno sviluppatore originale e/o un'email di annuncio, quando disponibili. Evitare link ad advisory di altre distribuzioni o advisory non ufficiali provenienti da entità esterne.

6.  Pubblicazione GLSA

Revisione tra colleghi

Quando la bozza iniziale è pronta, deve essere sottoposta alla revisione degli altri membri del team di sicurezza, effettuando una richiesta di revisione sul canale #gentoo-security. La versione finale (dopo che tutte le correzioni sono state applicate) deve essere approvata da due membri del team di sicurezza prima di essere committata e spedita.

Nel rivedere la bozza di un GLSA, controllare con attenzione le seguenti cose:

  • Versioni colpite/inalterate (Controllare nel Changelog che le versioni siano corrette e assicurarsi che non vi siano versioni che non siano definite o colpite o inalterate).
  • Correttezza del titolo.
  • Severity ed accesso (Non fare solo riferimento al rating del bug e se è necessario un account locale o remoto per un accesso "local o remote").
  • Alla fine viene effettuato un sanity check: si verifica che sia veramente una vulnerabilità e non un semplice bug (come le non-vulnerabilità di samba e shadow)

Quando la bozza viene approvata, deve esserle assegnato un numero ufficiale GLSA. Ciò viene fatto chiamando la funzione "Move" in GLSAMaker per spostare la bozza dalla zona di sviluppo alla zona ufficiale.

GLSA XML commit

Bisogna effettuare il commit del GLSA XML nell'albero del CVS di Gentoo in modo che compaia automaticamente nella gestione del feed RDF, nella lista dei GLSA e negli aggiornamenti di portage. Aggiornare in primo luogo la propria directory GLSA nel tree del repository gentoo CVS:

Codice 6.1: Aggiornamento albero CVS

you@home you $ cd gentoo_cvs
you@home gentoo_cvs $ cvs update -dP gentoo/xml/htdocs/security

A questo punto cliccare Fetch nel GLSA per scaricare la versione XML, e salvarla nella propria directory gentoo_cvs/gentoo/xml/htdocs/security/en/glsa/ . A questo punto effettuare il commit ed aggiungere il file XML:

Codice 6.2: Commit GLSA

you@home gentoo_cvs $ cd gentoo/xml/htdocs/security/en/glsa
you@home glsa $ cvs add glsa-YYYYMM-NN.xml
you@home glsa $ cvs commit -m "GLSA YYYYMM-NN" glsa-YYYYMM-NN.xml

Annuncio via E-mail

Avvertenza: Ogni volta che viene utilizzata una nuova installazione (software o macchina) per inviare un annuncio GLSA, assicurarsi che il proprio setup venga controllato, inviando un'email di test ad un altro membro del team di sicurezza.

Cliccare su Txt download per ottenere una versione di testo del GLSA. Controllare che la sezione colpite/inalterate (affected/unaffected) sembri a posto, quindi preparare una mail con le seguenti regole:

  • Da eIndirizzo di Ritorno devono essere impostati a tuonome@gentoo.org
  • To eCc dovrebbero essere configurati secondo regolamento
  • Oggetto deve essere "[ GLSA XXXXYY-ZZ ] la propria vulnerabilità qui" (copiare/incollare dal titolo nel file di testo)
  • Il corpo della mail dovrebbe corrispondere al contenuto del file di testo, dall'intestazione "Gentoo Linux Security Advisory" alla fine del file
  • L'email deve essere firmata dalla chiave GPG per l'indirizzo tuonome@gentoo.org

Nota: Si riceverà un'email di ritorno da gentoo-announce dicendo che è richiesta moderazione. Basta rispondere a questa mail e l'email di annuncio precedentemente menzionata arriverà a destinazione.

Chiusura dei bug

Controllare che la mail sia arrivata a gentoo-announce, poi è possibile chiudere i(l) bug relativo, regolando la condizione a RESOLVED/FIXED, con un commento indicante il numero di GLSA.

Pubblicazione Errata/Aggiornamenti

Un errata viene pubblicato quando viene commesso un errore, altrimenti si sta parlando di un aggiornamento. Quando la politica garantisce una ripubblicazione dovrebbero essere seguite queste linee guida:

  • Il campo revisione dovrebbe essere correttamente impostato in XML. Ciò significa che la revisione potrebbe avere bisogno di di essere corretta manualmente nella directory data di GLSAMaker, se si effettuano cambiamenti multipli usando GLSAMaker (es. <revised>September 10, 2004: 02</revised>)
  • Se non sussiste vulnerabilità nessun pacchetto colpito dovrebbe essere elencato nell'XML
  • Il titolo può cambiare (es. GLSA 200409-14 per Samba e GLSA 200411-01 per ppp)
  • Non tutti gli Errata richiedono ripubblicazione. La politica spiega dettagliatamente quando la ripubblicazione è necessaria.
  • Per la versione di testo GLSAmaker può aggiungere le informazioni relative agli aggiornamenti ed alle errata. Si seguano manualmente le istruzioni fornite da GLSAmaker.
  • La versione testuale deve contenere la sezione degli aggiornamenti o delle errata (si veda l'esempio indicato sotto) e soltanto DOPO QUESTO solo sezioni vengono cambiate (la versione XML non ha sezioni aggiuntive)
Questo advisory è stato descritto via ppp in maniera non corretta come vulnerabile ad un DoS. Dopo ulteriori verifiche, sembra che un utente remoto possa negare soltanto il servizio a sé stesso, quindi questo bug non induce alcun problema di sicurezza. Le sezioni corrette compaiono qui sotto.

Ecco due esempi completi di errata email, si veda ERRATA: [GLSA 200409-14 ] Samba: Remote printing non-vulnerability (dove non sono presenti reali vulnerabilità) e ERRATA: [GLSA 200801-09 ] X.Org X server and Xfont library: Multiple vulnerabilities (dove i problemi non sono risolti correttamente nella prima versione). Per un aggiornamento si veda UPDATE: [GLSA 200410-30 ] GPdf, KPDF, KOffice: Vulnerabilities in included xpdf (dove la correzione ha introdotto un'altra vulnerabilità ).

Altrimenti dovrebbero essere seguite le linee guida standard GLSA.

7.  Strumenti per i Coordinatori GLSA

Raccolta delle Informazioni

  • packageview è uno strumento che aprirà packages.gentoo.org e Gentoo ViewCVS nel punto giusto per una categoria e una nome pacchetto assegnati. Aiuta a determinare quali keyword sono richieste per tracciare i cambiamenti di un pacchetto.

Guide GLSA per la pubblicazione

  • glsacommit è una funzione bash che si occupa delle gestione del commit dei GLSA. Caratterizzato dall'ssh-agent keyadding, glsa-check controlla più volte la conformità ed ha delle funzioni "Sei sicuro?". Modificarlo per soddisfare le proprie necessità e le posizioni delle directory.

Security Subversion repository

  • Il Repository Subversion Sicurezza contiene diversi strumenti per valutare in modo collaborativo se Gentoo è affetta da nuovi identificatori CVE, e strumenti per determinare le keywords di destinazione. Molti strumenti interagiscono direttamente con Bugzilla, rendendo non necessari i copia-incolla manuali.


Stampa

Aggiornato il 15 maggio 2011

Oggetto: Questo documento contiene le procedure, i suggerimenti e soluzioni utili per il coordinatore dei GLSA

Thierry Carrez
Autore

Sune Kloppenborg Jeppesen
Autore

Matthias Geerdsen
Autore

Robert Buchholz
Autore

Alex Legler
Author

Dungeon01
Traduzione

Luigi Mantellini
Traduzione

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.