La versione 1.2, rilasciata nel 2010 e correntemente in vendita, è sprovvista di storage: può essere utilizzata per l’autenticazione in hotplug su Pluggable Authentication Modules (PAM) con Linux oppure per cifrare e decifrare le e-mail. Crypto Stick supporta anche Windows e Mac OS X. La prossima versione 2.0 aggiungerà una MicroSD.

La documentazione a corredo di Crypto Stick è particolarmente fornita. Il firmware è aggiornabile ed esiste un dispositivo per la compilazione: gli sviluppatori rilasciano continui update del software per supportare il numero più ampio possibile di applicazioni. Ad esempio, seguono i progressi di WebID per l’autenticazione del W3C.

Via | MakeUseOf

I parametri che concorrono a determinare l’efficacia delle password non sono unanimi: Dropbox, introducendo zxcvbn, ha mostrato una tabella con le diverse valutazioni di varie piattaforme rispetto alla stessa combinazione alfanumerica. I risultati sono contraddittori e, ad ogni modo, non esisterà mai uno standard al quale attenersi.

Lunghezza, presenza di caratteri speciali e punteggiatura, discrimine tra lettere maiuscole o minuscole: è meglio utilizzare frasi di senso compiuto oppure combinazioni alfanumeriche arbitrarie? Il dibattito è destinato a non arrivare alle conclusioni. Dropbox ha la sua risposta in zxcvbn che può essere provato con una demo online.

Via | Dropbox

Quindici mesi fa, Tarreau aveva annunciato che – se non avesse ottenuto aggiornamenti di sicurezza per un intero anno – Linux 2.4 avrebbe esaurito le proprie funzioni. Sorprendentemente, dopo la débâcle di kernel.org qualcuno ha continuato a chiedere dove si potessero trovare i sorgenti e/o le patch per quel preciso ramo del kernel.

Allungato il periodo di supporto del kernel per consentire il ripristino del dominio di Linux, Tarreau ha decretato ieri la fine del ramo 2.4. I sorgenti del kernel saranno ancora disponibili nel repository di Tarreau su Git: tuttavia, lo stesso sviluppatore non garantisce d’avere il tempo di risolvere eventuali problemi segnalati.

Via | LWN

Se fosse stata un’altra persona e lo stesso sfogo fosse stato pubblicato su qualche forum di discussione… probabilmente l’utente sarebbe stato riempito d’insulti e, forse, neppure a torto. Tuttavia, poiché parliamo di Torvalds, la questione ha portato a mettere in dubbio le attuali impostazioni di sicurezza dei sistemi multi-utente.

Torvalds non è stato affatto accondiscendente: in un passaggio, propone persino il suicidio come soluzione ai problemi mentali di chi richiede i privilegi d’amministrazione per accedere alla rete, configurare l’orologio o stampare un documento. openSUSE, per quanto mi riguarda, non ha tutte queste responsabilità: Fedora è identica.

E, per non fare un torto a nessuno, Debian o Ubuntu prevedono altrettanto. L’unica differenza tra le distribuzioni è l’utilizzo di su o sudo. Microsoft, prendendo spunto dai sistemi UNIX-like, ha introdotto qualcosa di simile a partire da Vista: è davvero così tremendo inibire l’esecuzione di certe operazioni agli utenti “normali”?

Il numero degli utenti e dei gruppi di sistema su Linux eccede, probabilmente, le reali necessità. Criticare l’intero meccanismo, però, mi sembra eccessivo: una semplificazione potrebbe essere d’aiuto. Uno stravolgimento sarebbe controproducente. Soprattutto, considerando che con delle modifiche Torvalds avrebbe risolto il problema.

Sarebbe bastato, infatti, agire manualmente sui file di configurazione… e attribuire all’account della figlia dei maggiori privilegi. Un’operazione che i membri più pazienti della comunità gli avrebbero consigliato in un forum, se fosse stato un altro. Tutti gli altri si sarebbero limitati a dirgli d’utilizzare i motori di ricerca.

Via | The H Open

Oneiric Ocelot costituisce un’eccezione perché l’ultimo aggiornamento di X.Org sarà incluso soltanto in Ubuntu 12.04 LTS. Il bug è stato risolto, perciò gli utenti di Fedora 16, Debian (Sid) o rolling release dovrebbero aggiornare i pacchetti quanto prima. Nonostante il problema in sé, la vulnerabilità non dipende dallo screensaver.

Il bug deriva dalla gestione dell’input della tastiera e, di conseguenza, il colpevole è xkeyboard-config. L’aggiornamento di sicurezza disabilita temporaneamente il debugging delle funzionalità. Il problema riporta in auge la questione del blocco dello schermo, alternativo allo screensaver. Una soluzione già approntata sui tablet.

Via | Peter Hutterer

SEAndroid supporta sia YAFFS2, il file system utilizzato fino a Gingerbread, sia Ext4. La soluzione prevede alcune delle principali funzioni di SELinux: integra una politica di Type Enforcement (TE) per autorizzare l’accesso dei processi agli oggetti e un sistema di Multi-Level Security (MLS) per isolare i domini delle applicazioni.

La NSA ha realizzato il porting d’una parte dello userspace di SELinux. Curiosamente, SEAndroid non è stato creato con Android: i sorgenti del progetto sono mantenuti da Fedora, la distribuzione di Red Hat che utilizza SELinux a livello predefinito. Canonical e Ubuntu gli preferiscono AppArmor. L’ultima parola spetta ai produttori.

Come si sottolineava per il porting di PulseAudio, SEAndroid è una soluzione open source di facile installazione su quei sistemi integrati che supportano ufficiosamente Android. Senza l’appoggio dei partner di Google, il progetto è destinato a un uso limitato. Il discorso nella circostanza fa sorridere: sarebbe considerato un hack.

Un ambiente ideale per l’integrazione di SEAndroid sarebbe Linaro con la build di Android che utilizza la toolchain di Ubuntu. Stiamo parlando d’una distribuzione non ufficiale ignorata da Google e perciò esclusa dall’Android Market. Stando a queste condizioni è lecito domandarsi se non sia preferibile optare direttamente per Linux.

Eppure, è innegabile che l’interesse attorno al sistema operativo di Google sia in costante ascesa: la recente disponibilità di PulseAudio e SEAndroid giustificano – almeno, in parte – la tesi di Chris Di Bona, per il quale Android è «il sogno del desktop di Linux diventato realtà». Il problema è nell’evidente dipendenza da Google.

Via | The H Security

Un aspetto destabilizzante venendo da ambienti diversi – ad esempio, da GNOME – è proprio l’onnipresenza della finestra di KWallet: il “portachiavi” di KDE per il salvataggio delle password. Alla prima parola–chiave da salvare è richiesto l’inserimento d’una password per sbloccare KWallet. Una soluzione tanto sicura, quanto scomoda.

Non sono stati proposti molti dettagli sulla presenza di KSecretService su KDE 4.8 RC 1. Tuttavia, il mio auspicio è che utilizzi una soluzione più simile a quella di GNOME Keyring: il “portachiavi” di GNOME non richiede la password per accedere a quelle salvate. Chi vuole proteggerle con questo metodo può farlo a titolo opzionale.

Da questo punto di vista, personalmente credo che la soluzione più intelligente sia quella di Ubuntu. Oltre all’integrazione predefinita di GNOME Keyring con Pluggable Authentication Module (PAM), Ubuntu cripta la cartella dell’utente usando la password di login. Accedendo al desktop si sbloccano sia la /home, sia il “portachiavi”.

KDE è perfettamente integrato con PAM già dal display manager, perciò realizzare altrettanto non costituirebbe un problema. Ancora meglio se associato a KSecretService per raccogliere e condividere le password di applicazioni “aliene”. Si può comunque scegliere di lasciare KWallet senza parola–chiave, ma è una scelta sconsigliabile.

Altre novità di KDE 4.8 RC 1 sono meno eclatanti: la direzione intrapresa dal progetto è la stessa di Qt, aumentando l’utilizzo di QML e QtQuick in vista del futuro major upgrade a KDE5 e Qt5. Dolphin, ad esempio, è stato riscritto per migliorare ulteriormente le performance. Seguono consueti fix di manutenzione all’intero desktop.

Via | KDE News

Come sempre, nelle analisi la raccolta dei dati è un’attività oggettiva, il problema poi rimane la metrica utilizzata. Infatti, i ricercatori Accuvant hanno deciso che per valutare la sicurezza dei browser i fattori discriminanti non sono la presenza, il numero o la gravità delle falle (ad esempio buffer overflow), ma piuttosto le azioni intraprese per limitare i danni al momento dell’attacco.

L’oggetto dello studio è quindi il comportamento di default in presenza di exploit. Di conseguenza tutta l’analisi ignora completamente la “responsività” del team di sviluppo nel rilascio di soluzioni efficaci. Il test, effettuato su Windows 7, ha dato i seguenti risultati: primo Google Chrome, secondo Internet Explorer e terzo Mozilla Firefox. Fa un certo effetto vedere Internet Explorer al secondo posto.

L’immagine che ne viene fuori è una sostanziale inadeguatezza delle tecnologie di Firefox. Di fatto è rimasto l’unico a non implementare una sandbox degna. Probabilmente un altro segno dei tempi che cambiano. Purtroppo. Ne avevamo avuto già un assaggio quando la vulnerabilità dei protocolli SSL-TLS stava imperversando e mieteva terrore ovunque. Gli ingegneri Mozilla elaborarono un piano tanto geniale quanto lungimirante: disabilitare Java. L’efficacia è ineccepibile.

Dall’altra parte invece, sviluppatori Google stavano approntando una soluzione non definitiva ma che rendeva il traffico catturato più “randomico” e quindi meno comprensibile all’attaccante. Il tutto senza scatenare discussioni religiose nel loro bugzilla. Probabilmente rilasciare versioni ogni sei settimane non basta a colmare il divario.

EDIT: riportiamo la dichiarazione di Johnathan Nightingale, Director of Firefox Engineering:

Firefox includes a broad array of technologies to eliminate or reduce security threats, from platform level features like address space randomization to internal systems like our layout frame poisoning system. Sandboxing is a useful addition to that toolbox that we are investigating, but no technology is a silver bullet. We invest in security throughout the development process with internal and external code reviews, constant testing and analysis of running code, and rapid response to security issues when they emerge. We’re proud of our reputation on security, and it remains a central priority for Firefox

Via | TheRegister

Un pessimo affare per chi aveva appena potuto provare l’installer grafico di Node.js su Windows. Per fortuna, gli sviluppatori sono intervenuti immediatamente e la versione 0.6.5 risolve il problema. Non si tratta certo d’un velato “boicottaggio”: Microsoft collabora attivamente al progetto sponsorizzato da Joyent su Windows Server.

Qualche dubbio sorge proprio in merito a questa collaborazione. Microsoft ha tenuto un atteggiamento molto propositivo nei confronti di Node.js, eppure è incappata in un banale errore con l’antivirus gratuito di Windows: la prossima versione di Security Essentials eliminerà automaticamente le minacce… Node.js ed NPM sono a rischio?

Via | Node Blog

Come ogni Long Term Support (LTS) che si rispetti, il supporto e le correzioni sono un’attività prioritaria. In particolar modo per quanto riguarda la sicurezza delle infrastrutture. Alcune settimane fa avevamo trattato le vulnerabilità nei kernel LTS 2.6.38 e 2.6.32. Questa volta tocca ai kernel per EC2 e, dunque, alle infrastrutture cloud.

Le vulnerabilità in questione comportano conseguenze serie ai sistemi affetti. Quattro sono le falle che interessano i kernel EC2 di Ubuntu, registrate come CVE-2011-2491, CVE-2011-2496, CVE-2011-2525 e CVE-2011-2517. Le prime tre comportano un Denial of Service e l’ultima, particolarmente insidiosa, rende possibile una “scalata” di privilegi per l’utente root.

Fortunatamente, se così si può dire, le falle possono essere sfruttate solo da locale. Le aree interessate sono la gestione del NFS Lock Manager, la Classless Queuing Disciplines, le mapping extensions e per finire una scorretta gestione della lunghezza degli SSID nello stack wireless. Le correzioni sono presenti nel pacchetto linux-image-2.6.32-340-ec2: trattandosi del kernel, ovviamente occorre un riavvio della macchina. I moduli di terze parti andranno ricompilati e reinstallati.

Via | LWN

Siamo abituati a considerare l’open source una risorsa positiva quale di fatto è. Tuttavia, il concetto può essere applicato a qualunque cosa — riprendendo così le recenti dichiarazioni di Matt Mullenweg. Non è obbligatorio fare del bene. Zeus è l’esempio di come la libera circolazione dei sorgenti possa beneficiare anche i malware.

Quello dei virus è un mercato fiorente, più di quello del software: normalmente, chi produce un malware ne difende la proprietà intellettuale al pari delle aziende che distribuiscono applicazioni commerciali. Con la diffusione del modello di business dell’open source, persino chi genera dei trojan a scopo di lucro si sta adattando.

Via | Ars Technica

La possibilità di cifrare i messaggi di posta elettronica è una delle funzioni assenti dall’interfaccia di GMail. GPG4Browsers elimina la necessità d’utilizzare un client: basta accedere alla webmail dal browser per criptare e decriptare i messaggi in invio o ricezione. La novità può incrementare sensibilmente l’uso della cifratura.

L’estensione è compatibile con GnuPG, a patto d’escludere la compressione: l’unica “pecca” di rilievo del progetto rilasciato sotto licenza LGPLv2.1. Per adesso GMail è il solo servizio di webmail a essere supportato da GPG4Browsers. L’interfaccia è in jQuery e la lista degli algoritmi di cifratura utilizzabili è piuttosto fornita.

Via | The H Security

Al momento i report arrivati all’ISC riscontrano interruzioni del servizio a seguito di query ricorsive. I log analizzati riportano una stringa del tipo: INSIST(! dns_rdataset_isassociated(sigrdataset)). Il problema interessa le seguenti versioni di BIND: 9.4-ESV, 9.6-ESV, 9.7.x, 9.8.x.

La causa del problema è, per il momento, sconosciuta. Di certo c’è che questo evento è in grado di mettere in cache un record non valido, determinando così un’inconsistenza. Non esistono correzioni definitive, ma solo delle patch che consentono di mitigare gli effetti. Il tutto è ancora sotto investigazione: l’unica soluzione reale è appunto fare l’upgrade alle versioni con patch 9.8.1-P1, 9.7.4-P1, 9.6-ESV-R5-P1, 9.4-ESV-R5-P.

Via | Sophos

Le opzioni rimangono due: offrire la possibilità di disabilitare la funzione dal BIOS oppure lasciare che gli utenti possano gestire le Platform Key (PK) da associare al Secure Boot. Oltre agli Original Equipment Manufacturer (OEM), gli utenti dovrebbero accedere a una «modalità di ripristino» per rimuovere e/o aggiungere le chiavi.

Microsoft non ha dovuto aggiungere nulla alle prime dichiarazioni sulla responsabilità di UEFI, né peraltro è stata chiamata in causa dalle petizioni che riguardano il Secure Boot. Per dovere di cronaca, l’unico dispositivo che attualmente prevede questa funzione è un prototipo di Samsung con Windows 8 e permette la disattivazione.

Via | Ars Technica

Non si parla, ovviamente, di tutelare i pedofili: Tor è stato utilizzato da costoro contro i princìpi della comunità. Tuttavia, non sarebbe avvenuta alcuna compromissione del codice di Tor. Le statistiche di Anonymous rivendicano l’identificazione di 6.000 indirizzi IP riconducibili a dei relay e Tor ne equipaggia tutt’al più 3.500.

È molto difficile attribuire delle responsabilità a Tor, soprattutto perché il tipo d’attacco perpetrato da Anonymous sfrutta delle vulnerabilità associabili ai sistemi operativi. Tornando alle cifre, è impossibile che sia stata mappata la rete di Tor perché esistono 600 bridge e ne sarebbero stati identificati 181. La rete è sana.

Via | Tor