Cold Boot Attacks on Encryption Keys

Riassunto:
Contrariamente a ciò che si crede comunemente, le DRAM usate nella maggior parte dei moderni computer, trattengono i propri contenuti per un periodo che va da pochi secondi ad alcuni minuti dopo che è stata tolta l’alimentazione, anche a temperature operative e anche se rimosse dalla scheda madre. Sebbene le DRAM diventino meno affidabili quando non vengano “rinfrescate” (riscritte con il medesimo contenuto, ndr.), queste non vengonono imediatamente cancellate e i loro contenuti persistono per un tempo sufficiente per l’acquisizione malevola (o forense) di immagini utilizzabili dell’intero sistema. Abbiamo mostrato che questo fenomeno limita l’abilità di un sistema operativo di proteggere la chiave crittografica da un aggressore che abba un accesso fisico (al computer, ndt.). Abbiamo usato reboot a freddo (cold reboot, ovvero quando si spegne il computer togliendo la corrente all’improvviso, senza eseguire uno shutdown, ndt.) per imbastire attacchi ai più popolari sistemi di crittazione di dischi – BitLocker, FileVault, dm-crypt, e TrueCrypt – senza usare materiali o periferiche speciali. Abbiamo caratterizzato sperimentalmente l’estensione e la predicibilità di ciò che rimane in memoria e abbiamo riferito che i tempi di permanenza possono venire incrementati in maniera sensibile adottando semplici tecniche. Offriamo nuovi algoritmi per trovare le chiavi crittografiche nelle immagini della memoria e per correggere gli errori causati dal decadimento dei bit. Sebbene discutiamo (nella ricerca in pdf che si trova sul sito, ndt.) di diverse strategia per mitigare questi rischi, non conosciamo alcun rimedio di semplice applicazione che li possa eliminare.

Center for Information Technology Policy – Princeton University

[Via Ministry of Intrigue]

Qmail finalmente in pubblico dominio

Shhhhh….pare che D. J. Bernstein si sia deciso a rilasciare in pubblico dominio tutti i suoi lavori, passati e a venire. Ciò implica anche l’ottimo Qmail server di posta elettronica noto per la sua sicurezza, velocità e affidabilità.

La stoffa di Bernstein si vede fino all’ultimo bit di codice, creato per fornire una elaborazione a stadi in cui ogni compartimento tratta il precedente come untrusted, fornendo quindi un ambiente un po’ paranoico, ma decisamente poco vulnerabile a eventuali attacchi.

Il focus sulla sicurezza è sempre stato, dopo tutto, ciò che ha da sempre attirato l’attenzione dell’autore che finora si è sempre rifiutato di rilasciare i sorgenti in una qualsivoglia licenza che ne permettesse la libera modifica e la sua ridistriuzione con le modifiche applicate.

Questa, quindi, la ragione principale per il fiorire, nel tempo, di decine e decine di patch che ne modificassero i sorgenti: ogni cambiamento doveva finora rimanere confinato in una patch esterna, applicabile a rischio e responsabilità dell’utente.

Il risultato è che, mancando uno sviluppo ufficiale di Qmail da ormai molti anni, i vari programmatori ne hanno esteso le funzionalità di base a colpi di patch esterne, dando origine a un dedalo di modifiche decisamente difficile da gestire: non solo si devono scegliere le patch, ma bisogna applicarle in un ordine preciso, altrimenti le varie modifiche vanno a “pestarsi i piedi” e rendono impossibile la compilazione del programma.

Da ciò, anche, la nascita di progetti come netqmail, ovvero Qmail già fornito di alcune patch. Lodevole, ma non la soluzione migliore. Ormai il codice di base di Qmail risente degli anni, non tanto per le prestazioni o la sicurezza, ma per le nuove funzionalità apparse sulla scena dopo il suo rilascio e volte a estendere le capacità dei server smtp, vedi SPF per esempio, mai incluse nel codice originale.

Ora, con il rilascio in pubblico dominio di Qmail la speranza che le varie patch confluiscano omogeneamente nel codice principale non sono poi peregrine. Occhio, però, a ciò che Bernstein stesso dice nella pagina dedicata alle informazioni rivolte a chi voglia redistribuire Qmail:

Se siete dei distributori, dovreste iscrivervi alla mailing list qmaildist.

Io pongo il pacchetto qmail (in particolare, qmail-1.03.tar.gz, con MD5 checksum 622f65f982e380dbe86e6574f3abcb7c) in pubblico dominio. Siete liberi di modificare il pacchetto, distribuirne versioni modificate, etc.

Ciò non significa che le modifiche siano incoraggiate! Per favore, prendetevi del tempo per assicurarvi che la vostra distribuzione di qmail supporti esattamente la stessa interfaccia usata da chiunque altro. In particolare, se spostate dei file, per favore introducete dei link simbolici dalle posizioni originali, così che non porterete per leggerezza al mal funzionamento di quegli script che funzionano da ogni altra parte.

Su Google trovate il video in cui D. J. Bernstein annuncia il rilascio in pubblico dominio dei suoi lavori.

VoIP e NAT – Il protocollo STUN, parte seconda

Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) (STUN), è un protocollo leggero che consente alle applicazioni di scoprire la presenza e la tipologia di NAT e firewall (frapposti, ndt) tra loro e l’Internet pubblica. Fornisce inoltre alle applicazioni la capacità di determinare gli indirizzi pubblici del Protocollo Internet (IP) loro allocati dal NAT. STUN funziona con molti tipi di NAT e non richiede da parte loro alcun tipo di comportamento speciale. In forza di ciò, consente a un’ampia gamma di applicazioni di funzionare attraverso l’infrastruttura NAT (pre)esistente.

E’ con l’abstract della RFC 3489 che riprendiamo in mano il filo del discorso intrapreso nella prima parte di questa lunga digressione, focalizzando fin da ora quale sia lo scopo pratico per il quale viene utilizzato il protocollo STUN (RFC 3489): consentire alle applicazioni che facciano uso di pacchetti UDP (STANDARD 00006) l’attraversamento di firewall e NAT (Network Address Translation – RFC 3022). Non si pensi, però, che STUN sia la soluzione a qualsiasi problema incontrato da un’applicazioni che sia segregata da un firewall o da un NAT. Tutt’altro, come viene ben evidenziato dal primo paragrafo della RFC 3489:

Questo protocollo non è una panacea per i problemi associati al NAT. Non consente connessioni TCP (STANDARD 00001) in entrata attraverso il NAT. Permette l’attraversamento del NAT in entrata per i pacchetti UDP, ma solo attraverso un sotto insieme dei (diversi ndt) tipi di NAT esistenti. In particolare, STUN non consente pacchetti UDP in entrata attraverso NAT simmetrici (definiti in seguito), comuni nelle grandi aziende. Le procedure di scoperata adottate da STUN sono basate sulle assunzioni (derivate, ndt) dal modo in cui NAT tratta UDP; queste assunzioni possono risultare non valide nella pratica nel momento in cui vengono introdotti nuove periferiche NAT. STUN non funziona quando viene utilizzato per ottenere un indirizzo (utile a, ndt.) comunicare con un nodo che sia dietro lo stesso NAT. STUN non funziona quando il server STUN non è nello stesso reame di indirizzi comuni condivisi. Per una discussione più completa discussione dei limiti di STUN, vedere la Sezione 14.

Tutto il discorso ruota quindi intorno al gioco di “invisibilità” introdotto dal NAT, specialmente quello simmetrico, come risulta evidente dalla definizione di quest’ultimo data nella prima parte di questo post:

Symmetric: Un Symmetric NAT è qualcosa di “unico”: come nel full nat, una connessione originata da una IP/PORTA interna verso un IP/PORTA esterna avrà una mappatura IP/PORTA pubblica sull’interfaccia esterna del router. La differenza risiede nella destinazione e nella “dinamicità” del mapping: ogni volta che o l’IP o la PORTA di destinazione cambiano, verrà utilizzato un mapping diverso sull’interfaccia esterna del router, ovvero una differente combinazione IP/PORTA pubblica. In più, solo l’host esterno che riceve un pacchetto può replicare con un pacchetto UDP verso l’host con indirizzo privato. Questa è una configurazione tipica di una rete aziendale.

E’ un po’ come il gioco della talpa in cui i pacchetti in uscita da un client dietro NAT simmetrico escono di volta in volta da una buca diversa, anche se si tratta sempre della stessa comunicazione, dello stesso soggetto emittente. In questo scenario, il NAT non è in grado di informare gli estremi di una comunicazione dei reali indirizzi e porte assunti da ognuno di questi nel corso di una stessa comunicazione, associazioni dinamiche e mutevoli. E sebbene siano state proposte linee guida per l’implementazione di protocolli NAT safe (RFC 3235), alcune fra le applicazioni più comuni non sono in grado di funzionare all’interno di un NAT. Perché diamo insieme un’occhiata ad alcuni passi della RFC 3235:

Con il NAPT (Network Address Port Translation, ndt), sia gli (indirizzi, ndt) IP che le porte di partenza e di arrivo (di un circuito di dati, ndt) (per TCP e UDP) vengono potenzialmente alterate dal gateway. Stante ciò, le applicazioni che passano solo l’informazione relativa al numero della porta (utilizzata per la connessione a un altro client o server, ndt) funzioneranno con il NAT di base, ma non con il NAPT.

E’ la differenza fra il NAT di base e il NAPT a giocare un ruolo fondamentale. Nel primo, viene alterato dal gateway (solitamente il firewall) unicamente l’IP con cui il client interno viene presentato sulla rete pubblica, mentre con il secondo viene modificato anche il numero di porta utilizzato per la connessione. Ed è sotto questa tipologia, il NAPT, che ricade il NAT simmetrico. Quali sono le tipologie di applicazioni che sono più inclini a non funzionare all’interno di un NAT simmetrico?

  • Applicazioni Peer To Peer. Questo tipo di servizi vedono gli estremi di una connessione coinvolti in una rete in cui i client sono nello stesso tempo server. Per ciò che ci interessa ai fini di questa discussione, la differenza fra un client e un server può essere esemplificata nel seguente schema:
    • Un client genera una connessione verso l’esterno. Non si attende di ricevere una connessione originata dall’esteno a lui diretta;
    • Un server attende una connessione originata dall’esterno, alla quale rispondere. Un server, quindi, rimane in ascolto (binding) su una tupla IP/PORTA, che sarà il punto di arrivo di una connessione iniziata da un client.

    In questo scenario, in cui il client è anche server, un NAT simmetrico che prevede una mappatura dinamica degli IP e delle porte ostacola la raggiungibilità univoca dei servizi: dietro al NAT potrebbero esservi una moltitudine di client che di volta in volta assumono la tupla IP/PORTA del client/server i cui servizi si vorrebbe raggiungere;

  • Applicazioni che richiedono l’utilizzo del protocollo IPSec (Internet Protocol Security, RFC 2401) in modalità end-to-end. I presupposti per cui non può essere utilizzato IPSec quando uno dei due estremi della connessione è all’interno di un NAT sono simili, come viene evidenziato nella RFC 2709, dedicata all’implementazione di IPSec in modalità tunnel combinata con il NAT :
    • Le applicazioni che incorporano informazioni inerenti al reame (di indirizzi privati, ndt) nel payload richiederanno un application level gateway (ALG), affinché il payload abbia senso in entrambe i reami. Tuttavia, le applicazioni che richiedono l’ausilio di un ALG per il routing non possono conseguire una sicurezza end-to-end a livello di applicazione.

Torniamo alla RFC 3235, per capire il perché di questa limitazione:

Le applicazioni dovrebbero, quando possibile, usare dei nomi a dominio pienamente qualificati (FQDN, ndt), piuttosto che gli indirizzi IP, quando fanno riferimento a punti finali (gli estremi di una comunicazione, ndt) IP. Applications should, where possible, use fully qualified domain names. Quando gli estremi sono posti su lati diversi di un gateway NAT, agli indirizzi privati non deve essere consentito di raggiungere l’altro estremo (della connessione, ndt).

Una ragione per questa limitazione viene fornita dalla stessa RFC 3235:

Ad aggravare ulteriormente il problema è la possibilità che vi siano indirizzi duplicati fra i due reami. Se un server offre un collegamento contenente un indirizzi IP privato, tipo 192.168.1.10, la pagina referenziata (si sta facendo riferimento, come esempio, a un server web che offra collegamenti a pagine poste su macchine all’interno del suo reame di indirizzi privati, ndt.) la pagina referenziata può risolvere a un sistema sulla rete locale sul quale si trova il browser (che evidentemente si trova su un altro spazio di indirizzi privati, ndt), ma questo sarebbe un server completamente differente. La confusione che ne risulterebbe per gli utenti finale sarebbe significativa. Le sessioni che coinvolgono implementazioni multiple del NAT (nell’esempio il server web è su una reta in NAT, il client su una diversa rete in NAT), sarebbero eccezionalmente vulnerabili a problemi di riutilizzo di indirizzi di questo tipo.

Per capire intuitivamente il problema, diamo un’occhiata al seguente diagramma: Notato qualcosa? In effetti le due reti private hanno, possono avere, la stessa classe di indirizzi, anche lo stesso subnetting, il che porta a uno spiacevole equivoco nel routing dei pacchetti. Se il client .5 della prima rete (quella più in alto nello schema) richiede al web server 192.168.1.10 della rete più in basso una pagina che si trova su una macchina nella stessa sotto rete del server, 192.168.10.5, il server istruirà il client della prima rete a chiedere una pagina alla macchina 192.168.1.5. Ora, attenzione a ciò che viene detto nella RFC 1918:

Un’azienda che decida di utilizzare indirizzi che non facciano parte dello spazio di indirizzamento definito in questo documento (ovvero voglia utilizzare indirizzi privati, ndt), può farlo senza alcun coordinamento con lo IANA o un Internet registry. Lo spazio di indirizzamento può essere così utilizzabile da molte aziende. Gli indirizzi all’interno di questo spazio privato di indirizzamento saranno unici solo al’interno dell’azienda, o del gruppo di aziende che scelgano di cooperare in questo spazio in modo da comunicare l’una con l’altra all’interno della loro internet privata.

Cosa significa?

Semplicemente che chiunque, al di qua di un router, può utilizzare per la connettività interna alla propria rete degli indirizzi privati, senza alcun coordinamento con le autorità che gestiscono le numerazioni pubbliche. Al contempo, però, gli indirizzi privati non sono “routabili”, ovvero non possono uscire al di là del gateway che collega la rete privata, per esempio una rete aziendale o domestica, a internet.

Tutto ciò porta a due considerazioni interessanti:

  1. L’orizzonte di visibilità di un indirizzamento privato ha come proprio limite il gateway di rete. Semplificando, le macchine possono vedere gli indirizzi privati solo fino al router, al di fuori del quale non hanno cognizione di altri indirizzamenti privati. Quindi, 192.168.1.5 significa una precisa macchina nella stessa rete del client che sta cercando di interrogarla, non su qualche altra rete privata remota;
  2. Più reti private possono utilizzare gli stessi indirizzamenti privati, senza che questo porti a un qualche equivoco. L’indirizzo 192.168.1.5 è “qui”, all’interno della prima rete, per le altre macchine della stessa rete, ma è “qui” anche per le macchine della seconda rete, con due “qui” differenti ma coerenti, ognuno all’interno del proprio spazio di indirizzamento privato.

Date queste premesse, uno sguardo allo schema precedente rende bene l’idea del problema: se il client 192.168.1.5 della prima rete interroga un web server sulla seconda rete, chiamando il suo indirizzo pubblico, e questo rimanda a un collegamento a una macchina con indirizzo 192.168.1.5 nella propria sotto rete, qui, proprio qui, sorge un equivoco: il client 192.168.1.5 della prima rete si vedrà istruire dal web server della seconda rete a cercare una risorsa all’indirizzo 192.168.1.5. Il problema risiede nella limitatezza dell’orizzonte: il server intende puntare alla macchina 192.168.1.5 sulla seconda rete, ma per il client della prima rete 192.168.1.5 ha senso solo nella propria rete. Ergo, il client tenta di interrogare se stesso alla ricerca di una risorsa che è presente solo sulla rete privata remota.

Ecco l’equivoco: ognuno interpreta gli indirizzi privati “a casa propria”, non vede, non conosce altro che non sia sulla propria rete.

Una delle metologie approntate come ausilio per quelle applicazioni che non possono nativamente operare attraverso un NAT è l’Application Level Gateway (ALG), agenti in grado di interfacciarsi con i gateway NAT e consentire ai programmi in funzione su un host di contattare la propria controparte su un host appartenente a un reame di indirizzi differenti. L’implementazione di un ALG può differire notevolmente di situazione in situazione, ponendosi in dialogo diretto con il gateway NAT per gestire gli stati delle connessioni, modificare il payload dei pacchetti per riscrivere la mappatura degli indirizzi e, comunque, garantire tutte quelle operazioni necessarie a mettere in comunicazione servizi appartenenti a reti differenti (end-to-end). Questo tipo di soluzione ha un indubbio vantaggio: non richiede alcuna modifica ai client, ponendosi in maniera del tutto trasparente tra le applicazioni e il NAT. Di contro, la sua implementazione pone dei problemi soprattutto per quanto riguarda la scalabilità e affidabilità di esercizio.

Una soluzione più interessante è rappresentata dallo sviluppo del Middlebox Communications (MIDCOM) protocol (RFC 3304), un protocollo che consente, tramite l’utilizzo di agenti, connessioni fidate (trusted) con le Middlebox (RFC 3303).

Messa in questi termini, la questione appare inintellegibile.

Prima di tutto, cosa è una Middlebox?

In sostanza, si tratta di un apparato di intermediazione di rete che implementa un servizio, come per esempio un NAT o un firewall, ma con una particolarità che lo rende unico rispetto a un tradizionale firewall o NAT: è in grado di delegare in parte o tutta la logica di funzionamento dell’apparato a uno o più agenti MIDCOM.

Ora, pensate a un’applicazione in grado di utilizzare un agente MIDCOM per controllare un NAT e gestirne dinamicamente le funzionalità, in modo da aprirsi dei varchi per consentire le comunicazioni end-to-end tra reami di indirizzamento differenti.

A questo punto, gli intermediari di rete diventano flessibili, si adattano alle esigenze delle applicazioni, superano le rigidità imposte dai protocolli.

Interessante, vero?

Interessante ma poco fattibile. Una rete MIDCOM aware implica la sostituzione degli apparati tradizionali con le nuove versioni in grado di supportarne il protocollo e, specialmente in ambienti enterprise ciò implica un investimento e un grado di ristrutturazione non sempre affrontabili. Inoltre, vi sono casi in cui gli agenti MIDCOM non possono avere visibilità su tutti gli apparati di rete coinvolti, come nell’esempio citato nella RFC 3489: molti provider utilizzano un NAT sulle linee dei clienti residenziali, i quali a loro volta usufruiscono di un secondo NAT sulla loro rete privata. Se l’utente finale può avere visibilità e controllo su una middlebox MIDCOM nella rete privata, agli agenti installati sulle loro macchine non sarà dato alcun controllo sulle middlebox che gestiscono il NAT direttamente sulle infrastrutture del provider stesso.

E’ chiaro che una soluzione univoca per ogni possibile scenario è difficilmente applicabile, per differenti ordini di motivazioni: costi, flessibilità, sicurezza, il che lascia uno spazio progettuale per soluzioni specifiche, pensate e sviluppate per facilitare il funzionamento di singoli protocolli all’interno di ambienti in NAT.

STUN è proprio questo, in termine burocratese è un “facilitatore”, ma questo sarà l’argomento della terza puntata di questo lungo post.

Linux MCE – Un Media Center ambizioso?

linuxmce.gif

LinuxMCE is a free, open source add-on to Ubuntu including a 10′ UI, complete whole-house media solution with pvr + distributed media, and the most advanced smarthome solution available. It is stable, easy to use, and requires no knowledge of Linux and only basic computer skills.

Mmmm….sto per andare a dormire e non ho il tempo di provarlo…ci penserò nei prossimi giorni…  linux-mc-installer.png

Giusto ho scaricato l’installer di questo LinuxMCE, il quale crea sul desktop un’icona che si occupa di caricare il tutto sopra una Ubuntu 6.10. Una volta cliccata l’icona e inserita la password di root, inizia una procedura di installazione assistita, che si occupa di auto rilevare le impostazioni e i componenti. Ah, ovviamente va caricato il CD nel lettore, in modo che l’installer carichi da lì tutto il necessario.

Nei prossimi giorni proverò a vedere cosa si nasconde dietro a questa suite che promette di trasformare il vostro pc in…

  • PVR;
  • Media browser con interfaccia a cubo tridimensionale;
  • Aggregatore di network storage e DMA;
  • NAS per backup centralizzati;
  • Media center;
  • Home Automation;
  • Centralino VOIP e su linee analogiche;
  • HUB di sicurezza per gestire l’antifurto domestico.

Mmmm…mi sembra troppo per essere vero, il che mi rende scettico. Nei prossimi giorni metto su una virtual box e lo provo…

[Via ArsGeek]

Falla di sicurezza in WordPress =< 2.0.5

Riprendo la descrizione data da Securiteam, che si riferisce a un post originale di Michael Daw, traducendola:

Una vulnerabilità nel file templates.php di WordPress consente a un utente con accesso a questo file di inserirvi del codice HTML o javascript arbitrario, che può quindi venire eseguito da altri amministratori.

Ne sono affette tutte le versioni dalla 2.0.5 in giù. Il rimedio è semplice: basta scaricare il seguente archivio, estrarne il file templates.php e utilizzare quest’ultimo per sovrascrivere il file wp-admin/templates.php. Qui trovate la pagina di trac su WordPress.org, dedicata al bug in questione.