Bug SSL/TLS su iOS e OS X ( #gotofail ): il punto in 12 FAQ

Venerdì sera Apple ha rilasciato gli aggiornamenti 7.0.6 e 6.1.6 per iOS, al fine di risolvere un singolo bug di sicurezza.
Quel bug, relativo alle connessioni sicure SSL/TLS utilizzate da iOS, è tutt’altro che secondario, perché rende possibile degli attacchi Man In The Middle grazie ai quali un malintenzionato connesso alla medesima rete Wi-Fi può dirottare una connessione sicura (come quella con il sito di una banca, ad esempio) e intercettare i dati dell’utente.
La stessa falla di sicurezza è presente su Safari in OS X Mavericks 10.9.1 e Apple ha fatto sapere che un fix sarà disponibile al più presto.
La tempistica dell’introduzione del bug (presente da iOS 6, rilasciato nel 2012) ha fatto insospettire più di un esperto, perché potrebbe essere stato usato dalla NSA nell’ambito dell’operazione PRISM.
Di seguito trovate alcune FAQ di approfondimento per mettere meglio a fuoco la questione.

1 – In cosa consiste la falla?

Il bug risolto dai due aggiornamenti di venerdì causava l’erronea esecuzione dei controlli sulla catena dei certificati che devono essere verificati affinché una connessione fra il dispositivo e un sito remoto sia decretata sicura.
Una linea di codice in più faceva sì che il controllo sulla crittazione della connessione venisse saltato sempre e comunque, evitando in questo modo qualsiasi controllo sul “matching” della chiave privata remota con la chiave pubblica riportata dal certificato.

2 – Quali attacchi rende possibile?

La falla rende possibili degli attacchi di tipo Man in The Middle. Un malintenzionato connesso alla stessa rete Wi-Fi della vittima potrebbe intercettare il traffico “sicuro” fra il dispositivo obbiettivo ed un sito sensibile (posta elettronica, banking remoto ecc…) e fornire un certificato falso con una chiave privata casuale o assente senza che il dispositivo si accorga di nulla.
Da questa “posizione privilegiata” il malintenzionato potrebbe condurre un semplice attacco silenzioso volto a rubare dati sensibili della vittima.

3 – Quali sono i dispositivi a rischio?

Tutti i dispositivi iOS su cui gira una versione di iOS precedente alla 6.1.6 nel caso di iOS 6 e alla 7.0.6 nel caso di iOS X.
Anche Mavericks 10.9.1 utilizza una libreria analoga che contiene il medesimo bug. Una patch per OS X non è ancora stata rilasciata nel momento in cui scrivo, ma Apple ha fatto sapere che arriverà presto.

4 – Significa che iOS e OS X Mavericks 10.9.1 (non patchato) sono sensibili ad attacchi remoti?

Si e No. La “posizione privilegiata” di cui si parla nei documenti ufficiali ha un significato ben preciso: l’attacco deve essere condotto sulla stessa rete cui è connessa anche la vittima. Una Wi-fi aperta è un esempio classico. Tuttavia un malintenzionato che avesse accesso alle reti degli operatori di telefonia (ipotesi assai estrema) potrebbe sfruttare lo stesso tipo di falla. Per le implicazioni più complottistiche vi rimando all’ultima domanda.

5 – Come faccio a sapere se il mio dispositivo è vulnerabile?

Gli iPhone e gli iPad aggiornati ad iOS 6.1.6 e iOS 7.0.6 sono sicuri. Per sapere se il dispositivo da cui state navigando non è sicuro aprite il sito GoToFail.com da iPhone, iPad, iPod touch o Safari su OS X. Il sito contiene anche una breve spiegazione del test che viene condotto.

6 – Devo stare attento alle Wi-Fi pubbliche o non protette?

Si. Se la navigazione avviene da un dispositivo iOS non patchato o da un Mac con OS X Mavericks 10.9.1 utilizzando Safari è meglio non connettersi ad alcun sito che preveda l’inserimento di dati sensibili. In ogni caso per i dispositivi iOS la soluzione consiste nell’aggiornare iOS al più presto.

7 – Se uso un altro browser o un’altra app su iOS non patchato sono al sicuro?

No, perché la maggior parte delle applicazioni utilizzano la libreria crittografica utilizzata da Safari, Mail e le altre applicazioni Apple. E’ esattamente in quella libreria che si annida il bug. Di nuovo: tutto torna sicuro, anche le applicazioni non Apple, dopo l’aggiornamento.

8 – Se uso un altro browser su OS X 10.9.1 sono al sicuro?

Si, su OS X Mavericks 10.9.1 (unica versione del sistema operativo dei Mac sensibile alla falla) il problema è limitato a Safari e probabilmente alle altre applicazioni Apple (non è detto che non siano sicure, però, perché altre app sensibili a questa falla, come iMessage e Mail, utilizzano ulteriori layer di sicurezza).
Se provate il test al punto

9 – Altre versioni di OS X sono sicure?

Si, il bug, per qualche ragione che non possiamo conoscere, è stato introdotto solamente in OS X 10.9.1. Le altre versioni di OS X sono sicure.

10 – Perché la falla è stata chiamata #gotofail?

Perché la linea di codice che genera la falla riporta questo comando: “goto fail;”. Chi volesse una breve spiegazione tecnica del problema può leggere l’ultimo punto di questa lista.

11 – Perché Apple non si è accorta del bug?

Questa è la proverbiale domanda da un milione di dollari. La risposta è che Apple, in realtà, se n’è accorta eccome. Nei documenti di sicurezza che descrivono il bug non vi è riferimento ad una segnalazione esterna della falla. Significa che il bug è saltato fuori internamente. Questo non esclude automaticamente che vi potessero essere altri soggetti esterni a conoscenza della falla. Allo stato attuale non è neppure possibile sapere se la falla è stata effettivamente sfruttata per condurre degli attacchi.

Il motivo per cui un bug così triviale sia finito in una libreria così importante è il vero nocciolo della questione. C’è chi sostiene la tesi dell’incapacità di uno o più ingegneri Apple, chi parla di scarsa attenzione in fase di Quality Assurance, chi fa notare che il problema si sarebbe potuto evitare scrivendo del codice migliore e chi infine sostiene che il bug possa essere stato inserito volontariamente. Il che ci porta alla domanda immediatamente conseguente.

12 – Perché si parla di coinvolgimento della NSA?

Questa falla di sicurezza è stata introdotta su iOS con la release di iOS 6 ed è rimasta aperta su iOS 6 e iOS 7 fino alla release delle due patch di venerdì. Non era presente nelle precedenti versioni di iOS.

Non serve essere dei teorici del complotto per notare una strana coincidenza di date:

• Il 24 settembre 2012 Apple rilascia iOS 6
• In una slide top-secret rivelata da Edward Snowden la NSA fa risalire ad “ottobre 2012” l’aggiunta di Apple al progetto PRISM

Secondo queste indicazioni, in altre parole, Apple ha pubblicato iOS 6 e da quel momento la NSA ha avuto la possibilità di penetrare nei dispositivi di Cupertino. Le due affermazioni sono prove prettamente indiziali e non c’è un collegamento diretto al di fuori della collocazione cronologica. Non è abbastanza per trarre delle conclusioni, qualsiasi esse siano ma ce n’è abbastanza per alimentare comprensibili illazioni complottiste.

Secondo John Gruber, che ha scritto dell’argomento, i “livelli di paranoia” sono 5, di grado crescente:

• a) La NSA non era a conoscenza della falla
• b) La NSA era a conoscenza della falla, ma non l’ha mai utilizzata
• c) La NSA era a conoscenza della falla e l’ha utilizzata
• d) La NSA ha impiantato volontariamente la falla
• e) Apple, complice con la NSA, ha aggiunto il bug

Il punto d) implica la presenza di una quinta colonna all’interno di Apple, qualche ingegnere sul libro paga della NSA. Una vera e propria talpa, insomma. Il punto e), invece, presuppone una totale e volontaria attitudine a mentire da parte della dirigenza Apple. E’ francamente molto poco probabile da un punto di vista prettamente logico.

Primo perché ci sarebbero metodi meno triviali ed evidenti per nascondere un simile bug; secondo perché Apple, se scientemente coinvolta, avrebbe potuto ideare meccanismo molto più oscuri per collaborare con la NSA. In entrambi i casi, Apple avrebbe scelto di seguire una strada rischiosa e compromettente senza alcun ritorno per la propria bottom line. Nulla che avrebbe senso anche soltanto analizzando la situazione dal punto di vista del business, senza tirare in ballo l’impegno di trasparenza che l’azienda sta mantenendo pubblicamente.

L’opzione d) è particolarmente “borderline” e per quanto complottista ci sono buone possibilità che all’interno di Apple siano in corso indagini e controlli per verificarne la verosimiglianza, o anche solo per capire come quel bug sia potuto finire in quella libreria. A questo proposito, se volete saperne di più, vi rimando all’appendice, qui sotto.

Appendice: Il bug nel codice

L’aspetto più curioso di tutta questa faccenda è che un problema di sicurezza così rilevante è generato solamente dalla cattiva gestione di un “banale” costrutto condizionale all’interno del codice della libreria compromessa.

L’errore, per chi sa anche soltanto leggiucchiare il codice, è abbastanza evidente:

static OSStatus
SSLVerifySignedServerKeyExchange(SSLContext ctx, bool isRsa, SSLBuffer signedParams, uint8_t signature, UInt16 signatureLen)
{
OSStatus err;
…
if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
    goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
    goto fail;
    goto fail;
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
    goto fail;
...

fail:
SSLFreeBuffer(&signedHashes);
SSLFreeBuffer(&hashCtx);
return err;
}

I tre if indicano fisicamente i tre passaggi di verifica della firma del certificato. Fra la validazione del certificato (secondo if) e la verifica della firma c’è un goto fail; di troppo che esclude totalmente il terzo if e permette quindi di utilizzare una firma qualsiasi per un certificato di sicurezza, perché tanto quella firma non viene mai verificata.

In altre parole quando l’esecuzione arriva al secondo if, viene verificata la legittimità del certificato. Se il certificato non è valido si innesca il primo goto fail;; se invece il certificato è valido, l’esecuzione passa oltre e incontra di nuovo un goto fail; che provoca il salto dell’ultima parte del controllo.

Quel secondo goto fail; non ci dovrebbe proprio essere e non si capisce ancora come sia potuto finire lì.
Molti esperti in ogni caso hanno fatto notare che sarebbe bastato utilizzare le parentesi graffe dopo l’if (come da best practices) per evitare il problema. Altri, più esigenti, indicano invece nell’utilizzo “pigro” del comando goto, tipico di un pessimo stile di scrittura del codice, il vero colpevole.

(Se i più esperti fra i nostri lettori notassero qualche imprecisione nell’esposizione divulgativa del problema in questo articolo sono pregati di segnalarle nei commenti, qui sotto)