Archivi categoria: Kernel

SegmentSmack: la rete del Kernel Linux è esposta ad attacchi DDOS

Facebooktwittergoogle_plusredditlinkedin

Come spiega questo articolo di Red Hat il Kernel Linux soffre di una falla che è stata battezzata SegmentSmack e riguarda la gestione di pacchetti TCP confezionati a regola per provocare denial of service.

A scoprire il problema, come spiega ZDNet, è stata la sezione CERT/CC della Carnegie Mellon University la quale ha fornito anche la lista delle implementazioni TCP che soffrono del problema e come appare chiaro… Non si salva praticamente nessuno.

Come specifica ZDNet:

But, given the widespread use of Linux, the bug could affect every vendor from Amazon and Apple through to Ubuntu and ZyXEL.

Data la grande diffusione di Linux il bug potrebbe affliggere ogni vendor, da Amazon ad Apple fino ad Ubuntu e ZyXEL.

Il motivo per cui tutto esplode è presto detto: la CPU viene saturata da queste chiamate TCP. Se questo è il principio stesso di DOS (Denial Of Service), quello che pare peggio in questa vulnerabilità è che per produrre il risultato non è necessario avere reti coordinate o grossa banda: a chi coordina l’attacco basta servirsi di quanto viene definito come “a relatively small bandwidth of the incoming network traffic“.

Workaround e rimedi? Al momento, nessuno. Prepariamoci quindi a seguiremo l’evoluzione di questa nuova con il consueto entusiasmo!

Posticipato il rilascio del Linux kernel 4.18

Facebooktwittergoogle_plusredditlinkedin

Sembrava ormai solo questione di giorni prima che la versione 4.18 del kernel Linux venisse ufficialmente resa disponibile quando, dopo aver rilasciato la release candidate 7 nella serata di domenica, il Supremo Torvalds ha fermato tutto al grido di “Revert!”

I think I’ll do an rc8 with the revert, just so that we’ll have some time to figure this out. It’s only Tuesday, but I already have 90 commits since rc7, so this isn’t the only issue we’re having.

I _prefer_ just the regular cadence of releases, but when I have a reason to delay, I’ll delay.

Penso che farò una rc8 con il revert [annullamento delle modifiche], così avremo ancora un po’ di tempo per risolvere. È solo martedì ma ho gia 90 commit dal rilascio della rc7, dunque questo non è l’unico problema che abbiamo.

_Preferisco_ una cadenza regolare per le release, ma quando avrò un motivo per ritardare, ritarderò.

Uno dei più grandi colpevoli di questo ritardo è ashmem, un’area di memoria virtuale utilizzata a livello applicativo introdotta per risolvere un problema di sicurezza sulle piattaforme Android.

Nel dettaglio, visto che in Android non esiste una sorta di tmpfs per evitare che app malevole inquinino /tmp, ashmem si preoccupa di mettere a disposizione della memoria che possa essere condivisa senza creare un leak di risorse: ci si passano le informazioni senza utilizzare un file system temporaneo.

Detto ciò, la variabile vma_is_anonymous() di questa implementazione causa un crash dello userspace nella versione open-source di Android che usa la rc7, ma non con la rc6.

In un post molto articolato, Torvalds spiega che, al momento, sta valutando la rimozione di questa parte in modo da poterci lavorare e ripristinare la funzionalità nella prossima release.

Il kernel 5.0 sembra ancora molto distante anche se, con Torvalds alla guida, tutto può succedere!

WireGuard verso l’inclusione nel Kernel

Facebooktwittergoogle_plusredditlinkedin


WireGuard si propone come una soluzione VPN che sia più semplice da usare delle soluzioni tradizionali (come IPSec), ed al contempo – parecchio – più performante di quelle basate su SSL (in particolare OpenVPN). Ecco un video di presentazione, ma più sotto trovate una breve spiegazione del funzionamento (o almeno un tentativo 😉 ).

Come spesso accade, una parte di WireGuard è un modulo specifico del kernel per generare e gestire l’interfaccia di rete da esso creata. E, per poter dire di far parte di Linux, deve essere integrato nel codice del kernel mainstream (quello emanato da Linus Torvalds).
L’ultimo giorno di luglio è comparsa nella mailing list del Kernel una proposta di patch per integrare il codice di WireGuard nel kernel: si tratta del primo passo per rendere ufficiale il nuovo modulo. E, magari, poterlo integrare nel Kernel di dispositivi embedded (come i cellulari).

Da ora in poi ci sarà un processo di review del codice, che sebbene non sia molto (meno di 40000 linee), difficilmente potrà essere completato per il prossimo rilascio (4.19): più probabilmente potremo vedere il nuovo modulo parte del Kernel 5.0. In effetti, come novità non sarebbe male.

Non sappiamo se sarà in grado di soppiantare le soluzioni tradizionali o anche solo OpenVPN, ma di sicuro si tratta di un’alternativa molto interessante. E open!

Proviamo a spiegare brevemente il funzionamento di WireGuard.
Una VPN si basa sulla criptazione della comunicazione tra due dispositivi direttamente di pacchetti IP (talvolta di frame ethernet). OpenVPN usa certificati SSL per poter autenticare e criptare il traffico, IPSec una serie di regole più o meno stringenti per l’autenticazione ed una chiave simmetrica (e condivisa a priori) per la criptazione; WireGuard usa IP sorgente (o destinazione) ed una chiave asimmetrica per l’autenticazione, e tramite le chiavi negozia con l’altro host una chiave di criptazione simmetrica che ogni intervallo predefinito di tempo o dati scambiati viene rinegoziata: questa tecnica risulta molto efficacie per garantire una criptazione robusta.
I protocolli usati da WireGuard per la criptazione sono i più sicuri in circolazione, ampiamente testati (e usati anche da altri).
Ogni peer può lavorare sia come client (creando una connessione con un altro peer) che come server (accettando una connessione); WireGuard usa UDP, ed il server necessita solo di una porta aperta.

Ad ogni interfaccia di WireGuard sono associati 3 elementi:

  1. la chiave privata (con cui decriptare i pacchetti che arriveranno criptati con la chiave pubblica associata);
  2. la lista di associazioni delle chiavi pubbliche dei peer che possono creare una connessione con gli IP dei peer;
  3. l’indirizzo IP (o gli indirizzi, o le reti) raggiunto tramite quel peer;

Il modulo Kernel serve a gestire la criptazione del pacchetto prima dell’invio all’IP remoto, a creare le interfacce, ma anche a modificare la tabella di routing: associa l’interfaccia creata ad ogni IP o rete raggiungibile configurata.
I file di configurazione prodotti risultano compatti, e non molto complicati; le performance sono notevoli (almeno stando alla documentazione da loro prodotta).

Rispetto ai concorrenti designati, WireGuard ha due limiti:

  1. l’impossibilità di lavorare a livello 2 della pila ISO/OSI (il frame ethernet di cui sopra): talvolta più che mettere in comunicazione due reti (facendo routing a livello 3) è utile estenderne una (incapsulando i messaggi a livello 2) e permettere l’uso di protocolli che non dipendono da IP.
  2. non è possibile usare TCP: la scelta di UDP è dettata dalle performance, ma talvolta è impossibile usarlo (bloccato da un firewall di cui non è possibile cambiare configurazione) o è preferibile usare TCP per connessioni poco affidabili (sebbene per una VPN sia una cattiva idea usare TCP).

I due limiti però riguardano casi particolari, e chi dovesse avere queste necessità normalmente è in grado di usare e impostare le tecnologie alternative. 😉

Linux Kernel 4.19: tantissimi miglioramenti e nuove features

Facebooktwittergoogle_plusredditlinkedin

Mancano solo pochi giorni al rilascio delle versione 4.18 del Kernel Linux ma si sta già discutendo su tutto il lavoro che il 4.19 richiederà visto la mole di feature e migliorie schedulate (salvo inghippi tecnici) per la prossima release.

Segnaliamo alcune delle caratteristiche che finora sono emerse:

  • Supporto a Microsoft Surface Dial e Dell Totem, strumenti utilizzati principalmente dai creativi digitali per avere un accesso più rapido a funzioni e strumenti per manipolare le immagini;
  • Supporto Intel GVT vGPU per le VM guest, per la virtualizzazione delle GPU;
  • Due nuovi framework. Il primo, Idle Injection Framework, per tenere sotto controllo le temperature e l’energia utilizzata dalla CPU, come già avviene con PowerClamp di Intel per esempio. Il secondo è FPGA Device Feature List che “nasconde” molti dettagli tecnici di più basso livello legati all’hardware per fornire dati “consolidati” in modo da poter essere usati per configurazioni di altre applicazioni;
  • Supporto KPTI per piattaforme a 32-bit per contenere i danni di Meltdown, a scapito purtroppo delle performance che verranno impattate negativamente;
  • Alternate Mode Driver per USB Type-C che permetterà di poter utilizzare monitor e adattatori tramite questa interfaccia;
  • Networking CAKE Qdisc, feature già presente su OperWRT, che mira a ridurre al minimo la banda e la latenza dei link e router di qualsiasi ISP;
  • Il driver raspberrypi-hwmon per Rasperry Pi sarà finalmente in grado di poter notificare i problemi di sotto-alimentazione;
  • Driver per la Cougar 500k, tastiera da gaming che incorpora un processore ARM a 32 bit per la gestione della configurazione (chissà se altri produttori vorranno seguire il buon esempio);

Questo è solo un primo elenco, sicuramente nelle prossime settimane verranno aggiunte nuove feature e bugfix; nel frattempo, aspettiamo di vedere come se la caverà la 4.18!

Kernel Linux: arrivano le prime patch per Spectre V4

Facebooktwittergoogle_plusredditlinkedin

Risale già a qualche settimana fa la scoperta di una nuova falla della serie Meltdown/Spectre da parte dei team di Microsoft e Google ed arrivano anche le prime mitigation nel kernel Linux.

La versione 4.17 rilasciata negli scorsi giorni infatti include anche diverse patch per arginare i problemi che hanno introdotto Spectre e Meltdown:

  • Fix per alcune CPU x86 di produzione cinese;
  • Fix per Spectre per IBM s390;
  • Fix per Spectre V4 per Power7, Power8 e Power9;
  • Fix per Spectre V4 su CPU Intel.

Per il kernel 4.18 sono previste ulteriori patch per mitigare i problemi derivanti dallo Speculative Store Bypass stavolta sulle CPU di AMD che utilizzeranno le direttive SPEC_CTRL / VIRT_SPEC MSR che verranno fornite in futuro dal produttore insieme agli aggiornamenti firmware.

Al momento, questa sembrerebbe anche l’unica mitigation inclusa nel kernel 4.18 che fa riferimento all’architettura x86. Oltre a questa, infatti, sono previsti aggiustamenti anche per Spectre V4 su ARM64 e, finalmente, per Spectre V1/V2 su ARM 32-bit.

Vedremo mai la fine di questa neverending “apply-fix-and-reboot-you-machine” story?

Il prossimo Kernel Linux sarà il 5.0, o forse no. Parola di Torvalds!

Facebooktwittergoogle_plusredditlinkedin

Non è una grande novità il fatto che a Linus Torvalds, creatore e principale sviluppatore del Kernel Linux, i numeri di versione interessino veramente poco.

Infatti in seguito all’annuncio della release candidate del Kernel 4.17 Linus ha fatto intendere che la prossima release potrebbe essere la 5.0. Anche se, di fondo:

The version numbers are meaningless, which should mean that they don’t even follow silly numerological rules

I numeri di versione sono insignificanti, il che dovrebbe significare che non seguono tediose regole numeriche

Il pensiero si riconduce ad un ragionamento relativo all’attuale versione, la quale secondo il signor Linux non brilla per essere una release particolarmente grossa (letteralmente “not shaping up to be a particularly big release“). Come peraltro abbiamo discusso recentemente la stessa versione 4.17 poteva essere considerata una sorta di milestone per via di tutte le righe di codice rimosse (una cosa inedita per il progetto kernel che non aveva mai visto in nessuna release un numero di aggiunte minore rispetto alle rimozioni), ma ha seguito invece la consueta numerazione.

Tutto questo porta alla conclusione:

v5.0 will happen some day. And it should be meaningless. You have been warned.

La versione 5.0 uscirà prima o poi. E dovrebbe essere insignificante. Siete stati avvisati.

Quindi: esce o non esce? Non è dato di saperlo. Quello che emerge con certezza è che il conteggio delle release in Linux continuerà a non portare con se aggiornamenti critici o funzionalità aggiuntive critiche, sarà invece, piaccia o no, decisione unica e insindacabile del suo creatore.

È o non è il nostro dittatore benevolo preferito?

E’ ufficiale: Microsoft ha rilasciato una distribuzione Linux basata su un Kernel personalizzato

Facebooktwittergoogle_plusredditlinkedin

Con il filone “Microsoft ama Linux” ci siamo abituati a vedere comportamenti sempre più controcorrente rispetto alla storia di Microsoft.

Dal rilascio dei propri software in open source, alla collaborazione con Canonical per il rilascio di uno strato Linux in Windows, fino all’inclusione (e promozione) di distribuzioni Linux officiali nello store Azure, pensavamo di aver fatto il callo a questa nuova tendenza.

Ma proprio in un momento di serenità, ecco l’esplosione: Microsoft rilascia una distribuzione Linux.

Si, potete rileggere la frase, c’è proprio scritto quello!

Un paio di giorni fa, infatti, Microsoft ha annunciato una nuova tecnologia chiamata Azure Sphere e pensata per avere un sistema estremamente sicuro per dispositivi IoT, giocattoli connessi ed altri gadget.

E, dovendo fornire un sistema sicuro, da cosa partire? Da Windows? No, molto meglio avvalersi di un kernel Linux (altamente modificabile) e customizzarlo per le loro necessità.

Ed è quello che è stato fatto, scritto nella pietra o, se vogliamo, nel post ufficiale sul blog di Microsoft:

Azure Sphere will bring to these new chips a new customized operating system built for IoT security. This OS incorporates a custom Linux kernel that has been optimized for an IoT environment and reworked with security innovations pioneered in Windows to create a highly secured software environment.

Azure Sphere porterà a questi nuovi chip un nuovo e personalizzato sistema operativo costruito per la sicurezza dell’IoT. Questo OS incorpora un kernel Linux personalizzato che è stato ottimizzato per gli ambienti IoT e rilavorato con innovazioni di sicurezza già utilizzate in Windows per creare un ambiente software altamente sicuro

Quindi si, c’è Linux, ma l’annuncio sembra non dargli troppo credito, sottolineando che hanno dovuto lavorare sul kernel parecchio per renderlo utilizzabile su dispositivi IoT e, soprattutto, “sicuro come Windows” (…).

Il progetto Azure Sphere è molto più ampio, in realtà, e comprende lo sviluppo di chip ad-hoc, l’OS e servizi cloud a compendio di entrambi, ma il fatto che per la parte centrale di tutto (di fatto, è l’OS che fa parlare l’hardware con il cloud) è stato deciso di non usare un sistema Windows -seppur embedded- è sicuramente una svolta sensibile.

Al momento ne nell’articolo di Microsoft, ne nel loro repository GitHub ufficiale è presente il sorgente di questo kernel, stando alla GPLv2 dovranno rilasciarlo per forza… magari stanno aspettando solo la mail di Garrett.

Cosa ne pensate? E’ l’inizio della fine?

Ubuntu 18.04 LTS e Canonical LivePatch: aggiornamenti kernel senza reboot

Facebooktwittergoogle_plusredditlinkedin

Mancano poco meno di due settimane, il 26 aprile, al rilascio di Ubuntu 18.04 LTS (Bionic Beaver) che includerà:

  • Linux Kernel 4.15
  • systemd-resolved sarà il nuovo resolver DNS di default;
  • SSSD aggiornato alla versione 1.16x;
  • X.Org Server come display server di default invece di Wayland;
  • Patch per Meltdown e Spectre;
  • Deprecato Python 2 in favore di Python 3 (versione 3.6).

Una delle novità più interessanti di questa release pero è Canonical LivePatch, un servizio che permette di aggiornare il kernel senza necessità di riavviare il sistema.

In realtà questo servizio era già presente nella scorsa release, la 16.04, ma per questa volta Canonical si è impegnata a rendere questo tool di più facile utilizzo: ora si integra direttamente nella tab Updates, nella sezione dedicata alle impostazioni degli aggiornamenti.

Unici due nei forse:

  • È necessario avere un account Ubuntu SSO;
  • Limitato a 3 sistemi; oltre diventa necessario acquistare una sottoscrizione ad Ubuntu Advantage.

LivePatch è abilitato di default e per ricevere gli aggiornamenti basta semplicemente loggarsi al proprio account. Gli update/patch vengono applicati utilizzando pacchetti Snap.

Che qualcuno poi finisca per usarlo… in produzione?