Gli utenti delle principali distribuzioni, a eccezione di Ubuntu, nelle ultime ore hanno dovuto affrontare un fastidioso bug di X.Org Server 1.11. Avviato lo screensaver chiunque avrebbe potuto accedere alla sessione attiva da una semplice combinazione di tasti. Nello specifico, [Ctrl]+[Alt]+[KP_Multiply] — il pulsante cd. compose.
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
Security Enhanced Android o SEAndroid è il porting di SELinux – creato dalla National Security Agency (NSA) – sul sistema operativo di Google. Annunciato da Stephen Smalley al Linux Security Summit 2011, è disponibile al pubblico. L’intenzione è quella d’incrementare la sicurezza di Android — sulla falsariga del progetto per Linux.
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.
Continua a leggere: SEAndroid, SELinux per Android creato dalla National Security Agency
È stata rilasciata ieri, in serata, la prima release candidate per KDE 4.8. Tra le novità proposte spicca KSecretService, un nuovo servizio in background per la memorizzazione delle password e soprattutto per migliorarne la condivisione con le applicazioni esterne a Plasma e KDE. Un cruccio tipico del desktop environment e KWallet.
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.
Continua a leggere: KDE 4.8 inaugura KSecretService per la memorizzazione delle password
A quanto pare, sicurezza per i browser significa sandbox. Un rapporto stilato da Accuvant mette a confronto tutti i maggiori browser saggiandone le debolezze e valutando le azioni intraprese a fronte di minacce selezionate.
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
Node Package Manager (NPM) è un sistema per la risoluzione delle dipendenze e l’installazione dei pacchetti di Node.js simile a RubyGems per Ruby. È stato integrato ufficialmente con la versione 0.6.3, però Windows non l’ha “digerito”: se non si procede all’aggiornamento NPM è trattato alla pari d’un virus ed eliminato dal sistema.
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
Zeus è un trojan apparso per la prima volta nel 2007: soltanto da un paio d’anni, però, è stato riconosciuto come «il re dei toolkit» per la realizzazione di malware. Una differenza sostanziale, rispetto al passato, è la disponibilità del codice sorgente. Un aspetto ambivalente che aiuta la creazione di “antidoti” come di derivati.
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
GPG4Browsers è un progetto in Java per gestire le chiavi di cifratura, compatibili con lo standard di OpenPGP, dal browser. Creato da Recurity Labs, al momento consiste in un’estensione per Chrom*. È semplice spiegare il suo significato: GPG4Browsers attiva il supporto alla cifratura dei messaggi nei servizi di webmail dal browser.
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
L’Internet Systems Consortium ha reso nota una falla che interessa BIND. Il problema è considerato di categoria “serious” ed è riproducibile da remoto. Attualmente, si pensa che la vulnerabilità 0day sia in grado di generare un Denial of Service, ossia indurre un crash da remoto. Particolarmente insidioso, vista la delicatezza del sistema dei DNS.
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
The Linux Foundation, Canonical e Red Hat hanno raccolto l’appello di The Free Software Foundation (FSF), riguardo alle linee guida da suggerire ai produttori per l’implementazione del Secure Boot di UEFI. Le posizioni espresse sono condivise e ricalcano grossomodo le dichiarazioni già pubblicate da FSF. La risposta tocca agli OEM.
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