Sasser demolisce il mito delle patch

Siamo alle solite. A distanza di meno di un anno dal disastro di Blaster, arriva Sasser, un altro worm che paralizza e devasta milioni di computer Windows (XP/2000/Server 2003), lasciando intatti Mac, Linux, e i venerabili Windows 95 e 98. Alla faccia del progresso tecnico di casa Microsoft e del suo trustworthy computing.

Oggi come allora, la patch che consente di evitare l’infezione è già disponibile da tempo. Così Microsoft può scaricare la colpa sugli utenti: “Ehi, noi la patch l’abbiamo pubblicata, se poi gli utenti non la installano, non possiamo farci niente.”

Troppo comodo. È vero che gli utenti hanno una parte di responsabilità, perché non hanno aggiornato il proprio sistema operativo con Windows Update (ma provateci voi a scaricare tutte le patch Microsoft con un modem a 56K), ma rifilare la colpa agli utenti distrae dal vero problema. In realtà il principale colpevole è il meccanismo di produzione del software, troppo adagiato sulla facile scappatoia delle patch. Perché prendersi la briga di scrivere codice robusto? Tanto c’è sempre la patch che risolve tutto. E così Microsoft ci ha abituato alla patch del mese. Accettereste che un televisore avesse bisogno di riparazioni ogni mese?

Peccato che casi come Blaster e Sasser dimostrano che in realtà le patch facilitano il lavoro dei vandali. Quando Microsoft annuncia una patch, per forza di cose deve fornire alcuni dettagli del problema che viene corretto. È un principio generale che vale anche per gli altri sistemi operativi. Ma quei dettagli sono preziosi indizi per gli aggressori. In sostanza, l’annuncio di una patch indica con precisione ai vandali dove si trova una vulnerabilità sfruttabile in tutti i computer che non sono ancora stati patchati. E siccome la natura umana è quella che è, di computer non patchati ce ne sono tanti e ce ne saranno sempre tanti, anche nelle aziende e nei siti istituzionali che dovrebbero avere un po’ più di sale in zucca, visto che custodiscono i nostri dati.

Posso avere un aiutino?

Faccio un paragone automobilistico per chiarire il problema. Supponiamo che la Fiat annunci che tutte le sue auto più recenti hanno un difetto nella serratura, che consente a chiunque di entrare scavalcando l’antifurto. Niente panico: generosamente, la Fiat mette a disposizione gratuita un kit di riparazione che rimedia al difetto. Fine del problema?

Non proprio. Ovviamente l’annuncio non passa inosservato anche nel mondo dei ladri d’auto, che a quel punto sanno dell’esistenza del difetto (se non ne erano già al corrente) e corrono a procurarsi il kit, dal quale dedurranno facilmente la natura esatta della vulnerabilità, ringraziando la Fiat per l’involontario “aiutino”. Sanno che una bella fetta di automobilisti non verrà a sapere dell’annuncio o non troverà il tempo o la voglia di procurarsi il kit, e resterà quindi vulnerabile. Senza l’annuncio Fiat, i ladri dovrebbero ingegnarsi a trovare il modo di scassinare le auto; con l’annuncio, la tecnica di furto viene servita loro su un piatto d’argento.

Ecco perché agli annunci di patch spesso fanno seguito attacchi informatici devastanti. Microsoft annuncia una patch per una falla RPC il 16 luglio 2003; Blaster, che sfrutta esattamente quella falla, arriva venticinque giorni dopo. Microsoft annuncia una patch per il servizio LSASS il 13 aprile 2004; due settimane dopo irrompe Sasser, che utilizza proprio quel difetto del servizio LSASS. Entrambi i difetti erano nascosti in Windows da anni, e la loro scoperta non è stata divulgata prima della disponibilità della patch. Basta ripercorrere la cronologia degli annunci di patch e dei relativi worm per trovare altri episodi analoghi. Coincidenze?

Divulgazione responsabile

Quest’ennesimo fallimento della politica delle patch indurrà sicuramente un profondo esame di coscienza negli addetti ai lavori. Per anni si è argomentato che è necessario divulgare le falle sempre e comunque, non appena vengono scoperte, perché tanto i Grandi Cattivi (i black hats) già le conoscono, e se non vengono pubblicizzate i produttori di software tendono a far finta che non esistano e non le sistemano. Gli esempi in questo senso si sprecano e non sono certo circoscritti a Microsoft e neppure al mondo del software per PC.

I produttori di software, dal canto loro, hanno sempre obiettato che la divulgazione di una falla prima dell’esistenza della patch è un atto irresponsabile, perché lascia improvvisamente indifesi gli utenti, e hanno spinto per la responsible disclosure, ossia la “divulgazione responsabile”: lo scopritore della falla (quasi sempre una società diversa da quella che produce il software fallato) la mantiene segreta, comunicandola esclusivamente al produttore del software, e attende l’uscita della relativa patch prima di parlarne in giro. Così è stato fatto sia per Blaster, sia per Sasser, e guardate che disastro ne è venuto fuori.

Il vantaggio della responsible disclosure è che mette i produttori di software al riparo da conseguenze legali, perché annunciano il difetto del proprio prodotto e contemporaneamente offrono il rimedio, facendo anche bella figura. Così la palla della responsabilità passa all’utente, ma in termini di contenimento del danno non cambia nulla, perché appena si annuncia una vulnerabilità, gli script kiddie di tutto il mondo, troppo imbranati per scoprire da soli le falle del software, le si avventano contro prima che gli utenti abbiano tempo di patchare.

L’ulteriore alternativa di offrire una patch senza dare dettagli del suo funzionamento, per non fornire indizi ai vandali, è un’illusione. Apple, per esempio, è decisamente laconica nel descrivere le motivazioni delle sue patch, ma non è che cambi molto: come dice Marc Maiffret, chief hacking officer della eEye Digital Security, “non è pensabile di pubblicare una patch senza il relativo advisory [rapporto di avviso], perché i cattivi guarderanno il codice binario [della patch] e troveranno la falla”. Il contenuto della patch medesima, insomma, è comunque un’indicazione più che sufficiente anche in assenza di spiegazioni della falla.

E allora che si fa?

La sicurezza è come una cipolla

Sperare che i produttori di software sfornino codice perfetto e senza falle, evitando quindi le patch, è assurdo. Le patch ci saranno sempre, in tutti i sistemi operativi. Viene spontaneo chiedersi allora come mai non sentiamo parlare di attacchi informatici su vasta scala contro gli utenti Mac o Linux. È solo una questione di quote di mercato a cifra singola, per cui i vandali non li considerano un bersaglio interessante, o c’è sotto qualcosa?

La differenza fondamentale è la stratificazione della sicurezza adottata dai sistemi operativi alternativi a Windows. La sicurezza viene ottenuta creando più di una barriera alle intrusioni: così, se una protezione è difettosa, restano in piedi le altre. È un approccio “a cipolla”, per usare la similitudine massacrata da un ormai mitico articolo sulla sicurezza informatica, ed è qui che Microsoft sinora ha inciampato.

Per esempio, in Linux e in MacOS non ci sono servizi in ascolto sulle porte per default come ci sono in Windows: tutti i loro boccaporti sono chiusi, per cui eventuali falle non sono sfruttabili dall’esterno. Invece, Windows è amicone con tutti e se un vandalo bussa alla sua porta, la trova aperta. È per questo che Blaster e Sasser possono agire senza dover ricorrere ad allegati infetti. È per questo che Windows ha portato l’informatica a nuove vette di ridicolo quando (con Blaster) è diventato sufficiente collegare a Internet un PC Windows, fresco di fabbrica, per infettarlo automaticamente. Provate a spiegarlo all’utente medio: pensa che lo stiate prendendo in giro.

Certo, anche Windows è “blindabile” come i suoi concorrenti, ma la differenza è che per blindarlo occorre lo sforzo attivo dell’utente, che spesso non è all’altezza del compito, mentre Linux e Mac sono già blindati in partenza. Per difendersi dai futuri attacchi come quello di Sasser ancor prima che sia resa disponibile la relativa patch, un utente Windows deve installare un buon firewall o attivare quello integrato nel sistema operativo Microsoft, che astutamente è fornito disattivato; un utente Linux o Mac ce l’ha già attivo di default.

Bisogna quindi che l’utente Windows impari ad aggiungere al suo sistema operativo qualche strato di protezione aggiuntiva, a partire dal firewall e dall’antivirus, e a usare religiosamente Windows Update. Bisognerà attendere l’arrivo, più volte rimandato, del Service Pack 2 di XP per vedere finalmente implementato il concetto di sicurezza intrinseca su più livelli anche in Windows: firewall attivo di default e servizi disattivati di default. Meglio tardi che mai, ma quanti scaricheranno un aggiornamento da 273 megabyte?