0x90.it - https://www.0x90.it/come-proteggere-un-server-dalla-vulnerabilita-linux-dirty-cow

Come proteggere un server dalla vulnerabilità Linux Dirty COW

Come proteggere un server dalla vulnerabilità Linux Dirty COW

Introduzione

In data 19 ottobre 2016 è stata scoperta una vulnerabilità di privilege escalation nel kernel Linux. Il bug è stato rinominato Dirty COW dato che il problema di fondo sta nel modo in cui il kernel gestisce il Copy-on-write (COW). Dirty COW esiste da molto tempo, almeno dal 2007 con la versione 2.6.22 del kernel, quindi la maggior parte dei server è a rischio.

Sfruttare questa vulnerabilità vuol dire che nel vostro server un regolare utente senza privilegi può ottenere il permesso di scrittura per ogni file che può leggere, e quindi può aumentare i propri privilegi nel sistema. Potrete trovare maggiori informazioni su CVE-2016-5195 sui siti di Canonical [1], Red Hat [2] e Debian [3].

Fortunatamente le principali distribuzioni hanno già provveduto a rilasciare una fix. Tutte le immagini [delle VPS, NdT] base di DigitalOcean sono state aggiornate in modo da avere le versioni del kernel con la patch applicata, quindi le prossime Droplets [le VPS di DigitalOcean, Ndt] che create non avranno bisogno di essere aggiornate. Tuttavia, se state utilizzando un vecchio server, potete seguire questa guida per assicurarvi di essere protetti.

Verificare la vulnerabilità

Ubuntu/Debian

Per vedere se il vostro server ne è affetto, controllate la versione del vostro kernel.

$ uname -rv

Avrete un output del tipo:

4.4.0-42-generic #62-Ubuntu SMP Fri Oct 7 23:11:45 UTC 2016

Se la vostra versione è meno recente delle seguenti significa che ne siete affetti:

  • 4.8.0-26.28 per Ubuntu 16.10
  • 4.4.0-45.66 per Ubuntu 16.04 LTS
  • 3.13.0-100.147 per Ubuntu 14.04 LTS
  • 3.2.0-113.155 per Ubuntu 12.04 LTS
  • 3.16.36-1+deb8u2 per Debian 8
  • 3.2.82-1 per Debian 7
  • 4.7.8-1 per Debian unstable

CentOS

Certe versioni di CentOS, per testare la vulnerabilità del vostro server, possono usare questo script fornito da RedHat per RHEL [4]. Per provarlo, per prima cosa scarichiamo lo script.

$ wget https://access.redhat.com/sites/default/files/rh-cve-2016-5195_1.sh

Ora eseguitelo con bash.

$ bash rh-cve-2016-5195_1.sh

Se siete vulnerabili vedrete un output come questo:

Your kernel is 3.10.0-327.36.1.el7.x86_64 which IS vulnerable.
Red Hat recommends that you update your kernel. Alternatively, you can apply partial
mitigation described at https://access.redhat.com/security/vulnerabilities/2706661 .

Riparare la vulnerabilità

Fortunatamente, applicare la correzione è semplice: aggiornate il vostro sistema e riavviate il vostro server.

In Ubuntu e Debian aggiornate i vostri pacchetti usando apt-get.

$ sudo apt-get update && sudo apt-get dist-upgrade

Potete aggiornare tutti i vostri pacchetti in CentOS 6 e 7 usando sudo yum update ma, se per risolvere il bug volete aggiornare solamente il kernel, usate:

$ sudo yum update kernel

Al momento siamo ancora in attesa di una correzione per CentOS 5. Nel frattempo potete usare questa soluzione [5] dal bug tracker di Red Hat.

Nelle Droplets più datate, con la gestione del kernel esterna, è inoltre necessario selezionare il kernel GrubLoader di DigitalOcean. Per farlo andate nel pannello di controllo e cliccate sul server che volete aggiornare. Cliccate quindi Kernel nel menu sulla sinistra e selezionate il kernel GrubLoader. Potete approfondire la modalità di aggiornamento dei kernel della vostra Droplet in questa guida alla gestione del kernel [6]. Le nuove Droplet con la gestione del kernel interna possono saltare questo passaggio.

Per concludere, avete bisogno di riavviare il vostro server per applicare i cambiamenti.

$ sudo reboot

Conclusioni

Assicuratevi di aggiornare i vostri kernel Linux per essere protetti da questo bug di privilege escalation.

Autore: Hazel Virdó [7]

Traduzione di Zantx dell’articolo https://www.digitalocean.com/community/tutorials/how-to-protect-your-server-against-the-dirty-cow-linux-vulnerability [8] Copyright © 2016 DigitalOcean™ Inc.