[Soci SLIP] Red Hat, Ubuntu, and Arch Linux patch Linux kernel exploit

[Lucio Crusca]

In data domenica 20 gennaio 2013 01:00:17, loredana ha scritto:
> La tua wheeze sarà stata vulnerabile come altre distribuzioni, ma la
> data di quell'articolo è gennaio 2012. Non so come funzioni la
> sicurezza con debian testing. Tempo di scoprirlo? 

Te lo dico io: quasi non c'è. Di Debian in ogni istante ne esistono 4 "gusti": 
experimental, unstable detta anche "sid", testing e stable. Sostanzialmente la 
sicurezza su Debian è pilotata da stable. Partiamo da lì così si capisce. 
Diciamo che in Debian stable c'è una versione di Firefox, diciamo la 10.0, che 
ha 3 funzionalità (chiamiamole A, B e C). Debian ad un certo momento rilascia 
una versione stabile del sistema operativo, diciamo la versione 6 di Debian, 
che contiene questo Firefox.

Passa un anno. Gli sviluppatori della Mozilla Foundation, che mantengono lo 
sviluppo di Firefox, sono arrivati alla versione 12 del famoso browser, il 
quale ora, rispetto alla 10, contiene una nuova funzionalità che chiamiamo D. 
Gli utenti di Debian stable continuano ad usare la "vecchia" 10, perché quella 
è la politica di aggiornamento del team di Debian, ovvero le nuove versioni 
dei singoli software arrivano solo assieme ad una nuova versione dell'intero 
sistema operativo. Una nuova versione di Debian stable però non è ancora 
pronta.

A questo punto gli sviluppatori della Mozilla Foundation scoprono che la 
funzionalità B del loro browser Firefox è insicura, in tutte le versioni dalla 
9 in avanti: rilasciano quindi una patch in modo da renderla sicura, ma questa 
patch la rilasciano solo per la versione 12 di Firefox, ovvero la più recente.

Gli sviluppatori di Debian hanno ora il compito di estrarre dalla versione 12 
"upstream" (ovvero versione 12 ufficiale della Mozilla Foundation) il pezzo di 
codice (la patch) che corregge il problema di sicurezza della funzionalità B e 
riadattarlo alla versione 10 che è inclusa in Debian stable. Non possono 
semplicemente aggiornare il browser alla versione 12 per le suddette politiche 
di aggiornamento (che condivido): se lo facessero, porterebbero in Debian 
stable la nuova funzionalità D, che un anno prima, al tempo del rilascio del 
sistema operativo, non esisteva e quindi non ha passato i test qualitativi di 
Debian stable.

Per quanto riguarda Debian experimental ed unstable "sid" però tali test 
qualitativi sono molto meno restrittivi, quindi la scelta in tal caso è quella 
di prendere la nuova versione 12 di Firefox che include già la patch.

E finalmente arriviamo a Debian testing, che attualmente porta il nome 
"Wheezy" e che sarà il nome della nuova futura Debian stable. Debian testing è 
la versione di Debian in cui entrano i software candidati per la futura nuova 
stable. Un software deve seguire un iter di controlli qualità via via più 
restrittivi per arrivare in Debian stable, a partire dall'inclusione in 
experimenta, poi unstable e infine passare in testing: questo è il penultimo 
passo di tale iter (l'ultimo è il rilascio ufficiale come software facente 
parte di Debian stable). Le patch di sicurezza in testing ci mettono quindi un 
po' più di tempo ad arrivare, perché arrivano assieme alle nuove versioni di 
unstable, che però devono arrivare in testing secondo regole che non 
riguardano la sicurezza, ma la qualità in termini di funzionamento (o almeno 
così ho capito io che funziona, ma non scommetteteci, magari mi sbaglio).

Inoltre, tornando a parlare del vero problema di sicurezza del kernel e non di 
un'ipotetica funzionalità B, in questo periodo particolare Debian testing è in 
stato "freeze" (congelata), ovvero nessuna nuova versione di software entra in 
testing, fino a quando la attuale testing non avrà passato tutti i controlli 
di qualità per diventare la nuova Debian stable (in altre parole siamo vicini 
al rilascio di una nuova Debian stable). Non so come funzioni la sicurezza in 
questo periodo, ovvero non so se la sicurezza venga già gestita come se fosse 
stable o se verrà gestita come stable solo dopo il rilascio ufficiale, magari 
avendo già pronte le patch da rilasciare contestualmente. Potrei provare a 
fare un aggiornare il sistema per scoprirlo in effetti...

 
> > No questa volta hai ragione tu. Mi sa che gli incubi stanotte li avrò
> > io...
> > 
> > :)
> 
> Questa volta? :)

Non iniziare... sai che non mi tiro indietro :)

Piuttosto, alla luce di quanto mi hai fatto notare, il problema non grosso, ma 
enorme, è per i possessori di uno smartphone o tablet con Android 4, perché 
nella maggior parte dei casi dipendono dal produttore dello smartphone per 
avere un aggiornamento al loro sistema e questi aggiornamenti, a seconda del 
produttore, possono metterci dei mesi ad arrivare e a volte non arrivano 
affatto. Il problema è che se mai dovesse verificarsi un fenomeno malware su 
Android a causa di questa vulnerabilità, i media non esiteranno a dare la 
colpa a Linux, perché fa più notizia che darla a Samsung o chi altri siano i 
veri colpevoli (Linux sarebbe solo la causa tecnica della vulnerabilità, ma la 
colpa e responsabilità di un sistema non aggiornato ovviamente sta altrove).