Tutta la verità sul bug TLS/SSL di iOS 7 e iOS 6 – c’entra l’NSA?

Redazione Guide, In Evidenza Lascia un commento

Apple ha recentemente rilasciato un aggiornamento, iOS 7.0.6, per tappare una falla di sicurezza che colpiva la crittografia TLS/SSL del sistema operativo per i suoi dispositivi mobili.

In realtà, secondo le ultime indiscrezioni, anche Mac OS X ne sarebbe afflitto, con gli utenti che però starebbero ancora aspettando l’aggiornamento.

Si tratta di un bug importante, che permette ai malintenzionati di operare come se la crittografia SSL/TLS non fosse implementata, aprendo questioni di sicurezza che tutti possono immaginare.

A mettere più carne al fuoco, come se il problema non fosse di per sé già piuttosto grave, arrivano le dietrologie (che forse poi tanto dietrologie non sono) che vorrebbero collegare il problema con il recente scandalo NSA.

L’ente per la sicurezza nazionale americano, come ha dimostrato Snowden, era in grado di superare con una certa facilità le misure di sicurezza dei principali sistemi operativi in circolazione, iOS incluso, e in molti cominciano a pensare che questo bug contenuto in iOS 6 e 7 non sia poi frutto di un errore, ma mezzo di un disegno ben preciso.

Per una graffa Martin perse la cappa

La cappa forse la perderà però qualcuno che lavora a Cupertino. L’errore nel codice è di una banalità sconcertante, e sono in molti a non credere che sia possibile che un errore tanto macroscopico sia riuscito a sfuggire ai test di Apple e dei suoi ingegneri.

Il codice recita quanto segue:

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;

Il problema è nel goto che abbiamo evidenziato nella porzione di codice sopra riportata. Nonostante sembri parte del secondo if, in realtà la condizione si risolve con il primo goto fail; il secondo non ha nessuna condizione che gli permetta di attivarsi o non attivarsi, e quindi si attiva, per dirla così e per far capire un po’ a tutti, sempre.

Un errore che, dicono i fan delle parentesi graffe, si sarebbe potuto risolvere con uno stile di programmazione differente (e più ordinato, aggiungiamo noi), utilizzando per la condizione if una parentesi graffa che avrebbe reso l’errore ancora più evidente.

C’entra l’NSA?

Il terrore di tutti è che c’entri l’NSA. L’errore è stato infatti introdotto con iOS 6 e non iOS 7, in tempi che coinciderebbero con quelli di cui ha parlato insistentemente Snowden. Un errore macroscopico, e che apre 5 possibili scenari, così come ha riportato il sempre ottimo Gruber di DaringFireball

L’NSA non era a conoscenza della vulnerabilità
L’NSA era a conoscenza della vulnerabilità e non l’ha sfruttata
L’NSA era a conoscenza della vulnerabilità e l’ha sfruttata
L’NSA ha inserito la vulnerabilità tramite un uomo di fiducia dentro Apple
L’NSA e Apple hanno collaborato per inserire la vulnerabilità

Anche noi, come Gruber, propendiamo per la terza, non volendo fare troppo i paranoici. Certo è che per sistemi attraverso i quali passano ogni giorno le nostre informazioni personali, relazionali e anche bancarie ci aspettiamo legittimamente un po’ più di attenzione.

Perché sarà anche vero che Apple fa ancora impallidire Android per quanto riguarda il numero di vulnerabilità e malware in circolazione, ma è altrettanto vero che da Cupertino, pagando per prodotti premium, ci aspettiamo sempre il meglio.