[Solira] OpenSSL e Debian (e derivate)

Mario mario.tux a gmail.com
Mer 14 Maggio 2008 10:40:12 CEST


Il giorno mar, 13/05/2008 alle 23.45 +0200, Mario ha scritto:
> Ho trovato l'inghippo: in effetti il "fix maldestro" è stato fatto poi
> modo diverso (con gli stessi danni) e l'ho alla fine localizzato in un
> file diverso 'md_rand.c', eccovelo:
> 
> /*
>  * Don't add uninitialised data.
>                 MD_Update(&m,buf,j);
> */

Per adesso su planet.debian.net c'è fervore: i debian-maintainer si
sentono attaccati e cercano di difendersi. 
La situazione è strana e tutti dicono pure cose senza senso: in realtà
il codice di OpenSSL contiene il seguente punto:

#ifndef PURIFY
                MD_Update(&m,buf,j); /* purify complains */
#endif

in cui, per aumentare l'entropia, viene aggiunto ANCHE un vettore non
inizializzato della memoria. Questo chiaramente non è l'unica fonte di
randomness utilizzata (vengono utilizzati i vari
device /dev/random /dev/urandom se disponibili) ma viene messa nel mezzo
pure questa. In realtà questo accorgimento (anche non condivisibile) può
essere disabilitato con l'apposita direttiva di compilazione
'PURIFY' (prevista dagli sviluppatori OpenSSL) per evitare questo tipo
di warning. 
Valgrind ha rilevato questa anomalia (quando compilato senza PURIFY) è
ha segnalato anche una riga in un'altra procedura (utilizzata dalla
prima) che è esattamente uguale (non ho capito se è un errore di
valdrind):

	MD_Update(&m,buf,j);

Il maintainer debian (dopo averne parlato minimamente sulla ML di
OpenSSL su cui, a dir la verità, non ha ricevuto dei chiarimenti
soddisfacenti http://marc.info/?l=openssl-dev&m=114651085826293&w=2 )
alla fine ha disabilitato del tutto la linea di cui sopra:

#ifndef PURIFY
#if 0 /* Don't add uninitialised data. */
                MD_Update(&m,buf,j); /* purify complains */
#endif
#endif

ma ANCHE l'altra linea relativa all'altra procedura:

/*
 * Don't add uninitialised data.
                MD_Update(&m,buf,j);
*/

Questo a mio modo di vedere ha annullato l'effetto della procedura
ssleay_rand_add() in cui era impiegata. 

Mia opinione: la colpa non sta da una parte sola, il maintainer ha
sicuramente peccato di incuria nell'applicare una patch che coinvolgeva
un processo che non era del tutto certo di capire, ma anche gli
sviluppatori openssl non sono stati esaurienti nel commentare il post
sulla ML (non notando il riferimento anche alla seconda istruzione) e
potevano sicuramente commentare meglio il loro codice. Gli ho dato
un'occhiata: il codice non è commentato come si deve e anche chi ha un
background tecnico non sempre riesce a seguire la logica di quel che sta
succedendo. IMHO

Saluti,
Mario




Maggiori informazioni sulla lista Solira