Tutti gli articoli di Marco Bonfiglio

Altro giro, altro bug (per Intel)!

Facebooktwittergoogle_plusredditlinkedin

L’epopea di Intel e dei bug hardware dei suoi processori non cenna a diminuire. Dopo l’annuncio di altre varianti di Spectre e Meltdown, con relative patch in arrivo, Cyberus Technology annuncia la scoperta di un nuovo buco, relativo al lazy FPU state switching (cambiamento di stato della FPU pigro).

Di cosa si tratta? Abbiamo già accennato ai meccanismi di Meltdown e Spectre, per cui alcune tecniche di miglioramento delle prestazioni (branch prediction) permettono l’accesso non autorizzato a dati memorizzati nella CPU; anche questa volta siamo di fronte ad un caso simile.

Le nostre CPU eseguono un solo programma alla volta, ma possono sospendere l’esecuzione di un programma ed eseguirne un altro: fatto spesso (e con sufficiente velocità), questo crea l’illusione del multitasking, ovvero l’esecuzione contemporanea di più programmi. La CPU usa tutta una serie di registri per sapere a che punto del programma sia arrivata e su che dati stesse lavorando: il cambio avviene salvando la situazione di questi registri e caricando la situazione del programma lasciato in sospeso da riprendere.
Anche in questo caso lo switch di programma può essere piuttosto oneroso, quindi una tecnica per migliorare le prestazioni è evitare l’effettivo cambiamento fino a quando non sarà necessario, lasciando quindi accessibili dei dati che non appartengono al programma in esecuzione in quel momento.

Questa particolare falla non riguarda tutta la CPU, ma la FPU (Floating-Point Unit), ovvero quel chip che si occupa esclusivamente dei calcoli che riguardano numeri con la virgola (le operazioni fatte con numeri interi sono più semplici e gestite direttamente dalla CPU). Ai tempi di 286 e 386 si parlava di coprocessore, ma l’utilità (e il costo irrisorio aggiuntivo) hanno ormai fatto integrare questo componente in tutti i processori moderni. Il dettaglio sembra piccolo, e che limiti i danni, peccato che moltissimi calcoli siano demandati all’FPU, compreso criptazioni e codifiche/decodifiche: danni limitati proprio alla parte più sensibile.

Al momento l’attacco sembra specifico delle CPU Intel, ma non è ancora dato sapere esattamente quali modelli né quanto sia difficile attuarlo. Tutto perduto, quindi?
No, perché da qualche anno i processori dispongono di una nuova istruzione (XSAVEOPT) per memorizzare lo stato dei registri che non si comporta pigramente, e i kernel moderni usano questa funzionalità di default: vale per RHEL/CentOS 7, Ubuntu 16.04, in genere dal kernel 4.9. Perfino Windows 10 è già coperto.
Per chi invece usasse un kernel più antico, dal kernel 3.7 è disponibile l’opzione al boot “eagerfpu=on”, che disattiva l’ottimizzazione problematica.

Per questo giro, forse, possiamo stare tranquilli.

Devuan 2.0 ASCII: il rilascio ufficiale!

Facebooktwittergoogle_plusredditlinkedin

Ne avevamo parlato poco tempo fa, e l’attesa è stata ripagata: Devuan 2.0, denominato ASCII, è stato rilasciato in forma stabile.

Devuan può essere definito come una versione di Debian senza systemd, e la nuova incarnazione si basa sulla versione 9, Stretch, l’ultima stabile: il gap tra le due distribuzioni diventa così praticamente nullo; data la vicinanza delle due distribuzioni (systemd a parte), tutto il parco software di Debian è disponibile (con la notevole eccezione di GNOME che, per scelta dei suoi sviluppatori, ha necessità di systemd).
Rispettati tempi e promesse del tempo del rilascio della beta, compresa la possibilità di usare OpenRC invece di SysV per la gestione dell’avvio dei servizi al boot.
Altra novità è il minisito con l’elenco (e la ricerca) dei pacchetti specifici di Devuan, simile a quanto offerto anche dalle altre distribuzioni principali, così da poter sapere in anticipo se un pacchetto di un certo software è stato adattato per Devuan e con quale versione.

Oltre alla versione principale (con varie possibilità di installazione), troviamo alcune distribuzioni derivate, tra cui le due più curiose sono:

  • Maemo Leste
    creata per i disposivi mobili, compresi Nokia N900/N950 e Motorola Droid 4, riprende il nome dal vecchio progetto maemo. Se avete qualche vecchio dispositivo ancora in giro…
  • DecodeOS
    per creare un sistema a micro-servizi anonimonascosto, sfruttando la rete Tor.

Pronti a fare un giro?

ip ed ss strumenti del futuro: dimenticate ifconfig e netstat

Facebooktwittergoogle_plusredditlinkedin

Un amministratore di sistema si affida ad una serie di strumenti, spesso specifici del sistema operativo su cui sta operando, per poter raccogliere informazioni sullo stato della macchina o impostarne alcuni parametri. Per la gestione della connettività di rete, tra quei strumenti usuali per linux, i comandi ifconfig e netstat sono stati per decenni fondamentali, ma esistono delle alternative: ss può sostituire egregiamente netsat, ed è capace di fare pure di più, mentre ip può sostituire ifconfig (e infatti in molte distribuzioni già lo fa).

Chris Siebenmann, sviluppatore di lunga data in ambito Unix/Linux (nonché creatore degli rpmtools, per citarne uno), si spinge oltre, argomentando che la scelta non può più essere basata solo su gusti personali, ma è dettata anche da questioni tecniche.

Su ssnetstat, il cui compito è visualizzare lo stato delle connessioni del sistema, e per cui abbiamo già dato un confronto delle informazioni fornite, il problema è nel metodo di recupero delle informazioni: netstat legge i file presenti sotto /proc, il mountpoint in cui il kernel espone le sue informazioni, mentre ss utilizza chiamate dirette al kernel, risultando molto più efficiente. Chris stesso ammette che su sistemi casalinghi la differenza fattuale può essere trascurabile, ma in ambiti di alto carico l’effetto è notevole.

Per ifconfig ed ip il problema può diventare evidente subito; entrambi questi programmi si occupano di gestire un’interfaccia di rete, indirizzo IP compreso. Può capitare di dover assegnare più indirizzi IP alla stessa interfaccia fisica, operazione che normalmente avviene tramite alias: invece di associare l’IP all’interfaccia stessa, si crea un’etichetta e lo si associa a quest’ultima. Però, questa tecnica, non è necessaria, tanto che ip è in grado di associare più indirizzi IP alla stessa interfaccia. ifconfig, aspettandosi il metodo classico, semplicemente si perde delle informazioni. Chris stesso ci fornisce l’esempio:

ifconfig -a
[...]
em0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 128.100.3.XX netmask 255.255.255.0 broadcast 128.100.3.255
inet6 fe80::6245:cbff:fea0:e8dd prefixlen 64 scopeid 0x20<link>
ether 60:45:cb:a0:e8:dd txqueuelen 1000 (Ethernet)
[...]
ip -4 addr show em0
[...]
  inet 128.100.3.XX/24 brd 128.100.3.255 scope global em0
    valid_lft forever preferred_lft forever
  inet 128.100.3.YY/24 brd 128.100.3.255 scope global secondary em0
    valid_lft forever preferred_lft forever

Come si vede, l’indirizzo 128.100.3.YY semplicemente non compare con il primo comando.

Sembra quindi che il sistemista moderno debba adeguarsi, imparando i nuovi comandi e dimenticando i vecchi. Magari non proprio subito… e no, stavolta non abbiamo detto systemd!

Esposti i piani iniziali per Ubuntu 18.10

Facebooktwittergoogle_plusredditlinkedin


Rilasciato da poco Ubuntu 18.04  Bionic Beaver (nonché LTS), Canonical deve pensare alla nuova versione da rilasciare ad ottobre: Ubuntu 18.10 Cosmic Cuttlefish. E cosa aspettarci in questa nuova iterazione?

Ce lo spiega in un post Will Cooke, uno degli sviluppatori coinvolti, che parte dai miglioramenti previsti per la 18.04.01 (prima point release, prevista a giugno):

  • sblocco tramite impronta digitale;
  • impostazioni dell’interfaccia Thunderbolt tramite il Centro di controllo di GNOME;
  • supporto per le applicazioni SNAP di XDG Portals.

Proprio l’ultimo punto conferma la grande attenzione (e fiducia) di Canonical in questo formato per la distribuzione di pacchetti. Tanto che due delle novità riguardano questo formato:

  • tempo di avvio delle applicazioni SNAP
    Uno dei punti deboli rimarcato delle installazioni SNAP è la necessità di configurare una serie di parametri al primo avvio, allungandone (molto) il tempo necessario per avviarsi. Il sistema di costruzione del pacchetto SNAP ha da poco aggiunto la possibilità di effettuare (alcune) di queste configurazioni direttamente nella fase di impacchettamento, così da evitare questo effetto; inoltre è stato promesso l’impegno di indagare più a fondo, per eliminare il più possibile il ritardo.
  • Chromium distribuito via SNAP
    Il browser di Google Chrome (closed source)  ha da sempre un gemello open source da cui trarre ispirazione, Chromium, che ha anche la vocazione ad usare sempre l’ultima tecnologia disponibile; questo vale anche in compilazione, ma le risorse necessarie non sempre sono disponibili nelle versioni appena più datate – come la 16.04 LTS, ancora supportata ma per Chromium vecchia. Questo costringe i manutentori dei pacchetti di Ubuntu a piccoli salti mortali, o all’impossibilità di offrire le ultime versioni. SNAP, con la possibilità di essere autonomo nelle librerie necessarie fornite, risolverebbe questo problema scorporando le librerie – e gli strumenti – di sistema dal programma distribuito.

Ecco le altre novità (alcune già anticipate):

  • GNOME Software improvements
    Solito allineamento della versione distribuita da Ubuntu alle ultime rilasciate dal gruppo di sviluppo, ma stavolta con una collaborazione attiva tra il gruppo interno di Canonical e quello di GNMOME
  • consumo energetico
    Promesso un miglioramento nella gestione dell’energia, con la risoluzione dei difetti di quei meccanismi ancora non attivi per problemi di stabilità.
  • condivisione dei media
    DLNA è ancora in giro, e sebbene sia uno standard poco rispettato, molti dispositivi (dal cellulare alla smart TV) possono trarne vantaggio: rendere semplice la condivisione dei contenuti è un obbiettivo. Altro meccanismo da rendere semplice è la condivisione via protocollo SMB  (la “condivisione cartelle” di Windows)
  • Sviluppo di un tema nuovo
    Lo schema di colori usato nel desktop può essere rinnovato
  • KDE Connect / GS Connect
    L’unione cellulare/computer può essere fatta semplice; su KDE esiste KDE Conncect, con GNOME il protocollo è implementato con GS Connect.
  • Iniziale supporto per un nuovo installer
    Sebbene non sarà completato per la prossima release, il lavoro sul nuovo processo di installazione deve iniziare!
  • Sito pubblico per i report dei dati inviati a Canonical
    Da qualche anno ormai tutti i sistemi Ubuntu raccolgono dati di uso che inviano ai server Canonical per sapere come e su cosa concentrare gli sforzi di sviluppo; ora c’è la promessa concreta di rendere le elaborazioni pubbliche e facilmente comprensibili.

Come si vede, la carne al fuoco è tanta: ce la faranno per Ottobre? Crediamo di sì, e infatti siamo già in attesa di vedere il risultato! 😉

Intel distribuisce CPU a 10nm

Facebooktwittergoogle_plusredditlinkedin

Qualche tempo fa abbiamo parlato di IBM e della sua messa a punto di un processo di produzione industriale a 5nm (nanometri, miliardesimi di metro), ma facciamo un riassunto: la dimensione indicata è quella del singolo transistor all’interno di un chip (una CPU oggi ne conta dai 2 miliardi dell’i7 serie 5000 ai 19 miliardi dell’AMD Epyc), quindi minore è questa dimensione, maggiore è il numero di transistor che possono stare nello stesso spazio (oppure maggiore sarà il numero di chip che si potranno produrre con la stessa quantità di silicio).

Non solo, minore è la dimensione del transistor, maggiore sarà la frequenza di clock che questo sarà in grado di sopportare (con migliori prestazioni), nonché minore sarà l’energia consumata per le stesse attività. In effetti, l’aumento di potenza di calcolo (e il rispetto della famosa legge di Moore) sono dirette conseguenze dei miglioramenti di questo aspetto produttivo.

Al momento Intel ha in catalogo CPU a 14nm, ma sono attese da molto tempo le CPU a 10nm: erano state annunciate per il 2015, ma le difficoltà produttive e le difficoltà finanziare (complice Meltdown) avevano rimandato fino al 2019. Un articolo di ArsTechnica però ci svela che non solo queste CPU sono già in produzione, ma addirittura in distribuzione – e specificamente a Lenovo. L’articolo si concentra sulle caratteristiche del tipo di processore (i3), del codice (8121, quindi ottava generazione), della serie (U, basso voltaggio) ed il fatto che sia il primo con microarchitettura Cannon Lake. Ad interessare maggiormente in ogni caso è il fatto che questo processore sia il primo con tecnologia a 10nm, e significa che il passaggio dalla produzione a 14nm si è già verificato.

Alcuni indizi indicano che questa produzione sia una specie di prova generale, come il fatto che un i3 (fascia bassa) è meno complesso di un i5 (fascia media) o di un i7 (fascia alta), quindi sono tollerabili maggiori difetti di produzione. Anche il fatto che non ci sono accenni ad una scheda grafica integrata farebbe pensare a difetti tanto frequenti da preferire di disattivare permanentemente questo componente. Inoltre, la distribuzione ad un solo cliente (per quanto importante) potrebbe essere una scelta obbligata per una produzione ancora in piccola scala.

Allo stesso tempo questa notizia ci permette di sperare che l’applicazione di questa tecnologia produttiva sia a breve termine applicabile per i5 ed i7, o anche per il mercato server: la nuova generazione. Dalla quale ci si aspetta anche la risoluzione definitiva di Meltdown e Spectre…

OpenSuSe inaugura i Transactional Updates

Facebooktwittergoogle_plusredditlinkedin

Per il 25 maggio  è atteso il rilascio della prossima versione stabile di openSUSE, ovvero Leap 15, ma è notizia di ieri la conferma dell’uso dei Transational Updates, già in test nella versione di sviluppo Tumbleweed (come scrivevamo qualche tempo fa). Il nuovo meccanismo sarà disponibile di default, e selezionando il nuovo ruolo “Transational Server” sarà anche attivo di default – con ogni notte aggiornamento e, se necessario, riavvio automatico.

L’obbiettivo del nuovo sistema è quello di rendere gli update dei pacchetti atomici: ogni volta che verrà richiesto un aggiornamento, tutti i pacchetti interessati saranno attivati in blocco e non singolarmente; altro obbiettivo è dare un metodo di rollback rapido ed affidabile, ovvero poter tornare esattamente allo stato pre-update (e certamente funzionante ) in caso di problemi.
openSUSE ha scelto di utilizzare delle tecnologie esterne al formato di pacchetti stesso (al contrario di Ubuntu con SNAP), basandosi sulle funzionalità di btrfs di fare ed usare snapshot del filesystem. Ricordiamo che Red Hat, di cui openSUSE rimane una derivata, non potrà adottare la stessa strategia in quanto ha annunciato l’abbandono del supporto a btrfs, e gli altri filesystem non hanno una funzionalità simili con un supporto altrettanto maturo.

Tale capacità di btrfs viene sfruttata da snapper, sviluppata da SUSE stessa proprio per comparare e gestire le snapshot (inizialmente solo per LVM, ora anche con btrfs). A sua volta snapper viene invocato da Zypper, ovvero il gestore di pacchetti di openSUSE. Questa architettura permette di avere la nuova capacità di update transazionale senza modificare i pacchetti per supportarla apposta, e quindi essere compatibile con tutti i pacchetti: futuri, passati o di terze parti.

Le considerazioni già espresse sui limiti della tecnologia rimangono valide, e in particolare il fatto che la capacità di rollback viene annullata al primo avvio “valido” della versione aggiornata; in più, la snapshot di recovery del sistema è quella prima dell’update: in caso di rollback, qualunque modifica fatta tra l’inizio degli aggiornamenti e il reboot della macchina verrà persa.

efail: il pericolo viene ridimensionato

Facebooktwittergoogle_plusredditlinkedin

I dettagli di efail sono stati rilasciati prima del previsto! Al link https://efail.de si trova una prima descrizione, mentre una più dettagliata è in un PDF. Ecco riassunto il problema.

Come avevamo intuito, il problema risiede più nel modo in cui i client di posta gestiscono i metodi di criptazione che nel metodo stesso, in particolare per email in formato HTML. In più, l’attacco richiede l’accesso alla mail stessa da attaccare, quindi un accesso di qualche tipo all’archivio in cui si trova la mail stessa (che si trovi su un server o sul proprio pc). Per alcuni casi specifici, infine, è possibile sfruttare una attacco di tipo Man-in-the-middle, nel quale l’attaccante si pone tra il server e la vittima per modificare nella trasmissione la mail stessa: quest’ultimo tipo di attacco potrebbe essere molto complicato di per sé, però.

Le mail che ci scambiamo sono (ormai) quasi sempre di tipo HTML con qualche tipo di allegato (come specificato dallo standard MIME (Multipurpose Internet Mail Extensions – Estensioni multifunzione alla posta di Internet), che usa una designazione standard per poter identifcare le varie parti del messaggio(header –BOUNDARY per l’inizio e –BOUNDARY– per la chiusura); di fatto sia OpenPGP che S/MIME prevedono un messaggio composto da un allegato, che poi non è altro che il messaggio criptato.
Normalmente i (plugin dei) client di posta provvedono a decriptare l’allegato e visualizzarlo come fosse il messaggio, rendendo semplice l’uso.

Modificando la mail, è possibile aggiungere un header prima del messaggio criptato, che apra un collegamento il cui argomento è il messaggio criptato, ed uno in fondo, che chiuda il collegamento; quando il client di posta andrà ad aprire il messaggio farà la composizione dei tre pezzi, ma decriptando in automatico il messaggio in mezzo; a questo punto metterà insieme le varie parti del messaggio per crearne uno solo, che sarà composto da un link con il messaggio decriptato come parte del link. Se l’attaccante avrà predisposto un sito a cui puntare, potrà leggere il testo come banale richiesta al suo sito.

Affinché l’attacco abbia successo, però, c’è bisogno che la mail venga aperta dal client di posta della vittima, in quanto solo quel client avrà accesso alla chiave privata per decriptare la mail; inoltre, si ha bisogno che quel client provi in automatico da solo a contattare la URL così creata: l’esempio classico è un’immagine in una mail, tanto che è il metodo esposto nell’articolo; ma molti client (e webclient, vedi GMail) si rifiutano di scaricare le immagini in automatico da siti che non ritiene affidabili.

Insomma, l’attacco sembra piuttosto articolato e vincolato alla riuscita di qualche altro tipo di attacco, quindi non di immediata applicazione; inoltre non appare un problema di protocollo di criptazione. Queste considerazioni ci inducono a ridimensionare la criticità dell’attacco.

La mitigation consigliata per il breve periodo su efail.de è quella già data nell’annuncio: disabilitare i plugin automatici. Mentre per soluzioni definitive si invocano patch ai client e una revisione di alcuni meccanismi sia di PGP che di S/MIME: vedremo chi e come risponderà a questo appello.

Noi, forse sbagliando, non cambieremo il nostro comportamento. E voi?

efail: le email criptate con PGP o S/MIME sono a rischio

Facebooktwittergoogle_plusredditlinkedin

Avere la sicurezza che i propri messaggi saranno letti solo dal destinatario è parte ormai irrinunciabile delle nostre comunicazioni, specialmente via Internet, e la crittografia esiste proprio per questo.
Da almeno un decennio lo standard per lo scambio di file ed email è OpenPGP (sua con l’implementazione closed PGP che con la open GPG), ed esistono anche servizi che garantiscono lo scambio sicuro di messaggi grazie a questa tecnologia, come ProtonMail.

Per chi non sapesse come funziona PGP, più sotto troverà una breve spiegazione.

Il 13 maggio, tramite un tweet, il ricercatore Sebastian Schinzel ha annunciato una falla di sicurezza, in particolare per gli utilizzatori di PGP e S/MIME nello scambio di email, già battezzata efail (e-fallimento); nello stesso tweet ha rimandato al 15 maggio per avere i dettagli.
Da notare che anche la EFF (Electronic Frontier Foundation) ha deciso di dare risalto all’annuncio con un suo comunicato, nel quale si può leggere quanto segue:

EFF has been in communication with the research team, and can confirm that these vulnerabilities pose an immediate risk to those using these tools for email communication, including the potential exposure of the contents of past messages.

La EFF è in comunicazione col team di ricerca e può confermare che queste vulnerabilità pongono un rischio immediato per quanti usino quei tool per comunicazioni via mail, compreso la potenziale esposizione dei contenuti dei messaggi vecchi.

Il pericolo quindi sembra reale, e non è legato ad un atto di intercettazione – ovvero un attacco da attuare alla trasmissione o ricezione del messaggio – ma ad un vero e proprio problema di metodo –  e quindi un attacco che può essere portato anche alle mail già archiviate.

L’invito è quello di disabilitare o proprio disinstallare le estensioni del client di posta che sfrutti questi meccanismi di criptazione, con tanto di istruzioni per Thunderbird con EnigmailApple Mail con GPGTools e Outlook con Gpg4win.

Per sapere esattamente di cosa si tratti dovremo aspettare maggiori informazioni, che saranno rilasciate oggi, ma il fatto che vengano citati sia PGP che S/MIME, e che si faccia riferimento solo alle mail, fa pensare che il problema sia più nel protocollo usato per le mail in generale che nella sicurezza dei meccanismi di criptazione PGP (e della sua implementazione open GPG).

Appena sapremo qualcosa in più, vi aggiorneremo!

Facciamo un riassunto sui meccanismi di PGP e S/MIME e le nozione base di crittografia associate.

Proprio perché la crittografia è una necessità sentita da tanto tempo, esistono tante soluzioni, ma di fatto la più diffusa ed utilizzata è PGP (Pretty Good Privacy – Priviacy piuttosto buona), descritta nelle specifiche OpenPGP, ed implementata in Linux con GPG (GNU Privacy Guard – Guardia della privacy GNU). Sì, la giungla delle sigle è piuttosto complicata, ma diciamo che tutte prevedono il supporto per una serie di algoritmi e tecniche di criptazione che possono essere applicate a tanti livelli; ci occuperemo solo di quanto succeda con una mail o un file in generale.

In generale troviamo diffusi due sistemi di criptazione:

  • simmetrico
  • asimmetrico

Nel primo caso viene generata una sola chiave, da usare sia per criptare che decriptare un messaggio; si definisce simmetrico proprio perché il processo di criptazione e decriptazione è lo stesso, cambiano solo i dati di partenza.
Nel secondo caso le chiavi sono due: una pubblica, per criptare il messaggio, ed una privata, per decriptarlo. In questo caso la chiave privata è da custodire gelosamente, mentre è necessario distribuire quella pubblica. Questo secondo metodo è di gran lunga quello più usato su internet, in quanto su questo principio si basano tutte le comunicazioni sicure (da HTTPS ad SSH).

PGP usa un sistema misto (o ibrido), in cui i dati sono criptati con metodo simmetrico, mentre la chiave stessa con metodo asimmetrico, usando la chiave pubblica specifica del destinatario.
Per esempio, se Alice deve criptare un file da mandare a Bruno, le operazioni da fare sono:

  1. generazione di una chiave;
  2. applicazione della chiave al file con metodo simmetrico;
  3. criptazione della chiave stessa con la chiave pubblica di Bruno;
  4. unione dei dati criptati e della chiave criptata in un unico file.

Bruno, alla ricezione del file, dovrà effettuare una analoga sequenza di operazioni:

  1. separazione della chiave criptata dai dati criptati
  2. decriptazione della chiave usata per i dati tramite la propria chiave privata
  3. uso della chiave per decriptare i dati

L’uso di chiavi pubbliche associate ad una certo destinatario rende necessaria una infrastruttura ad hoc per la distribuzione delle chiavi pubbliche, per evitare di dover scambiare prima queste informazioni e invece richiederle quando necessario; proprio per questo esistono una serie di server, chiamati key server, deputati proprio a questo scopo.

S/MIME descrive un metodo simile, ma al posto delle chiavi asimmetriche usa certificati x509; per questo meccanismo non esiste un metodo standard di distribuzione dei certificati, che devono essere scambiati tra i corrispondenti prima di iniziare una comunicazione.