Tutti gli articoli di Raoul Scarazzini

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!

OpenShift Origin cambia nome in OKD con la versione 3.10

Facebooktwittergoogle_plusredditlinkedin

Grandi novità alle porte per la versione community della blasonata piattaforma per container di Red Hat, OpenShift. Infatti con la versione 3.10 di OpenShift Origin il progetto cambia nome, diventando OKD.

Sul blog del progetto la scelta viene così motivata:

… to better represent our project as a distribution of Kubernetes, align our terminology with the larger cloud-native community naming conventions, and clarifies how this upstream project functions within the Red Hat OpenShift product line

Per meglio rappresentare il nostro progetto come una distribuzione di Kubernetes, per allineare la nostra terminologia con le naming convention utilizzate dalla maggioranza dei progetti community cloud-nativi e chiarire come questo progetto upstream si relaziona all’interno della linea di prodotti Red Hat OpenShift.

Quindi un nuovo nome, un nuovo sito, https://okd.io/ ed un nuovo logo a partire dalla versione attualmente disponibile, la 3.10.

Gli stessi manutentori del progetto si aspettano un poco di confusione all’inizio, ma grandi benefici a tendere in quanto la motivazione principale di questa mossa è proprio garantire la chiarezza e la continuità del progetto, anche perché il codice rimarrà nel repository GitHub openshift/origin pertanto nessuna reale modifica andrà effettuata da parte di chi usualmente collabora con il progetto.

E particolare enfasi è posta in quest’ultimo aspetto nel post:

We are not forsaking our origins.

Non abbandoniamo le nostre origini.

Avanti così quindi!

per

OpenSource Hardware Association revoca il primo certificato

Facebooktwittergoogle_plusredditlinkedin

Sono diversi anni che ormai seguiamo l’evoluzione dell’Open Source Hardware Association e poco meno di un mese fa raccontavamo di come l’associazione avesse creato il certification logo, atto a dimostrare che l’hardware in questione rispettasse i dogmi imposti in fatto di apertura delle specifiche.

Ebbene, in questo articolo apparso sul blog della OSHWA viene raccontato come, per la prima volta nella storia del programma di certificazione Open Source Hardware, sia stata revocata una certificazione precedentemente assegnata.

Il caso riguarda la stampante 3d MOTEDIS XYZ, e la motivazione è la seguente:

…we have been unable to obtain a copy of the documentation to post publicly. Without the documentation, the XYZ is no longer in compliance with the program. Therefore OSWHA revoked the certification.

Non siamo stati in grado di recuperare una copia della documentazione pubblicata pubblicamente. Senza la documentazione, la XYZ non è più conforme al programma. Pertanto OSWHA ha revocato la certificazione.

Nessuna documentazione, nessuna certificazione. Semplicissimo.

Ciò che si sta discutendo ora all’interno dell’associazione è però un altro tema, direttamente collegato a questa vicenda: chi deve mantenere le documentazioni? È giusto che se ne faccia carico OSWHA (con i benefici, ma anche i costi che ne deriverebbero) oppure sono i produttori a doversene fare carico?

Per ora OSWHA ritiene corretto l’approccio decentralizzato, ma la discussione continuerà sul forum dell’associazione.

Staremo a vedere!

Linux Journal racconta la storia di Git

Facebooktwittergoogle_plusredditlinkedin

Conoscete tutti la storia di Git? È presumibile che tutti sappiano come l’autore del più popolare software di versioning sia Linus Torvalds, certo, ma i dettagli della sua genesi?

Questo lungo articolo di Zack Brown per Linux Journal, racconta moltissimi succosi dettagli in merito a come Git è nato e cosa ha portato Torvalds a compiere determinate scelte.

Ad esempio, sapevate che inizialmente non esisteva nessun sistema di versioning per gestire le patch? I contributori dovevano inviare messaggi al gruppo Usenet del Kernel e lo stesso Torvalds, a mano, gestiva i merge. Questo significava che l’unica via per risalire ad una determinata modifica era di effettuare un comando diff su due intere versioni, con chiaramente tutti i disagi che questo comportava.

Sapevate poi che, non sopportando CVS e subversion (i software di versioning disponibili negli anni 2000), Torvalds optò per una soluzione commerciale, closed-source, chiamata BitKeeper? Pensate un po’, il software open per antonomasia, il più importante di tutti, colui che ha determinato l’inizio dell’era Linux, è stato gestito da un software chiuso. Incredibile, vero? A tutte le (comprensibili) critiche mosse nei suoi confronti l’affezionato dittatore benevolo rispondeva semplicemente…

Non sono un fanatico del software libero

Inevitabilmente i nodi per BitKeeper vennero al pettine quando Andrew Triggel (creatore di Samba e co-creatore di rsync) tentò di fare il reverse engineering del prodotto usato da Torvalds, Larry McVoy (proprietario della società BitMover distributrice di Bitkeeper) decise di impedirne il suo utilizzo da parte degli sviluppatori del Kernel, bloccandone di fatto gli sviluppi (da notare come la licenza di utilizzo di Bitkeeper per il progetto Kernel non prevedesse il pagamento di denaro).

A questo punto accadde qualcosa mai successo dal 1991: Torvalds smise completamente di sviluppare il Kernel e creò Git.

Il resto, come si dice, è storia.

Il futuro dell’intelligenza artificiale spiegato, in un film, da chi la crea

Facebooktwittergoogle_plusredditlinkedin

Red Hat ha presentato il video “Road to A.I., parte della serie “Open Source Stories“, nel quale viene analizzato lo stato attuale degli studi A.I. e soprattutto come questi siano guidati nella totalità da software open-source.

La rassegna a cui il film è stato iscritto si chiama “Real to Reel International Film Festival” ed è così descritta:

The mission of the Real to Reel International Film Festival is to offer a forum for independent film, video and multimedia artists from around the world to showcase their talents and expose the works of these artists to the region

La missione del Real to Reel International Film Festival è quella di offrire un forum per i film indipendenti, i video artisti e gli artisti multimediali da tutto il mondo per presentare il proprio talento ed promuovere il proprio lavoro alla regione.

All’interno del documentario è interessante notare come il primo richiamo sull’ambito di utilizzo dell’A.I. sia riferito all’automobilismo che, di fatto, è la prima cosa che viene in mente alle molte persone intervistate nel video. Proprio le interviste costituiscono un elemento molto avvincente di questo film poiché permettono di farsi un’idea di come la persona non tecnica percepisce l’ambito dell’intelligenza artificiale. La risposta cioè alla domanda: ma come funziona?

Ecco il video:

Buona visione!

Red Hat rende OpenSource lo scanner per eseguibili potenzialmente veicolo di Spectre

Facebooktwittergoogle_plusredditlinkedin

Red Hat ha reso disponibile uno strumento di analisi in grado di identificare potenziali attacchi volti a sfruttare la arcinota vulnerabilità Spectre (precisamente la variante 1 di Spectre) all’interno di file binari.

La modalità con cui l’eseguibile può essere invocato è semplice:

x86_64-scanner vmlinux --start-address=0xffffffff81700001

ed il risultato potrà essere un rassicurante:

X86 Scanner: No sequences found.

O un ben più preoccupante esito positivo:

X86 Scanner: Possible sequence found, based on a starting address of 0:.
X86 Scanner: 000000: nop.
X86 Scanner: COND: 000001: jne &0xe .
X86 Scanner: 00000e: jne &0x24 .
X86 Scanner: LOAD: 000010: mov 0xb0(%rdi),%rcx.
X86 Scanner: 000017: mov 0xb0(%rsp),%rax.
X86 Scanner: 00001f: nop.
X86 Scanner: LOAD: 000020: mov 0x30(%rcx),%rbx.

Inutile dire come il livello di competenze necessario per concepire anche solo lo scan del file stesso (in questo esempio è stato analizzato proprio il kernel stesso, vmlinux, l’eseguibile che diventerà pid 0 all’interno del sistema) sia decisamente elevato, ma nulla vieta di poter replicare gli esempi forniti.

Più importante di tutto il resto: il tool in questione è stato rilasciato in forma open-source, perciò chiunque può analizzarne il codice e, con molta pazienza e competenza, carpire un po’ di più in merito a questa fastidiosa vulnerabilità.

Curiosi su come fare? Ecco un piccolo how-to basato su Fedora 28:

Per prima è necessario scaricare e decomprimere il file scanner:

$ wget https://people.redhat.com/~nickc/Spectre_Scanner/scanner.tar.xz
$ tar -xJf scanner.tar.xz
$ cd scanner

A questo punto, nel sistema andrà installato il pacchetto binutils-devel, necessario alla compilazione del sorgente:

$ sudo dnf install binutils-devel

E scaricati i sorgenti dello stesso pacchetto, poiché alcune librerie necessarie non sono presenti nel pacchetto devel:

$ wget https://ftp.gnu.org/gnu/binutils/binutils-2.29.1.tar.xz
$ tar -xJf binutils-2.29.1.tar.xz

Quindi, prima di lanciare il fantomatico comando make, all’interno del file makefile andranno impostate le seguenti variabili:

all: x86_64-scanner
...
...
...
# If you are building the tool in a separate directory
# to the sources, then you will need to add a path to
# the scanner.h header file.
#CFLAGS += -I /path/to/scanner/sources
CFLAGS += -I /home/rasca/scanner

# The scanner uses some header files that are part of
# the binutils sources, but which are not normally
# distributed with binary packages. (eg elf/internal.h)
# You can get the binutils sources from:
# https://ftp.gnu.org/gnu/binutils/
#CFLAGS += -I /path/to/binutils/sources/include
CFLAGS += -I /home/rasca/scanner/binutils-2.29.1/include

Dove chiaramente /home/rasca andrà sostituito con la vostra home directory. A questo punto tutto è pronto per la compilazione:

$ make
gcc -c scanner.c -Wall -I. -O3 -I /home/rasca/scanner -I /home/rasca/scanner/binutils-2.29.1/include
gcc -c x86_64-scanner.c -Wall -I. -O3 -I /home/rasca/scanner -I /home/rasca/scanner/binutils-2.29.1/include
gcc scanner.o x86_64-scanner.o -o x86_64-scanner -lopcodes -lbfd -liberty -lm -lz -ldl

L’esempio riportato all’inizio si preoccupava di analizzare un file denominato vmlinux, ossia il kernel del sistema, per fare lo stesso sarà necessario copiare il proprio kernel nella directory locale e decomprimerlo in modo da ottenere il file vmlinux (se siete curiosi sul perché di questi comandi a questo link si trova un’esauriente spiegazione):

$ wget -O extract-vmlinux https://raw.githubusercontent.com/torvalds/linux/master/scripts/extract-vmlinux
$ chmod +x extract-vmlinux
$ ./extract-vmlinux vmlinuz-4.17.6-200.fc28.x86_64 > vmlinux

Sarà possibile eseguire infine lo scanner:

$ ./x86_64-scanner vmlinux --start-address=0xffffffff81700001
X86 Scanner: No sequences found.

In questo caso il kernel non presenta vulnerabilità. Per fortuna, aggiungerei 🙂

È tutto, buona verifica!

C’è vita oltre Devuan, ma Artix, un’altra distribuzione senza systemd, ha bisogno di aiuto!

Facebooktwittergoogle_plusredditlinkedin

Abbiamo sempre seguito da vicino le evoluzioni della distribuzione Devuan, unica nel suo genere in quanto fa dell’assenza di systemd il suo punto di forza. È interessante però scoprire come esistano altre distribuzioni che hanno rinunciato a systemd. Tra queste Artix Linux tra le sue FAQ alla domanda “Why?”(perché?) risponde chiaramente:

Why? Because systemd is bad.

Perché? Perché systemd è male.

e al di là di questo i creatori della distribuzione forniscono tutta una serie di argomentazioni per giustificare la necessità di rinunciare a systemd.

Ebbene Artix Linux è salita recentemente agli onori della in quanto necessita di packagers, ossia di manutentori di pacchetti che aiutino a rendere disponibile il software all’interno della distribuzione. Unico requisito richiesto è sapere come funzione PKGBUILD, ma in ogni caso sono garantiti aiuto e training per cominciare ad essere produttivi.

È chiaro come mantenere un’intera distribuzione sia qualcosa di estremamente complicato e richieda soprattutto una gran quantità di tempo, si fa presto a capire come in situazioni simili la forza lavoro non sia mai abbastanza. Da qui la chiamata alle armi. Come e perché gli sforzi profusi in questa distribuzione non possano confluire in Devuan (o vice versa) non è dato saperlo, ma se volete spendere parte del vostro tempo ad aiutare questo progetto è sufficiente rispondere alla chiamata sul forum di Artix.

In bocca al lupo!