Università degli studi di Roma La Sapienza. Facoltà di Scienze Matematiche Fisiche e Naturali. Laurea Triennale in Informatica

Transcript

1 Università degli studi di Roma La Sapienza Facoltà di Scienze Matematiche Fisiche e Naturali Laurea Triennale in Informatica Relazione di tirocinio Aspetti di sicurezza in macchine virtuali: Realizzazione di un prototipo di protezione della integrità del kernel linux su macchina guest. Candidato Matteo Signorini Responsabile Dott. Roberto Di Pietro Corresponsabile Dott. Flavio Lombardi a.a. 2008/2009

2 INDICE i Indice 1 Introduzione Applicazioni della Virtualizzazione Tecnologie di Virtualizzazione Categorie Contributi Supporto Hardware alla Virtualizzazione Tecnologia Intel - VT Tecnologia AMD-V Software di Virtualizzazione KVM Componenti di KVM Gestione delle Macchine Virtuali Vantaggi Svantaggi Virtualizzazione e Sicurezza (Tecniche di Attacco e di Difesa) Stato dell Arte File Nascosti Il FileSystem /proc Processi Nascosti Moduli Nascosti Redirezione di Funzioni di Sistema /dev/mem Il Progetto KVMLSP Architettura Requisiti Implementazione Analisi delle prestazioni 49 7 Conclusioni 56

3 ii ELENCO DELLE FIGURE Elenco delle figure 1 Isolamento Sviluppo e Testing Consolidamento Migrazione Bilanciamento del carico di lavoro Disaster Recovery Emulazione Virtualizzazione Completa Para-Virtualizzazione Virtualizzazione al livello SO Virtualizzazione delle Applicazioni Livelli di privilegio in Linux Modelli Diagramma esecuzione del guest in kvm [26] Architettura dell Hypervisor KVM Normale esecuzione di una system call (getdents) Redirezione della system call getdents Struttura di una generica task struct Navigazione tra le task struct Inserimento di codice malevolo all interno di una system call Interrupt Descritor Table (IDT) Clonazione della system call table Clonazione della Interrupt Descriptor Table Architettura di KVMLSP Schema di avvio di KVM Inizializzazione strutture kernel Struttura di esecuzione di KVMLSP Inizializzazione memoria in KVMLSP Test Make Test Lame Test Untar Test Execl Test FileCopy Test Pipe Test Process Test Shell Script

4 1 1 Introduzione Stiamo assistendo in questi ultimi anni all evoluzione delle tecnologie di virtualizzazione. Tra le svariate applicazioni della virtualizzazione, una particolarmente degna di nota è quella legata alla sicurezza informatica dei sistemi operativi. Una delle più comuni filosofie di difesa informatica è quella basata su differenti livelli di protezione denominati strati di sicurezza 1 (security layer). Questa filosofia, denominata difesa in profondità 2 (defense in depth), consiste nell uso di differenti tecniche di sicurezza per mitigare i rischi dovuti alla compromissione di un singolo livello. La defense in depth basa una prima parte della sua efficacia sulla difficoltà progressiva dei vari strati e sul numero di questi ultimi. Il secondo punto di forza risiede invece nell isolamento dei vari strati. La virtualizzazione è una tecnica che consente di ripartire le risorse di un sistema in ambienti di esecuzione multipli. Il concetto di macchina virtuale nasce negli anni 60 da parte di IBM con VM/370[17]. L idea di sviluppare del software che simuli una macchina reale nasce dalla necessità di condividere singole risorse fisiche, a quei tempi molto costose, fra più utenti. In principio per virtualizzazione si intendeva un meccanismo per suddividere una macchina reale in più copie della stessa, garantendo la compatibilità del software, l isolamento e, per quanto possibile, prestazioni simili a quelle originali. Dagli anni 60 in poi si è assistito ad una notevole evoluzione dell hardware, diffusione di personal computer e sistemi operativi multiutente che hanno portato a rendere sempre più raro l utilizzo della virtualizzazione. Oggi tale fenomeno è ridiventato attuale. I sistemi moderni sono divisi in due componenti: Host, macchina fisica e Guest, macchina virtuale. Per creare una o più macchine virtuali è necessario un sistema operativo ospitante in esecuzione, host o hypervisor, che esegua un software di virtualizzazione che crea ad alto livello l ambiente in cui eseguire le varie macchine virtuali, guest. Ogni macchina virtuale viene eseguita come se fosse un normale software che comunica indirettamente con l hardware tramite il software di controllo che agisce a basso livello. Dal punto di vista hardware, da alcuni anni, Intel e AMD hanno sviluppato indipendentemente due set di istruzioni addizionali a supporto della virtualizzazione per macchine x86. Esse non sono tra loro completamente compatibili, ma offrono funzionalità molto simili[34][15]. Entrambe permettono ad una macchina virtuale di eseguire un sistema operativo ospite senza incorrere in notevoli perdite prestazionali causate dall emulazione software di alcuni dispositivi. Partendo da queste considerazioni e studiando le metodologie di attacco e difesa dei sistemi operativi attuali, si è pensato di realizzare un progetto, denominato KVMLSP (KVM Linux Security Project), per la creazione di un sistema di monitoraggio dell integrità del sistema operativo guest. Il cuore del controllo viene dislocato in un livello inferiore rispetto al sistema in analisi in modo tale da essere il più trasparente possibile e non invasivo 1 Si può considerare il sistema operativo come un insieme di strati interagenti tra di loro. 2 La difesa in profondità consiste nella protezione dei vari strati di cui è composto un sistema con delle tecniche di sicurezza in modo tale che la compromissione di uno strato non pregiudichi gli altri.

5 2 1 INTRODUZIONE nei confronti dell utente fruitore di servizi dislocati in una Virtual Machine. Il progetto si avvale del supporto software alla virtualizzazione offerto da Qemu-KVM[36][11]. 1.1 Applicazioni della Virtualizzazione L impiego della virtualizzazione permette di offrire un maggior numero di funzionalità [31] [30] [10] e, al tempo stesso, di ridurre i costi. Con la virtualizzazione, le risorse di dati e di elaborazione, server e storage, vengono raggruppate in maniera logica in un unico insieme di risorse. Descriviamo qui di seguito alcuni vantaggi offerti dalla virtualizzazione: flessibilità : grazie alla virtualizzazione è possibile convertire una macchina fisica in virtuale e viceversa, clonare macchine per differenti fini, spostare una macchina virtuale da un host ad un altro senza interromperne l esecuzione, clusterizzare lo stesso strato di virtualizzazione per permettere la migrazione automatica delle macchine virtuali in caso di problemi dell hardware host; isolamento : usando le macchine virtuali, si ottiene un isolamento completo e trasparente per i sistemi guest, come se ognuno di essi eseguisse su dell hardware dedicato. Ogni macchina virtuale può raggiungere diversi livelli d isolamento, a seconda che si tratti di virtualizzazione completa o para-virtualizzazione;(figura 1) Figura 1: Isolamento sviluppo e testing : la virtualizzazione, anche in questo contesto, è un ottima soluzione che permette di avere a disposizione ambienti di test operativi in poco tempo, ad esempio clonando una macchina virtuale esistente su cui effettuare tutte le prove necessarie in sicurezza;(figura 2) consolidamento ed ottimizzazione : oggi è possibile consolidare i sistemi, mantenendo gli stessi livelli di sicurezza e prestazioni, cosa che non accadeva quando le tecnologie di virtualizzazione non erano ancora mature. È possibile consolidare numerose macchine virtuali su un numero limitato di sistemi e successivamente ripartizionare a piacimento le stesse in funzione del carico senza interrompere l operatività

6 1.1 Applicazioni della Virtualizzazione 3 Figura 2: Sviluppo e Testing delle singole macchine virtuali. Strumenti specializzati di gestione possono accendere, spegnere e spostare le macchine virtuali in base ad eventi configurabili. In tal modo è possibile ridurre la quantità dell hardware e ottenere un risparmio tangibile;(figura 3) Figura 3: Consolidamento disaccoppiamento tra hardware e servizi : con la virtualizzazione nascono i concetti di vista logica e vista fisica dell hardware. La realizzazione dipende dal tipo di virtualizzazione che si intende adottare, virtualizzazione completa o paravirtualizzazione. Entrambe rendono possibile sostituire l hardware o migrare le applicazioni con grande facilità e immediatezza;(figura 4) supporto al networking : è possibile emulare differenti segmenti di reti, switching e routing. Anche complesse architetture composte da segmenti di frontend, backend, DMZ 3 e management possono essere virtualizzate ed integrate nelle VLAN reali dando potenzialmente la possibilità di virtualizzare interi datacenter; 3 Demilitarized Zone ovvero Zona non coperta dal controllo del firewall etc. etc.

7 4 1 INTRODUZIONE Figura 4: Migrazione clustering : virtualizzando i server che faranno parte di un cluster, non solo sarà possibile effettuare un bilanciamento del carico su tali macchine, ma ci sarà la possibilità di bilanciare il carico dei processi che girano all interno di ogni singola macchina virtuale;(figura 5) Figura 5: Bilanciamento del carico di lavoro applicazioni / sistemi pronti da impiegare : un altro aspetto da non sottovalutare è il possibile mercato di macchine virtuali preconfigurate (su media e/o web), vendute con soluzioni ad hoc 4 o secondo modelli standard in pronta consegna; backup, disaster recovery, archiviazione : poiché ogni sistema è tipicamente in continua evoluzione, spesso nasce l esigenza di mantenere multiple versioni di tale sistema, tramite le quali rendere possibile un roll-back 5. Sfruttando la virtualizzazione, il disaster recovery risulta notevolmente semplificato: è possibile effettuare il 4 Soluzioni create specificatamente per la risoluzione di determinati problemi 5 ripristino

8 1.1 Applicazioni della Virtualizzazione 5 ripristino di una macchina virtuale in modo immediato e sicuro, rendendo possibile il ripristino dei servizi in tempi limitati. Anche il backup risulta essere facilitato, effettuare il backup di una macchina virtuale consiste nel copiare un numero estremamente limitato di file;(figura 6) Figura 6: Disaster Recovery La presente tesi nasce all interno del progetto sperimentale di ricerca condotto dal Dott. Roberto Di Pietro dell Università La Sapienza di Roma e dal Dott. Flavio Lombardi del Consiglio Nazionale delle Ricerche, mirato ad affrontare e risolvere alcune problematiche di sicurezza sulle macchine virtuali. Ci occuperemo di fornire una panoramica sullo stato dell arte e sugli strumenti di virtualizzazione x86 e infine sulla realizzazione del progetto KVMLSP (KVM Linux Security Project). Il software di virtualizzazione usato nel presente studio è KVM 6, un software composto da un LKM 7, che crea sistemi virtualizzati utilizzando la tecnologia Intel-VT[9] o AMD-V[36]. KVMLSP è il sistema sviluppato al fine di gestire la sicurezza delle macchine virtuali. L applicazione di quest ultimo ha come obiettivo il monitoraggio di ciò che accade su una macchina virtuale dalla macchina fisica che la ospita. Una delle peculiarità del presente progetto rispetto ad altri recentemente pubblicati è che si prefigge lo scopo di rimanere completamente trasparente alla macchina guest, non vengono infatti minimamente toccati ne il kernel del guest ne applicazioni di cui questo è composto. La trasparenza agli occhi del guest è un requisito fondamentale per la costruzione di un robusto sistema di sicurezza perché, grazie al supporto della virtualizzazione, ci garantisce che un ipotetico attaccante presente sulla macchina guest non possa rendersi conto della presenza di KVMLPS. Le operazioni di monitoraggio hanno come oggetto file o strutture dati di notevole importanza per un corretto funzionamento della macchina guest, con l obiettivo di rilevare eventuali modifiche o manomissioni non autorizzate. 6 Kernel-based Virtual Machine 7 Loadable Kernel Module

9 6 1 INTRODUZIONE 1.2 Tecnologie di Virtualizzazione L architettura di virtualizzazione usata per questo studio è denominata Platform Virtualization [21]. Questa è composta da un sofware lato host che crea uno o più ambienti simulati ( detti macchine virtuali ) destinati ad ospitare uno o più software guest. Il software guest che solitamente è esso stesso un Sistema Operativo è eseguito come se si trovasse realmente su una macchina fisica. In questo modo diversi Sistemi Operativi guest possono essere eseguiti contemporaneamente sulla stessa macchina fisica (host). Vengono ora elencate le terminologie a cui molto spesso si farà riferimento durante la presentazione di questo studio. Sistema Operativo (SO): è il software responsabile del controllo di una macchina, della gestione dei suoi componenti hardware e dei programmi che su di esso vengono eseguiti. SO guest: è il SO che viene eseguito su una Virtual Machine. SO-host: è il SO che viene eseguito sulla macchina fisica e sul quale vengono eseguite le macchine virtuali. Virtual Machines (VM): è una macchina logica avente la stessa architettura della macchina fisica che la ospita, solitamente una macchina fisica ospita più Virtual Machine. Virtual Machine Monitor (VMM): è uno strato di software, collocato tra SO e hardware fisico che controlla l esecuzione delle VMs. In questo modo le VMs hanno la sensazione di stare comunicando con l hardware fisico mentre invece stanno comunicando con il VMM. 1.3 Categorie Ci sono diverse definizioni del concetto di platform virtualization ; Si distinguono quindi le seguenti categorie. Emulazione In questo tipo di virtualizzazione(figura 7), l ambiente virtuale emula l architettura hardware richiesta da un certo guest che viene eseguito senza alcuna modifica. L emulatore può emulare parzialmente o completamente l hardware della macchina fisica tenendo presente che maggiore è l emulazione maggiori sono le capacità di simulare le operazioni consentite sull hardware fisico ma minori sono le prestazioni ottenute. Un campo in cui viene molto usata una virtualizzazione di questo tipo è quello dei cellulari, smartphone, palmari ed in generale tutti i dispositivi mobili. Ad esempio gli sviluppatori di applicazioni per cellulari, emulano il sistema operativo del telefono per effettuare la fase test di tali applicazioni.

10 1.3 Categorie 7 Vantaggi: capacità di simulare un ambiente hardware completamente differente da quello di cui è composta la macchina host. Svantaggi: scarse prestazioni Figura 7: Emulazione Virtualizzazione Completa Nella Virtualizzazione Completa(figura 8), un immagine di un SO guest non modificata viene eseguita all interno di un ambiente virtualizzato. La differenza tra la virtualizzazione di tipo completo e quella di tipo emulato è che tutti i SO guest eseguono sulla stessa architettura hardware. Tutti i SO guest supportano lo stesso hardware, il che permette a questi di eseguire molte istruzioni direttamente in hardware aumentando quindi notevolmente le prestazioni. Vantaggi: Possibilità di eseguire diverse versioni di SO anche provenienti da diversi produttori: Microsft Windows XP, Microsoft Windows Server, Linux, etc. Svantaggi: I SO guest sono creati da installazioni identiche a quelle effettuate su macchine reali e quindi lo spazio richiesto è notevole. Possono sorgere problemi causati da applicazioni che fanno uso intensivo del disco. Para-Virtualizzazione Nella para-virtualizzazione(figura 9) il VMM esporta una copia modificata dell hardware fisico. Questo strato esportato viene modificato per permettere ai SO guest di eseguire le istruzioni ad una velocità molto vicina alla velocità che si otterrebbe se il SO guest stesse eseguendo su una macchina fisica. I guest vengono di conseguenza modificati affinché determinate system call[25][20] effettuate da questi siano redirette verso il substrato esportato dal VMM piuttosto che verso l hardware fisico della macchina. Vantaggi: Leggero e veloce. Le immagini dei SO guest sono piccole e le prestazioni possono raggiungere livelli molto vicini a quelli ottenuti su macchine fisiche.

11 8 1 INTRODUZIONE Figura 8: Virtualizzazione Completa Svantaggi: Richiede di apportare delle modifiche ai SO guest che consentono a questi ultimi di usare le istruzioni fornite dal VMM. Non utilizzabile con SO proprietari come quelli appartenenti alla famiglia di prodotti Microsoft. Figura 9: Para-Virtualizzazione Virtualizzazione a livello SO Nella virtualizzazione a livello SO(figura 10) non ci sono macchine virtuali; la virtualizzazione è realizzata completamente all interno di un singolo SO. I sistemi guest condividono delle proprietà e dei driver comuni appartenenti al sottostante SO ma hanno comunque la sensazione di essere dei computer separati. Ciascun istanza guest esegue le proprie applicazioni,che possono essere completamente differenti dalle applicazioni delle altre istanze, e ciascuna ha il suo proprio file system 8, il suo indirizzo IP etc. etc. 8 Un File System è l insieme dei tipi di dati astratti necessari per la memorizzazione, l organizzazione gerarchica, la manipolazione, la navigazione, l accesso e la lettura dei dati.

12 1.4 Contributi 9 Vantaggi: Veloce, leggero, ed efficiente, con la capacità di supportare un elevato numero di istanze virtuali. Svantaggi: L isolamento delle singole istanze e la sicurezza dei dati sono molto problematici. Tutte le istanze virtuali devono supportare lo stesso SO. Figura 10: Virtualizzazione al livello SO Virtualizzazione delle Applicazioni La virtualizzazione delle applicazioni(figura 11), come qualsiasi altro tipo di virtualizzazione, richiede uno strato di virtualizzazione. Questo strato intercetta tutte le richieste che vengono effettuate dalle applicazioni virtualizzate verso il file system e le redireziona verso una locazione di memoria virtuale. Le applicazioni quindi sono completamente distaccate dai dispositivi hardware poiché comunicano solamente con lo strato di virtualizzazione. Questo permette ad applicazioni che sono incompatibili tra di loro di poter essere eseguite insieme: ad esempio Microsoft Internet Information Services 4.0,5.0 e 6.0 potrebbero essere eseguite fianco a fianco. In oltre aumenta anche la portabilità delle applicazioni, consentendo a delle applicazioni di eseguire in degli ambienti diversi da quelli per cui sono state sviluppate. Vantaggi: Aumenta la portabilità delle applicazioni. Permette ad applicazioni incompatibili tra loro di eseguire insieme. Svantaggi: Performance di esecuzione deludenti. Non tutte le applicazioni possono essere virtualizzate. 1.4 Contributi La realizzazione di questo studio è stata composta da due fasi:

13 10 1 INTRODUZIONE Figura 11: Virtualizzazione delle Applicazioni Analisi Implementazione Durante la fase di Analisi ho studiato le moderne tecniche di attacco ai sistemi operativi, usate dai più comuni rootkit in circolazione. Tale lavoro mi ha permesso di comprendere i punti deboli dei suddetti attacchi e di individuare le strutture dati del sistema operativo di cui era necessario controllare l integrità. Ho quindi studiato l architettura interna del sistema operativo Linux per comprendere in che modo le strutture sopra citate vengono usate ed in che modo sia possibile interagire con esse. Anche lo studio delle tecnologie di virtualizzazione è stato molto importante poichè tramite questo ho appreso in che modo la macchina host interagisce con il guest e mi è stato di conseguenza possibile avere un completo accesso alla macchina virtuale. Una volta definita la strategia di difesa sono passato alla fase di progettazione ed implementazione. La maggiore difficoltà incontrata in questa fase è stata la traduzione dello spazio di indirizzamento guest all interno del sistema operativo host. Completata con successo la fase di lettura della memoria guest sono passato all implementazione dell insieme di funzioni necessarie alla creazione del checksum di una porzione di memoria guest. Successivamente ho modificato il codice sorgente di Kvm per fare in modo che il controllo di integrità venisse eseguito ad intervalli temporali di ampiezza variabile. Per rendere stabile Kvm una volta aggiunto il mio codice, ho dovuto implementare anche delle tecniche di sincronizzazione tra le mie funzioni e quelle di kvm al fine di evitare situazioni problematiche quali ad esempio l accesso simultaneo alla memoria guest. In fine ho realizzato degli script automatici di test per l analisi delle prestazioni del progetto creato. Tali script sono stati necessari per eseguire un elevato numero di test in modo automatico ma soprattutto per filtrare ed elaborare i dati ottenuti dai test di cui sopra.

14 11 2 Supporto Hardware alla Virtualizzazione Le tecnologie,analizzate in questo studio, che forniscono supporto hardware alla virtualizzazione sono: Intel-VT e AMD-SVM. Uno dei problemi principali che il supporto hardware alla virtualizzazione risolve è legato al livello di privilegio [13] (figura 12) con il quale viene eseguito il SO. Attualmente le cpu hanno 2 bit per esprimere tale livello di privilegio sotto forma di flag. Ogni livello di privilegio (conosciuto anche con il nome di ring) consente ad un software di eseguire un insieme di istruzioni macchina piú o meno ampio. Utilizzando i suddetti livelli Figura 12: Livelli di privilegio in Linux di privilegio é possibile costruire 4 modelli(figura 13) di esecuzione delle macchine virtuali, tali modelli sono: a) Tradizionale: SO a livello 0 e software a livello 3 b) 0/1/3: VM Monitor a livello 0, SO a livello 1 e software a livello 3 c) 0/3/3: VM Monitor a livello 0 e SO insieme al software a livello 3 d) VT-X: VM Monitor a livello 0 Di conseguenza hypervisor come quello di KVM non sono ancora pienamente compatibili con i SO che hanno kernel proprietario. Vantaggi offerti dal supporto hardware alla virtualizzazione Grazie al supporto hardware alla virtualizzazione possiamo porre soluzione a diversi problemi legati alla virtualizzazione nei seguenti modi: 1. Il VMM ha uno spazio di memoria dedicato solo ad esso e quindi non interferisce con quello delle applicazioni guest, compreso il SO guest. 2. Le transizioni sono gestite attraverso la struttura dati VMCS 9 ( o VMCB 10 [2] a seconda della piattaforma hardware usata ) che risiede nello spazio di memoria dedicato al VMM. 9 Vitrual Machine Control Structure (Intel). 10 Virtual Machine Control Block (Amd).

15 12 2 SUPPORTO HARDWARE ALLA VIRTUALIZZAZIONE Figura 13: Modelli 3. Il software è eseguito al livello di privilegio per il quale è stato progettato,in oltre la presenza del VMM situato tra l hardware fisico ed il SO guest é completamente invisibile a quest ultimo. Tutti i programmi, compreso il SO guest, sono eseguiti al livello di privilegio di cui necessitano. 4. Viene eliminata la possibilità di accedere in modo non corretto ad uno stato privilegiato. 5. La struttura dati VMCB (o VMCS a seconda dell architettura) controlla le interruzioni e le eccezioni. 6. Sysenter e Sysexit ora sono abilitate in quanto il SO può computare virtualmente al livello di privilegio I registri GDT 11 ed LDT 12 [22] non accessibili da nessun software sono stati resi disponibili alla VM. 11 La GDT o Global Descriptor Table è una struttura dati usata dai processori della famiglia x86 di Intel, usata per definire varie aree di memoria nell esecuzione di un software, come per esempio l indirizzo base, la dimensione e i privilegi di accesso come l eseguibilità e la scrittura. Queste aree di memoria sono chiamate segmenti nella terminologia Intel. 12 La LDT o Local Descriptor Table è una tabella di memoria usata nelle architetture x86 in modalità protetta e contenente i descrittori di segmento della memoria: grandezza, eseguibilità, scrivibilità, accesso privilegiato, presenza attuale in memoria etc. etc.

16 2.1 Tecnologia Intel - VT Tecnologia Intel - VT L estensione di virtualizzazione sviluppata da Intel per le architetture x86 è denominata Intel VT (Intel-Virtualization-Technology o Vanderpool). Oltre alle istruzioni base dei processori Intel, la tecnologia VT supporta due istruzioni: VMX root e VMX non - root, le quali possono presentarsi a tutti e quattro i livelli di privilegio permettendo alla VM di usare più livelli di privilegio e al SO di essere eseguito al livello di privilegio per il quale è stato progettato. Partendo dalla definizione di queste due istruzioni vengono successivamente definite due transazioni, chiamate transizioni VMX: VMX root VMX non - root. VMX non - root VMX root. Questo sistema consente alla VM di controllare delle operazioni che potrebbero risultare dannose per se stessa(es. terminazione incondizionata). Altre istruzioni possono essere configurate per far uscire la VM in condizioni controllate, infatti è possibile modificare la bitmap che descrive per quali eventi 13 la VM dovrebbe terminare e per quali no. Quando ci troviamo nello stato VMX non - root il controllo del processore è limitato, solo l hypervisor ha completo controllo di quest ultimo. È importante citare i registri VMenter e VMexit, nei quali vengono salvate le informazioni sullo stato del processore. Ogni VMexit registra le motivazioni (log) per cui è uscita. Ciclo di vita di un Hypervisor 1. L hypervisor abilita il set di comandi VMX eseguendo il comando VMXon. 2. Con i comandi VMenter, VMlaunch e VMresume, l hypervisor può attivare una VM o ripristinare la sua esecuzione. 3. Con il comando VMexit, il controllo torna all hypervisor che potrà analizzare le motivazione per le quali è stato invocato. 4. Eventualmente l hypervisor potrà interrompere la sua stessa esecuzione disabilitando il set di comandi VMX con il comando VMXoff. Virtual Machine Control Structure Il Virtual Machine Control Structure è una struttura dati aggiuntiva che gestisce le transazioni, le chiamate a VMentry/exit e lo stato del processore nelle operazioni VMX non - root. È divisa logicamente in sezioni, tra le più rilevanti citiamo quella dedicata allo stato del guest, quella dedicata allo stato dell host ed altre due dedicate ai registri VMenter e VMexit. 12 Matrice di bit. 13 Eccezioni che possono essere eseguite dalla VM

17 14 2 SUPPORTO HARDWARE ALLA VIRTUALIZZAZIONE Le prime due aree contengono diverse sezioni dedicate ai processori del guest e dell host, mentre le seconde due servono all hypervisor per controllare la corretta entrata/uscita nella/dalla VM. L hypervisor può utilizzare diversi VMCS per diverse macchine virtuali. Per una macchina virtuale che utilizza più processori virtuali ci sarà un VMCS per ognuno di essi. L hypervisor avrà quindi il compito di caricare e puntare al corretto VMCS a seconda della macchina virtuale e del processore virtuale che questa dovrà utilizzare. VMenter Questa istruzione si occupa di caricare lo stato del processore dalla guest - state area nel VMCS. L hypervisor ha il compito di effettuare i controlli sullo stato del processore e sulla struttura VMCS affinché si eviti il caricamento da quest ultima di valori errati o che lo siano quelli presenti nei registri del processore fisico. VMexit Questa istruzione salva lo stato del processore nella guest - state area e carica lo stato di questo dalla host - state area. Ogni invocazione della VMexit salva informazioni dettagliate sullo stato del processore nel VMCS per facilitare l implementazione dell hypervisor. L hypervisor dovrà farsi carico di controllare lo stato del processore affinché questi risulti essere in uno stato legale. Interrupt La tecnologia VT offre il supporto per la virtualizzazione degli interrupt. Viene in oltre offerta la possibilità di selezionare quali interrupt virtualizzare. L hypervisor può configurare il comando VMenter in modo da fare un inserimento nella VM di interrupt od eccezioni che verranno prese in considerazione in modo tempestivo dal processore. In questo modo anche segnali che pervengono alla VM mentre la sua esecuzione è sospesa verranno processati non appena questa verrà ripristinata. Al contrario, quello che accadeva senza supporto hardware era che l hypervisor si doveva far carico di registrare gli interrupt per ogni VM e replicarli quando quest ultima riprendeva la sua esecuzione. 2.2 Tecnologia AMD-V L estensione di virtualizzazione di AMD per l architettura x86 a 64-bit (AMD64) è denominata AMD Virtualization, conosciuta anche con l abbreviazione AMD - V o attraverso il nome in codice Pacifica [1]. La tecnologia AMD - V è stata progettata con l obiettivo di fornire le seguenti funzionalità: Un meccanismo per passare velocemente da istruzioni hypervisor a istruzioni guest. L abilità di intercettare istruzioni o eventi selezionati nel sistema operativo guest. Accessi alla memoria esterna protetti, DMA[16]. Assistenza per la gestione degli interrupt e supporto per gli interrupt virtuali. Una TLB[42] per guest/host per ridurre il costo dovuto alla virtualizzazione. Le estensioni hardware del processore AMD - V offrono le seguenti fuzionalià:

18 2.2 Tecnologia AMD-V 15 Cambio di stato: VMRUN, VMSAVE, VMLOAD. Intercettazione : permettono all hypervisor di intercettare operazioni critiche del SO guest. Interrupt e APIC[8]: intercettazione di interrupt fisici, supporto ad interrupt virtuali, virtualizzazione dei registri APIC. Intercettazione del System Management Mode 14. Protezione da accessi alla memoria esterna, DMA. Istruzione di sicurezza SKINIT 15. Le funzionalità sopra citate si riferiscono allo stato della macchina virtuale e necessitano di alcune informazioni contenute in una particolare struttura dati, il Virtual Machine Control Block (VMCB). Virtual Machine Control Block Prima di ripristinare o sospendere l esecuzione di una VM, si accede al VMCB per registrare alcune informazioni riguardanti il processore, la memoria e la mappatura dell I/O[46]. Il Virtual Machine Control Block contiene le seguenti informazioni: 1. Una lista di istruzioni o eventi del guest da intercettare. 2. Dei bit di controllo che indicano azioni particolari da intraprendere prima che il codice del guest venga eseguito. 3. Stato del processore del guest. VMRUN L architettura AMD-V per il caricamento delle VMs si avvale dell istruzione VMRUN, la quale prende in input l indirizzo fisico dove risiede il VMCB. L istruzione VMRUN può essere eseguita sotto le seguenti condizioni: 1. Il livello di privilegio corrente è impostato a Il processore è in modalità protetta. 3. Viene impostata la modalità No - Execute (NX) per alcune aree di memoria. VMRUN salva lo stato del processore e carica quello nuovo, ricordando il minimo quantitativo di informazioni. Se si ha la necessità di effettuare salvataggi o caricamenti più complessi si utilizzano appositi comandi quali: 14 Il System Management Mode (o SMM) è una modalità di esecuzione nella quale le esecuzioni di software standard (incluso il Sistema Operativo) sono sospese mentre altro software come ad esempio un firmware o un debugger viene eseguito con i massimi privilegi. 15 Reinizializza il processore in modo tale da permettere il caricamento della VM in un ambiente sicuro

19 16 2 SUPPORTO HARDWARE ALLA VIRTUALIZZAZIONE VMSave VMLoad Operando quindi una suddivisione del carico di lavoro, le operazioni di cambio di contesto vengono gestite, la maggior parte delle volte, in modo molto rapido. La VMRUN controlla lo stato del guest appena caricato, se questo si trova in uno stato non legale il controllo del processore torna all host invocando la VMEXIT. VMEXIT La funzione VMEXIT, viene invocata dal processore quando si verifica un evento nel sistema, come ad esempio l uscita dal guest, per il quale si ha la necessità che il controllo torni all host. Interrupt Per facilitare la virtualizzazione degli interrupt, sono forniti i seguenti supporti sotto il controllo di flag nel VMCB: Interrupt a livello fisico: l hypervisor può richiedere che gli interrupt fisici, che causano l uscita dalla modalità guest di una VM, vengano gestiti da lui stesso. Interrupt Virtuali: l hypervisor può creare interrupt per un guest. Esso infatti controlla sia una copia virtuale della bitmap, presente sul processore, che descrive gli interrupt e sia dei registri che gestiscono le priorità di quest ultima(apic). Il guest si interfaccia direttamente con i registri virtuali e non con quelli presenti sul processore. Condivisione degli APIC fisici: AMD-V permette a vari guest di condividere un APIC fisico.

20 17 3 Software di Virtualizzazione KVM Attualmente esistono molti tipi di hypervisor[45][44][28], la maggior parte dei quali non utilizzano il supporto hardware alla virtualizzazione. L hypervisor si occupa dello scheduling dei processi e della gestione della memoria e spesso delega la gestione dell I/O ad un guest con permessi superiori rispetto agli altri. Poiché questo ha il completo controllo delle risorse hardware può restringerne la percentuale di quelle che vanno rese visibili ai SO guest. In generale un hypervisor ha a disposizione uno o più driver standard per una data risorsa hardware sulla macchina fisica e quindi al SO guest è presentata una versione standard dell hardware. KVM 16 [36] [26] è una soluzione di Virtualizzazione Completa per Linux su sistemi x86 (Intel VT or AMD-V) consistente in un modulo del kernel, che in quanto tale gode di tutti gli strumenti messi a disposizione dal kernel, ed in un sistema di emulazione dei dispositivi hardware (denominato Qemu) sviluppato prima di kvm e successivamente inglobato da quest ultimo per dare forma ad un software finale completo a cui è stato dato il nome di Qemu-Kvm. Di conseguenza ogni VM è vista dal kernel host come un normale processo Linux, e come tale, dispone di due modalità di esecuzione: kernel mode user mode KVM integra le modalità di esecuzione con una terza: guest mode Quest ultima è composta a sua volta da due modalità: kernel e user, quindi in totale si hanno quattro modalità di esecuzione: guest kernel mode guest user mode kernel mode user mode In sintesi le varie modalità operano come segue(figura 14): Guest mode: esegue codice non-i/o per il guest. Kernel mode: cambia il contesto, da host a guest, e gestisce le uscite dalla modalità guest quando si effettuano istruzioni I/O. User mode: effettua operazioni I/O per conto del guest. 16 Kernel-based Virtual Machine

21 18 3 SOFTWARE DI VIRTUALIZZAZIONE KVM Figura 14: Diagramma esecuzione del guest in kvm [26]

22 3.1 Componenti di KVM Componenti di KVM La semplicità di KVM viene messa in risalto dalla sua struttura(figura 15). Vi sono due componenti: Un device driver per gestire l hardware virtualizzato. Tale device driver, eseguito a livello kernel, fornisce un character device (/dev/kvm) per le comunicazioni con il modulo in user-space. Un componente a livello user-space per emulare l hardware. Questo modulo consiste in una versione modificata del processo Qemu 17 [11] Figura 15: Architettura dell Hypervisor KVM La versione modificata di Qemu mappa la memoria fisica del guest, invoca i kernel mode driver e li esegue in modalità guest. 3.2 Gestione delle Macchine Virtuali Come già precedentemente accennato, ogni macchina virtuale è vista dal kernel host come un processo, e come tale possono esservi applicati tutti gli strumenti standard di gestione offerti da Linux. È possibile quindi: Distruggere la macchina virtuale Interrompere la macchina virtuale 17 Qemu è un emulatore che offre il supporto alla virtualizzazione completa di un sistema.

23 20 3 SOFTWARE DI VIRTUALIZZAZIONE KVM Ripristinare la macchina virtuale Visualizzare le risorse utilizzate dalla macchina virtuale I permessi per il processo sono gestiti normalmente come quelli di tutti gli altri processi ovvero il processo eredita l etichetta dell utente che lo ha invocato. La caratteristica di avere le macchine virtuali rappresentate da comuni processi permette agli amministratori di sistema la gestione di queste attraverso comuni strumenti di amministrazione forniti dal sistema. 3.3 Vantaggi 1. Driver: KVM utilizza i driver standard del kernel Linux. KVM è la soluzione di virtualizzazione standard supportata da L. Torvalds. Poiché i driver sono aggiornati all ultima versione del kernel, si suppone che essi siano meno vulnerabili ad attacchi. 1. Aggiornamenti: KVM consiste in un unico modulo del kernel e di conseguenza è facilmente aggiornabile. Il passaggio da una versione ad un altra di KVM necessita la ricompilazione del progetto e la rimozione più reinserimento del modulo 18 KVM all interno del kernel. 1. Flessibilità: Il modulo KVM è indipendente dalla versione del kernel Linux nella quale viene inserito, quindi compatibile con ogni distribuzione che alla base abbia lo standard Linux kernel. KVM sfrutta la versione più recente del kernel Linux. 18 Grazie allo standard LKM (Linux Kernel Module) è possibile l inserimento e la rimozione di moduli del kernel senza dover ricompilare l intero kernel

24 3.4 Svantaggi Svantaggi 1. Driver: Essendo il kernel molto complesso e vasto, teoricamente questo è più soggetto a vulnerabilità e bug. Il demandare al kernel la gestione dei driver e non relegarlo in una macchina virtuale rende l intero sistema maggiormente esposto a rischi nell ambito della sicurezza. Debolezze dei driver, soprattutto quelli di terze parti il cui codice non è visionabile dalla comunità di sviluppo Linux, possono creare falle nella sicurezza ed aprire la strada ad eventuali attaccanti. 1. Flessibilità: Non c è il supporto alla para-virtualizzazione. Si richiede necessariamente un processore che supporti le tecnologie di supporto hardware alla virtualizzazione quali Intel-VT o AMD SVM.

25 224 VIRTUALIZZAZIONE E SICUREZZA (TECNICHE DI ATTACCO E DI DIFESA) 4 Virtualizzazione e Sicurezza (Tecniche di Attacco e di Difesa) Individuare le violazioni alle politiche di sicurezza è l obbiettivo principale di un IDS 19 [40]. Quando un kernel viene compromesso, ad esempio da un rootkit 20 [23] [47], le informazioni fornite da quest ultimo all HIDS 21 [19] divengono inattendibili. Molti HIDS atti a controllare attacchi al livello kernel assumono che quest ultimo non sia stato compromesso. In realtà, una volta che un attaccante penetra il kernel può installare strumenti per evitare di essere individuato, rendendo quindi falsa la precedente assunzione. Utilizzando delle parti di kernel non compromesso, si possono installare in queste dei software per l individuazione dei rootkit evitando quindi situazioni come quella sopra citata. Questa soluzione ha però anch essa i suoi difetti, infatti, un attaccante potrebbe accorgersi del software di verifica e progettare un rootkit in grado di raggirarlo. Soluzioni a questo problema sono basate su hardware ad hoc ma sono molto costose e richiedono il supporto del SO, quindi sono difficilmente applicabili su larga scala. Minacce Si definisce malware un qualsiasi software creato con il solo scopo di causare danni più o meno gravi al computer su cui viene eseguito. Il termine deriva dalla contrazione delle parole inglesi malicious e software e ha dunque il significato letterale di software malvagio. Si distinguono molte categorie di malware, anche se spesso questi software sono composti di più parti interdipendenti e rientrano pertanto in più di una classe. Le categorie di malware più comuni sono: Virus: si diffondono copiandosi all interno di altri software, o in una particolare sezione del disco fisso, in modo da essere eseguiti ogni volta che il file infetto viene aperto. Si trasmettono da un computer a un altro tramite lo spostamento di file infetti ad opera degli utenti. Worm: non hanno bisogno di infettare altri file per diffondersi perché modificano il sistema operativo della macchina ospite in modo da essere eseguiti automaticamente. Per indurre gli utenti ad eseguirli utilizzano tecniche di ingegneria sociale 22, oppure sfruttano dei difetti (bug) di alcuni software. Il loro scopo è rallentare il sistema con operazioni inutili o dannose. 19 L Intrusion Detection System o IDS è un dispositivo software e hardware utilizzato per identificare accessi non autorizzati ai computer o alle reti locali. 20 Un rootkit è un software creato per avere il controllo completo sul sistema senza bisogno di autorizzazione da parte di utenti o amministratori. 21 Un Host based intrusion detection system (HIDS) è una tipologia di intrusion detection system specializzato nell analisi e nel monitoraggio del computer. Una variante del network intrusion detection system, uno strumento indirizzato verso l analisi del traffico di rete. 22 Nel campo della sicurezza informatica per ingegneria sociale (dall inglese social engineering) si intende lo studio del comportamento individuale di una persona al fine di carpire informazioni.

26 4.1 Stato dell Arte 23 Trojan Horse: oltre ad avere delle funzionalità lecite, utili per indurre l utente ad utilizzarli, contengono istruzioni dannose che vengono eseguite all insaputa dell utilizzatore. Non possiedono funzioni di auto-replicazione, quindi per diffondersi devono essere consapevolmente inviati alla vittima. BackDoor: consentono un accesso non autorizzato al sistema su cui sono in esecuzione. Tipicamente si diffondono in abbinamento ad un trojan o ad un worm, oppure costituiscono una forma di accesso di emergenza ad un sistema, inserita per permettere ad esempio il recupero di una password dimenticata. Spyware: vengono usati per raccogliere informazioni dal sistema su cui sono installati e trasmetterle ad un destinatario interessato. Rootkit: composti da un driver e, a volte, da copie modificate di software normalmente presenti nel sistema non sono dannosi in se ma hanno la funzione di nascondere, sia all utente che a software come gli antivirus, la presenza di particolari file o impostazioni del sistema. Vengono quindi utilizzati per mascherare spyware e trojan. KeyLogger: software in grado di registrare tutto ciò che un utente digita su una tastiera rendendo così possibile il furto di password o di altri dati. In questo studio sono state analizzate le tecniche di azione e di detenzione dei rootkit che, poiché sono necessari a mascherare altre tecniche di attacco, sono considerati come i più pericolosi dell elenco sopra mostrato. I rootkit possono essere divisi in due grandi categorie: livello utente: Lo scopo di questi rootkit è modificare utilità di sistema ( come ps,ls,netstat etc. etc. ) per mascherare intrusioni, processi e connessioni. Questi rootkit sono facilmente individuabili in quanto non modificano il kernel del SO che può facilmente rendersi conto della loro presenza. livello kernel: sono i più difficili da individuare perchè modificano il kernel del SO affinché questo fornisca false informazioni che non rivelino la presenza dello stesso rootkit. Molti degli attuali rootkit adottano una strategia comune per infettare il sistema e nascondersi dai software di controllo. L analisi di tali strategie [18] è il miglior modo per creare degli efficienti sistemi di protezione poiché solo conoscendo nei minimi dettagli le operazioni eseguite durante un attacco possiamo essere sicuri di non poter essere raggirati dal rootkit. 4.1 Stato dell Arte La sicurezza dei Sistemi Operativi è sempre stata una componente chiave nel mondo dell informatica. Quello a cui si è assistito con la nascita della virtualizzazione è stato un processo di raffinamento e miglioramento delle tecniche di difesa dei SO. I due aspetti più importanti introdotti grazie alla virtualizzazione sono stati:

27 244 VIRTUALIZZAZIONE E SICUREZZA (TECNICHE DI ATTACCO E DI DIFESA) L impossibilità da parte della macchina virtuale di accedere alle strutture della macchina fisica ospitante. La possibilità di poter posizionare il sistema di monitoraggio ad un livello inferiore rispetto alla macchina guest. Vengono ora elencati i più famosi sistemi di sicurezza basati sul monitoraggio dei SO su macchine virtuali e non. XenKimono[39]: sistema software in grado di accorgersi di intrusioni al kernel della macchina virtuale. Sviluppato sull hypervisor Xen Virtual Machine, questo è in grado di individuare molte tipologie di kernel rootkit all interno della macchina guest garantendo una minima degradazione delle prestazione di quest ultima. A differenza di altri sistemi, XenKimono è isolato dal kernel sottoposto a monitoraggio cosi chè qualora quest ultimo venisse corrotto il sistema sarebbe ancora in grado di svolgere il suo lavoro correttamente. In oltre XenKimono è molto flessibile e non richiede alcuna modifica al sistema controllato. Xenfit[37]: sistema in grado di controllare in tempo reale l integrità della macchina virtuale e di inviare un allarme di notifica di avvenuto attacco. Questo sistema modifica dinamicamente dall host la memoria della macchina virtuale introducendo codice di controllo dell integrità di quest ultima senza dover installare alcun software o codice kernel all interno del guest stesso. In oltre, grazie alle potenzialità offerte da Xen, sia le politiche di sicurezza che le tecniche di controllo dell integrità sono posizionate all interno di una macchina virtuale sicura rendendo Xenfit inattaccabile. Lares[33]: sistema di monitoraggio per alcuni aspetti molto simile a Xenfit. Anche nell architettura proposta da lares, come quella proposta da Xenfit, il sistema di monitoraggio viene posizionato all interno di una macchina virtuale per poter resistere in modo più efficace agli attacchi. SecVisor[41]: sistema di monitoraggio che assicura, all interno della macchina virtuale, la sola esecuzione di codice-fidato proteggendo quindi il guest da attacchi di tipo code-injection come ad esempio i kernel-rootkit. Caratteristica degna di nota del sistema Secvisor è la capacità di controllare l integrità della macchina virtuale anche laddove un attaccante fosse in grado di prendere possesso di tutto l hardware di questa ad eccezione della cpu e della memoria. Remus[12]: architettura di monitoraggio delle system call necessarie ad una corretta esecuzione del SO. Tale architettura viene inserita all interno di un qualsiasi SO basato sull ambiente Linux filtrando l esecuzione delle system call in modo tale che queste vengano eseguite solamente nel caso in cui il processo chiamante ed il valore passato come parametro corrispondano a delle regole mantenute in un database di controllo degli accessi. Caratteristica fondamentale di questo approccio consiste nel non richiedere alcuna modifica alle strutture dati del kernel. Tutte le modifiche

28 4.2 File Nascosti 25 eseguite al kernel sono trasparenti all applicazione che può continuare ad essere utilizzata all interno del SO senza bisogno di subire alcuna modifica ne tantomeno di essere ricompilata. 4.2 File Nascosti Il comando usato sotto Linux per visualizzare l elenco dei file presenti in una directory è ls. Invocando il comando strace ls possiamo ottenere informazioni sulle operazioni eseguite da ls. Matteo:~# strace ls... getdents64(3, /* 2 entries */, 4096) = Matteo:~# La descrizione che il man 23 fornisce circa questa funzione è la seguente, getdents - get directory entries [4],la cui definizione è: int n_getdents64(unsigned int fd, struct linux_dirent64 *dirp, unsigned int count) Dove fd: è il descrittore del file da cui la funzione andrà a leggere dirp: è la zona di memoria in cui la funzione andrà a scrivere le varie strutture linux dirent64 lette count: è la dimensione della zona di memoria che verrà scritta Una struttura linux dirent64 e l equivalente a 64 bit della struttura dirent, che in parole povere, non e altro che la rappresentazione di un file. struct linux_dirent64 { u64 d_ino; // Inode (per ora non pensateci, ne parleremo in seguito) s64 d_off; // Offset alla prossima entry unsigned short d_reclen; // Lunghezza di questa entry unsigned char d_type; // Tipo dell entry: directory, file normale, socket... char d_name[0]; // Puntatore all inizio del nome } Le operazioni che saranno quindi necessarie per nascondere un determinato file saranno: 1. Redirigere la funzione sys getdents64 2. Chiamare la sys getdents64 originale e passargli come parametri i valori ottenuti tramite la redirezione. 3. Filtrare i risultati e far sparire le informazioni scomode 23 Il man in ambiente Linux è il comando che ci permette di leggere i manuali dei comandi eseguibili.

29 264 VIRTUALIZZAZIONE E SICUREZZA (TECNICHE DI ATTACCO E DI DIFESA) Bisogna a questo punto fare una precisazione, le modifiche verranno effettuate sulla system call invocata dalla funzione getdents, non sulla funzione stessa. La differenza è sostanziale infatti mentre le system call(figura 16) lavorano in kernel space, le funzioni con le quali si è abituati ad operare lavorano in userspace. Ovviamente da kernel space non si può accedere direttamente alla memoria user space, ovvero dove verranno memorizzati i risultati della chiamata alla sys getdents64 originale, e quindi bisogna usare delle funzioni kernel space che permettano di svolgere tali compiti. Figura 16: Normale esecuzione di una system call (getdents) Con la stessa tecnica appena descritta possono essere eseguite svariate operazioni molto gradite ai rootkit come ad esempio: rendere inaccessibile un file nascondere un processo cambiare i privilegi di esecuzione di un processo eseguire delle operazioni privilegiate anche da processi che non potrebbero eseguirle etc. etc. Tutte queste tecniche hanno in comune la redirezione delle system call(figura 17). Proprio per questo motivo, il monitoraggio delle system call è requisito fondamentale per garantire un discreto livello di sicurezza. La debolezza di questa strategia di attacco risiede proprio nella facilità con cui può essere scoperta. È noto che gli indirizzi delle system call si trovano all interno del file System.map[7] generato all avvio del sistema operativo. Basterebbe quindi salvare gli indirizzi delle system call durante una esecuzione sicura del sistema operativo e controllare che tali indirizzi non cambino mai. Il termine esecuzione sicura indica una esecuzione del sistema operativo nella quale si ha la certezza che non vi siano ne rootkit ne altre applicazioni malevole. Questa fase, ovvero quella di salvataggio dei dati che devono essere monitorati, è fondamentale infatti,

30 4.3 Il FileSystem /proc 27 Figura 17: Redirezione della system call getdents l esecuzione di questa in un sistema già compromesso non permetterebbe il rilevamento di minacce all interno del sistema con nessuna delle soluzioni adottate in questo studio. Bisogna quindi a questo punto fare una puntualizzazione. Nello sviluppo di un rootkit c è sempre un tradeoff tra la portabilità e la sua capacità di rendersi invisibile. Infatti, come si è mostrato precedentemente, per ottenere un rootkit con alte capacità di risultare invisibile ai controlli bisogna scendere nei dettagli implementativi delle funzioni del kernel, e più si scende nei dettagli implementativi di tali funzioni più si rischia che il suddetto rootkit risulti eseguibile su un sistema ma non su un altro. 4.3 Il FileSystem /proc Una ulteriore tecnica che permette di ottenere un alto livello di invisibilità pur mantenendo un buon livello di portabilità e quella dell attacco al /proc file system. Il proc file system [29] è un file system virtuale esistente interamente a kernel space che contiene una gerarchia di file speciali che rappresentano lo stato corrente del kernel. Questo consente alle applicazioni e agli utenti di esplorare il sistema attraverso il punto di vista del kernel. All interno della directory /proc si trovano numerose informazioni sull hardware e su qualsiasi processo attualmente in esecuzione. Inoltre alcuni file all interno dell albero della directory /proc possono essere manipolati dagli utenti e dalle applicazioni per comunicare al kernel eventuali modifiche di configurazione. Questo particolare file system viene generato su richiesta (on-demand) ovvero gli elementi costituenti di quest ultimo sono sempre vuoti, vengono riempiti solo nel momento in cui vi si accede. Se quindi fosse possibile modificare il modo in cui questi dati vengono generati (ovvero le funzioni del procfs) si potrebbero ingannare tutti quei software che si basano su di esso senza andare minimamente a modificare la system call table. La struttura di una entry del procfs è la seguente: struct proc_dir_entry { unsigned short low_ino;

31 284 VIRTUALIZZAZIONE E SICUREZZA (TECNICHE DI ATTACCO E DI DIFESA) unsigned short namelen; const char *name; mode_t mode; nlink_t nlink; uid_t uid; gid_t gid; unsigned long size; struct inode_operations *proc_iops; struct file_operations *proc_fops; get_info_t *get_info; struct module *owner; struct proc_dir_entry *next, *parent, *subdir; void *data; read_proc_t *read_proc; write_proc_t *write_proc; atomic_t count; int deleted; kdev_t rdev; }; Di tutti questi elementi costituenti, i due più importanti sono next e subdir. Il puntatore next serve per accedere agli elementi di una lista i cui nodi rappresentano gli altri file del procfs presenti nella directory corrente. Attraverso il puntatore subdir è invece possibile entrare all interno delle sottocartelle. È quindi possibile scorrere tutto il procfs partendo dalla sua radice e navigando la sua struttura mediante i puntatori next e subdir. Quando viene richiesta la lettura di un file all interno del file system procfs, il kernel esegue le seguenti operazioni: rileva il tentativo di lettura del file attiva la funzione che genera il contenuto del file Queste operazioni vengono effettuate ogni volta che si richiede l interazione con un file presente in /proc, di conseguenza agli occhi di un utente o di un software l impressione è quella che il file sia sempre stato li. Le funzioni relative alla lettura/scrittura del procfs si trovano all interno della struttura proc dir entry corrispondente, quindi quello di cui si ha bisogno per la creazione di un rootkit è: Individuare il campo per il quale si vogliono modificare le funzioni di interazione Sostituire la funzione che viene chiamata a seconda del tipo di interazione con il file (read, get info, etc...) Il controllo che tutela da un attacco di questo tipo è anche questa volta basato sull utilizzo del file System.map. Eseguendo una piccola scansione del suddetto file si nota infatti che in esso si trovano gli indirizzi delle funzioni usate dal kernel per l interazione con il procfs. Basta quindi salvare gli indirizzi di tali funzioni durante una esecuzione sicura del sistema operativo e controllare che questi ultimi non cambino mai durante tutto il ciclo di vita del sistema operativo.

32 4.4 Processi Nascosti Processi Nascosti Linux memorizza i processi in una lista a doppia percorrenza di strutture task struct(figura 18). Questa lista viene navigata tramite due variabili puntatore: next struct e prev struct(figura Figura 18: Struttura di una generica task struct 19) che corrispondono al puntatore al processo seguente ed al processo precedente nella lista. Figura 19: Navigazione tra le task struct Il comando per visualizzare l elenco dei processi sotto Linux è ps, quindi per vedere quali sono le funzioni di sistema chiamate all esecuzione del comando ps basta eseguire il comando:

33 304 VIRTUALIZZAZIONE E SICUREZZA (TECNICHE DI ATTACCO E DI DIFESA) Matteo:~#strace ps open("/proc", 0_RDONLY 0_NONBLOCK 0_LARGEFILE 0_DIRECTORY ) = 5... getdents64(5, /* 36 entries */, 1024) = Matteo:~# Come si vede dal codice sopra riportato, durante l esecuzione del comando ps viene aperta la directory /proc e viene letto il suo contenuto. Successivamente le informazioni vengono raffinate ed infine stampate sullo schermo. Nella directory /proc ci sono altre directory dal nome composto da numeri ed all interno di queste ci sono le informazioni sui processi. Il nome numerico delle directory presenti in /proc corrisponde al pid 24 del processo e le informazioni contenute all interno della rispettiva directory si riferiscono proprio a quest ultimo. Per cercare all interno di /proc la directory corrispondente ad un certo processo basterà quindi cercare il pid del processo partendo da 1 fino ad un massimo consentito di PID MAX 25. Quello che accade durante l esecuzione del comando ps è la lettura da proc dei processi esistenti, la raccolta delle informazioni necessarie ed infine la stampa a video di quest ultime. Ancora una volta quindi l attacco si basa sulla modifica delle system call e di conseguenza una buona tecnica di difesa consiste nel monitoraggio di queste. 4.5 Moduli Nascosti Tutti i moduli del kernel agganciati in testa ad una lista rappresentata dalla struttura module list. Le operazioni da portare a compimento sono quindi le seguenti: scorrere la lista fino a trovare il modulo che si desidera nascondere replicare in parte il funzionamento della sys delete module in modo tale da non liberare la memoria occupata dal modulo In questo modo le zone di memoria in cui si trova il modulo non verranno eliminate e questo permetterà al modulo di continuare indisturbato la sua esecuzione, dal lato opposto, tutte le informazioni riguardanti il modulo verranno cancellate e questo farà in modo che agli occhi del SO il modulo risulterà completamente cancellato. 24 Il pid di un processo è l identificativo del processo ovvero è un numero intero non negativo assegnato automaticamente che identifica in maniera univoca un processo all interno del sistema e rimane costante per tutta la durata del processo 25 PID MAX è una variabile di sistema che esprime il numero massimo di processi attivi che ci possono essere nel sistema

34 4.6 Redirezione di Funzioni di Sistema Redirezione di Funzioni di Sistema Fin qui si è mostrato come nascondere file e processi ma non si sono ancora analizzate le metodologie che permettono di nascondere il cuore dell attacco, ovvero il modulo del kernel che deve essere caricato nel sistema per far si che l attacco abbia inizio. In questo paragrafo verrà analizzata la tecnica con la quale è possibile nascondere gli effetti dell attacco al SO. Tutte le tecniche usate sino a questo momento fanno uso di una strategia comune, la modifica dei puntatori presenti nella system call table con dei puntatori che fanno riferimento a delle funzioni malevole. Dato però che la system call table è un luogo estremamente controllato vi è un alta probabilità che l attacco venga smascherato in poco tempo e quindi bisogna lavorare ad un livello più basso per rendere questo più efficiente e difficile da individuare. Il controllo effettuato sul System.map assicura che la system call eseguita sia quella originale ma non ci fornisce alcuna informazione riguardo a cosa viene effettivamente eseguito da questa. Di conseguenza un attacco che vada a modificare il codice interno ad una system call avrebbe la stessa efficacia degli attacchi visti precedentemente ma avrebbe anche la caratteristica di nascondersi meglio all interno del sistema risultando quindi più difficile da trovare. Per modificare l interno di una system call(figura 20) non bisogna necessariamente riscriverla tutta, basta solo fare in modo che le prime istruzioni eseguite da questa siano dei riferimenti alla funzione di attacco. La modifica viene eseguita tramite istruzioni in assembler e consiste nell inserimento di un jump 26 all inizio della system call originale. Il jump in questione non è altro che l invocazione della system call malevola. La dinamica di esecuzione sarà quindi la seguente: il jump nella system call originale chiama la system call maligna una volta all interno della system call maligna bisogna ripristinare il codice originale all interno della system call originale ed eseguirla in modo da ottenere l output si cui lavorare una volta ottenuto il risultato dalla system call originale, filtrare le informazioni ottenute mostrando solo quelle che servono allo scopo del rootkit ripristinare il codice malevolo all interno della system call originale in modo tale che alla prossima esecuzione venga eseguito di nuovo lo stesso procedimento Se ad esempio la funzione originale fosse: int originale(void){ printf("inizio funzione originale"); printf("fine funzione originale"); exit(0); } 26 Condizione di salto incondizionato effettua un salto all interno del codice del software senza condizioni

35 324 VIRTUALIZZAZIONE E SICUREZZA (TECNICHE DI ATTACCO E DI DIFESA) Figura 20: Inserimento di codice malevolo all interno di una system call E la funzione di attacco fosse: int attacco(void){ printf("funzione di attacco"); exit(0); } Basterebbe trasformare la funzione originale in una funzione di questo tipo: int originale(void){ attacco();... exit(0); } In questo modo non si avrebbero nemmeno problemi legati alla dimensione del codice presente nella funzione di attacco ma si dovrebbero risolvere i seguenti punti: Conoscere l indirizzo della funzione da modificare. Trovare un sistema per inserire il codice maligno. Per entrambi questi due punti possono essere adottate diverse tecniche più o meno valide ma l analisi di queste non fa parte del presente studio. Quello che è importante sottolineare invece è che con qeusta tipologia di attacco l indirizzo della system call presente in memoria nella system call table sarà lo stesso presente nel System.map e quindi con un controllo effettuato solo sugli indirizzi il rootkit continuerebbe ad agire indisturbato. Ciò che è necessario per proteggersi da attacchi di questo tipo è controllare l integrità dell intero codice, o parte di esso, di cui è composta ciascuna system call che si ritiene fondamentale per la corretta esecuzione del SO. Nei precedenti paragrafi sono state analizzate due metodologie molto comuni nei malware, la prima è quella della sostituzione dell indirizzo di una system call con quello di un altra funzione e la seconda è quella dell inserimento di codice malevolo all interno della system call stessa. Lo stesso tipo di approccio, ovvero la sostituzione di parti di codice del SO con parti di codice scritte da un attaccante, viene usato da altre tecniche di attacco ottenendone gli stessi identici risultati.

36 4.6 Redirezione di Funzioni di Sistema 33 Le system call presenti in un SO sono in totale 256 (queste sono quelle di base a cui si possono aggiungerne altre pur sempre rispettando un numero massimo, diverso da sistema a sistema, oltre il quale non si può andare). I 256 indirizzi che specificano la posizione in memoria delle rispettive system call sono salvati all interno di una struttura chiamata system call table e l indirizzo della system call table viene salvato a sua volta in una struttura chiamata Interrupt Descriptor Table (IDT) (figura 21). Figura 21: Interrupt Descritor Table (IDT) Durante l invocazione di una system call i passi che vengono eseguiti dal SO sono: Viene lanciata una interruzione software Il SO legge nel registro IDTR (Interrupt Descriptor Table Register) l indirizzo al quale si trova la IDT (Interrupt Descriptor Table) Considerando la IDT come una matrice, il SO legge la riga corrispondente alla interruzione generata. In tale riga è presente l indirizzo di memoria nel quale risiede l indirizzo della system call table. Considerando anche la system call table come una matrice, ciascuna riga contiene l indirizzo di memoria nel quale risiede l indirizzo della funzione di gestione della system call corrispondente. Quindi una volta giunti fino alla system call table, il SO legge l indirizzo della funzione che si occupa della gestione della specifica system call richiesta dall utente Il controllo viene quindi passato alla funzione di gestione, di cui sopra, che si occupa di eseguire il codice costituente della system call. Si è appena visto come le strutture coinvolte nell esecuzione di una system call sono molteplici e ciascuna di esse può essere soggetta ad un attacco.

37 344 VIRTUALIZZAZIONE E SICUREZZA (TECNICHE DI ATTACCO E DI DIFESA) Uno di questi è quello della clonazione della system call table(figura 22). In tale strategia viene creata una struttura quasi identica alla system call table, gli unici elementi differenti sono gli indirizzi delle system call che si desidera modificare. L indirizzo di tale system call table clonata viene quindi inserito nell IDT al posto dell indirizzo originale e la system call originale non viene minimamente alterata. In questo modo, durante l esecu- Figura 22: Clonazione della system call table zione di una system call, la system call table che verrà usata dal SO sarà quella clonata ed eventuali controlli dell integrità della system call table originale non si accorgeranno di nulla. Ovviamente anche questo attacco può essere facilmente intercettato eseguendo un monitoraggio della struttura IDT. Per poter sfuggire al controllo sulla IDT è necessario quindi eseguire l attacco a delle strutture del kernel ad un livello più basso, ovvero bisogna sostituire la IDT(figura 23) allo stesso modo con cui è stata sostituita la system call table, ovvero clonandola e modificando le informazioni di cui si ha bisogno. A tal fine bisogna modificare l indirizzo della IDT originale con quello della IDT clonata e ciò è possibile andando a cambiare il valore presente nel registro IDTR. In questo modo, verrano lasciate inalterate le strutture IDT e system call table originali e di conseguenza un controllo dell integrità di queste ultime non si accorgerebbe di un attacco di questo tipo. Anche stavoltà però basta controllare che il valore presente nel registro IDTR sia quello desiderato per poter sfuggire a questo tipo di attacco. Con l analisi di tutte queste metodologie di attacco si è voluto mostrare come gran parte dei malware sia composta da redirezioni o da sostituzioni di strutture del kernel e come tali attacchi siano facilmente individuabili attraverso un continuo monitoraggio delle strutture interessate.

38 4.7 /dev/mem /dev/mem Figura 23: Clonazione della Interrupt Descriptor Table Tutte le tecniche viste sin qui fanno uso di una importante caratteristica del SO Linux ovvero gli LKM 27 [24]. Grazie a questa caratteristica è possibile inserire dei moduli mentre il sistema è in esecuzione. Per eseguire un attacco basta quindi inserire il suo codice di esecuzione in un modulo e inserire tale modulo all interno del kernel. Dato l elevato numero di rootkit facenti uso di questa tecnica si è deciso di inserire una opzione di configurazione nel kernel di Linux mediante la quale è possibile disabilitare gli LKM. Questo ha ovviamente portato allo studio di nuove tecniche di attacco al kernel Linux,tra le quali la più nota si basa sull inserimento di codice malevolo all interno del kernel mediante il file /dev/mem. Tale tecnica è un perfezionamento di un altra tecnica scoperta in precedenza che usava la stessa metodologia ma si basava sul file /dev/kmem [14]. Il file /dev/mem altro non è che il file all interno del quale troviamo la mappatura di tutta la memoria fisica. Spostarsi all interno di tale file di un offset X equivale a leggere dalla memoria quello che si trova all indirizzo X partendo dall inizio della memoria stessa. Poiché il kernel usa degli indirizzi di tipo logico mentre invece all interno del file /dev/mem si lavora con indirizzi fisici si deve necessariamente applicare una traduzione da indirizzi logici a fisici. Per effettuare tale traduzione è possibile utilizzare la struttura GDT 28. Questa non è altro che una tabella contenente le informazioni relative alla mappatura di tutte le aree della memoria. Una volta tradotti gli indirizzi è possibile leggere e/o scrivere all interno del file /dev/mem come se lo si stesse facendo direttamente in memoria. Ovviamente, poiché modificare il codice di un kernel in esecuzione senza creare instabilità nel sistema è una impresa molto difficile, per poter aggiungere del codice malevolo all interno di quest ultimo bisogna usare delle tecniche particolari per le quali si consiglia per esempio la lettura di [27]. 27 Loadable Kernel Module 28 Global Descriptor Table

39 364 VIRTUALIZZAZIONE E SICUREZZA (TECNICHE DI ATTACCO E DI DIFESA) La tecnica del /dev/mem ha mostrato come sia possibile aggirare il livello di sicurezza fornito dal kernel mediante la disabilitazione degli LKM ma ha anche evidenziato come, qualsiasi sia la tecnica di modifica della memoria del kernel, tutti gli attacchi, per poter raggiungere il loro scopo hanno bisogno di modificare strutture del kernel o aree di memoria che devono essere quindi costantemente monitorate.

40 37 5 Il Progetto KVMLSP 5.1 Architettura KVM Linux Security Project(figura 24) è un sistema di monitoraggio della integrità del sistema operativo guest. Il controllo viene dislocato in un livello inferiore rispetto al sistema in analisi per il quale la presenza del sistema di controllo è trasparente. KVMLSP si compone di un insieme di funzioni user space inserite all interno di un thread che viene creato da una funzione di kvm delegata alla gestione delle richieste delle macchine virtuali. Le funzioni di cui è composto KVMLSP inizialmente eseguono il salvataggio dei checksum delle strutture dati del kernel guest delle quali si deve controllare l integrità. Successivamente, controllano periodicamente la memoria del guest assicurandosi che i checksum delle strutture dati sopra citate siano rimasti gli stessi calcolati durante la prima esecuzione. Host Qemu-kvm Guest kvm_main_loop: -Controlla che la ram sia stata inizializzata correttamente dal guest. thread_create(thread_sum_loop) qemu_monitor_sum_loop Funzione di monitoraggio Memoria Memoria kernel space Struttura 1 Struttura 2 Struttura n Il Sistema Operativo guest non è stato modificato. La sua esecuzione avviene come se si trovasse su una macchina fisica. Figura 24: Architettura di KVMLSP

41 38 5 IL PROGETTO KVMLSP 5.2 Requisiti KVMLPS è il prototipo di un sistema di sicurezza sviluppato sulla base di Qemu-Kvm 29 [5] allo scopo di garantire la sicurezza delle macchine guest pur rispettando i seguenti requisiti: Trasparenza Prestazioni Portabilità Inoltre durante il suo sviluppo si è cercato il più possibile di prendere come esempio i Reference Monitor e di rispettare le proprietà di questi ultimi quali: Non Aggirabilità (Non Bypassable) Valutabilità (Evaluate Able) Continuità di Esecuzione (Always Invoked) Non Manomissibilità (Tamper-Proof) Trasparenza Con il termine trasparenza si vuole indicare l impossibilità da parte del guest, e quindi da parte di un possibile attaccante, di rendersi conto che nel SO è attivo un sistema di verifica dell integrità del guest stesso. Questo aspetto è molto importante perché, nel caso in cui un attaccante fosse in grado di accorgersi della presenza di un controllo di sicurezza allora tale attaccante potrebbe essere in grado di risalire ai meccanismi di controllo e di conseguenza potrebbe anche essere in grado di sviluppare delle tecniche per ingannarli. Il progetto KVMLSP è riuscito a raggiungere un alto livello di trasparenza grazie al fatto di aver implementato l intero processo di monitoraggio nella parte host di kvm senza modificare la parte guest. La particolarità di questo studio risiede proprio nella sua elevata trasparenza. Molti studi [32][43][38] precedentemente effettuati su questo argomento mostrano soluzioni nelle quali è stato necessario modificare anche il SO guest per poter effettuare su di esso un controllo dell integrità. Purtroppo però le modifiche al guest hanno alcuni svantaggi non indifferenti. Il primo tra questi in ordine d importanza è sicuramente quello legato alla sicurezza. Un attaccante potrebbe tranquillamente accorgersi di tali modifiche al kernel guest e adottare delle contromisure per controllare a suo piacimento sia il SO che il software di controllo stesso. Supponiamo per esempio che il software di sicurezza installato sul guest segnali all host quando il primo richieda l uso di una particolare sytem call, l attaccante potrebbe tranquillamente disabilitare tale controllo, invocare la system call e riabilitarlo. In questo modo dall host non ci si accorgerebbe mai dell attacco avvenuto. 29 Progetto che unisce qemu e kvm in unico software.

42 5.2 Requisiti 39 In generale quindi si deve spostare il controllo di un livello più in basso rispetto al soggetto che deve essere controllato.nei sistemi operativi ad esempio tutti i controlli sono situati a livello kernel che corrisponde al livello più basso presente in un SO. Nel caso di KVMLSP il controllo viene posizionato ad un livello ancora più basso del kernel del guest e questo ci permette di poter controllare tutta la macchina guest con la certezza che il suddetto controllo non possa essere evitato. Prestazioni Questo aspetto ha due risvolti. Il primo, più semplice ed immediato, è legato al desiderio di voler effettuare dei controlli di sicurezza della macchina guest che non vadano ad incidere pesantemente sulle prestazioni di quest ultimo. Il secondo aspetto è fortemente legato alla trasparenza, infatti un degrado delle prestazioni è il primo segnale di allarme che nel SO c è qualche altro software in esecuzione oltre a quelli conosciuti e questo può servire di aiuto ad un attaccante che cerchi di capire se il SO sul quale sta lavorando è sottoposto o meno a dei controlli. Il problema delle prestazioni è stato un problema presente in tutto il processo di sviluppo di KVMLSP. Questo perché la sicurezza e le prestazioni sono solitamente proprietà inversamente proporzionali, senza nessun controllo di sicurezza le prestazioni sono quelle originali fornite da kvm mentre se si volesse avere un altissimo livello di sicurezza bisognerebbe controllare molto frequentemente tutte le strutture del kernel ritenute sensibili e questo comporterebbe un elevato consumo di risorse con conseguente degrado delle prestazioni. Portabilità Come verrà analizzato in seguito in maniera più approfondita,kvmlsp si basa su una routine di controllo di alcune strutture del kernel importanti per una corretta esecuzione del SO guest. Poiché tali strutture riguardano il guest si ha bisogno di sapere in quale punto della memoria esse si trovino. Per far ciò all inizio era stata adottata una tecnica diretta ma poco portabile che consisteva nell uso del software crash per tradurre gli indirizzi virtuali in indirizzi fisici. L uso di crash comportava di dover avviare il SO guest in uno stato sicuro 30 e salvare tutti gli indirizzi fisici delle strutture del kernel delle quali si voleva controllare l integrità. Una volta salvati tali indirizzi si doveva inserirli all interno del codice sorgente di cui era composto il software di controllo e successivamente si poteva avviare di nuovo la macchina guest che questa volta sarebbe stata controllata correttamente. Ovviamente tale soluzione non era portabile, primo perché era necessario avviare il guest in una prima esecuzione sicura per raccogliere tutti i dati e secondo perché si dovevano avere le giuste competenze sia per eseguire il comando crash e sia per inserire i dati raccolti all interno del codice sorgente di kvm. Per ovviare a questo problema si è quindi deciso successivamente di usare una funzione presente nel monitor 31 di Qemu-Kvm. Tale funzione è la memsave ed è addetta a leggere una porzione di memoria del guest partendo da un indirizzo virtuale di memoria e continuando a leggere per una certa dimensione data. Usando questa funzione è stato 30 Ovvero in uno stato in cui si aveva la certezza assoluta dell integrità del sistema stesso 31 Il monitor di qemu è un software che rende possibili numero operazioni eseguibili sulla macchina guest

43 40 5 IL PROGETTO KVMLSP quindi possibile usare gli indirizzi virtuali al posto di quelli fisici che ha portato a notevoli vantaggi dal punto di vista della portabilità. Infatti non e più stato necessario dover usare crash sul guest ma, molto più semplicemente è bastato salvare il file System.map relativo al kernel della macchina guest e portare tale file nella macchina host. All interno di questo file sono presenti tutti gli indirizzi degli oggetti del kernel ed è quindi possibile prendere le informazioni necessarie alla corretta esecuzione del software di controllo direttamente da li. Non Aggirabilità La certezza che il controllo di sicurezza non sia evitabile in alcun modo deriva dall architettura di kvm e quindi dall architettura del controllo stesso. Tutto il codice sorgente della routine di controllo di cui è composto il progetto KVMLSP è situato all interno della macchina host, di conseguenza, per come è struttura la virtualizzazione con supporto hardware un ipotetico attaccante presente nel guest non solo non è in grado di vedere quale tipo di controllo venga effettuato dall host ma non può nemmeno rendersi conto se tale controllo è presente o meno. Nessuna tecnica di raggiro può quindi essere applicata a tale situazione. Valutabilità La routine di controllo eseguita sulla macchina guest è composta da una semplice analisi delle aree di memoria di cui si vuole controllare lo stato nel tempo. Tale controllo viene fatto eseguendo un checksum 32 delle suddette aree di memoria nel tempo e verificando se tale checksum subisca o meno delle modifiche. Il codice sorgente è composto da un numero di righe di codice dell ordine delle centinaia ed è pertanto facilmente analizzabile. Continuità di Esecuzione Tale caratteristica (detta anche in inglese always invoked ) viene garantita dall esecuzione di kvm. Come ampiamente spiegato nel prossimo capitolo, l invocazione della routine di controllo è stata inserita all interno di un ciclo di esecuzione che corrisponde al cuore di tutto kvm. Tale ciclo viene ripetuto costantemente e periodicamente (ad intervalli molto piccoli) per controllare se ci siano delle operazioni pendenti che devono essere eseguite sul guest e quindi l interruzione della sua esecuzione corrisponde all interruzione dell esecuzione della macchina guest. Di conseguenza l esecuzione della macchina virtuale ci garantisce che anche la routine creata per questo progetto venga sempre eseguita. Non Manomissibilità Anche questa proprietà, come la Non Aggirabilità, viene garantita dall architettura di kvm. Il codice di cui è composto KVMLSP si trova all interno della macchina host che non è raggiungibile, in nessun modo, dalle macchine virtuali. Quindi la modifica, da parte di un attaccante presente nella VM, del codice sorgente di cui è composta la routine di controllo è praticamente impossibile. 32 inserire spiegazione checksum

44 5.3 Implementazione Implementazione Qemu-Kvm è suddiviso in due parti, una in kernel space e l altra in user space. I moduli di kvm che fanno parte del lato kernel space vengono caricati dinamicamente all interno del kernel su cui si sta eseguendo e servono a fornire il supporto hardware alla virtualizzazione. Il codice sorgente di cui è composto KVMLSP è stato posizionato all interno del codice sorgente di kvm che risiede in user space. Questo implica l aver potuto usare tutti i benefici dello user space, ovvero tutte le librerie e funzioni di sistema, cosa difficile nel kernel space. Prima di analizzare in dettaglio il funzionamento di KVMLSP bisogna analizzare in che modo questo si lega a kvm e in che modo viene eseguito. All interno di kvm le macchine virtuali vengono gestite come dei thread. All avvio di kvm vengono creati quattro thread 33, uno di questi quattro ovvero quello dedicato alla macchina virtuale, viene eseguito, messo in pausa o fermato sotto il completo controllo di kvm. Dopo aver creato il thread associato alla VM, il software controlla se il supporto a kvm è stato attivato, se cosi fosse viene invocata una funzione chiamata kvm main loop (figura 25). Come si può intuire dal nome, questa funzione esegue ciclicamente dei controlli ad intervalli regolari ripetuti all infinito (ovvero fino a quando kvm non viene terminato) ed è proprio in questa funzione che è stata inserita l invocazione alla funzione principale del progetto KVMLSP. I controlli eseguiti in kvm main loop sono: qemu shutdown requested: richiesto lo shutdown da parte della VM qemu powerdown requested: richiesto il powerdown da parte della VM qemu reset requested: richiesto un reset da parte della VM kvm debug cpu requested: richiesto il debug 34 della cpu Oltre a quelli sopra citati sono stati aggiunti i seguenti controlli: count==0: viene controllato che siano passati un certo numero di cicli di kvm main loop prima di rieseguire la routine di controllo di KVMLSP ram inizializzata: viene controllato che la memoria sia stata correttamente inizializzata dal SO della VM Il principio fondamentale su cui si basa KVMLSP è quello di controllare che determinate aree della memoria associata alla macchina virtuale non mutino nel tempo o almeno non 33 Un thread è contenuto all interno di un processo, diversi thread contenuti nello stesso processo condividono essenzialmente la sezione di codice, la sezione di dati e le risorse del SO. Gli elementi che invece sono differenti tra tutti i thread di uno stesso processo sono principalmente tre: program counter, valori nei registri e stack. 34 Il debugging (o semplicemente debug) è un attività che consiste nella individuazione della porzione di software affetta da errore (bug) rilevati nei software a seguito dell utilizzo del software stesso.

45 42 5 IL PROGETTO KVMLSP QEMU-KVM.C (KVM Thread) VL.C Figura 25: Schema di avvio di KVM

46 5.3 Implementazione 43 mutino in maniera non desiderata. Di conseguenza lo strumento migliore sia in termini di efficacia che di efficienza è il checksum 35. L uso di questo strumento comporta sia dei vantaggi che degli svantaggi. Vantaggi: molto veloce risparmio di spazio (qualsiasi sia la dimensione della memoria analizzata, la dimensione del checksum è sempre la stessa) Svantaggi: il checksum consente di individuare se i dati contenuti nella memoria vengono alterati. Purtroppo però non è di per se in grado di dire quale dato sia stato alterato ne tanto meno dire in che modo. Nell implementazione di KVMLSP è stato usato il ben conosciuto algoritmo di checksum MD5[6]. Inizializzazione KVMLSP non viene eseguito immediatamente all avvio di kvm nonostante la sua invocazione compaia tra i primi comandi presenti in kvm main loop. La motivazione è semplice, all avvio della VM come all avvio di una qualsiasi macchina fisica, tutte le strutture dati e di controllo del kernel sono ancora vuote. Tali strutture vengono riempite da specifiche funzioni del kernel durante l avvio del SO(ad esempio nella figura 26 viene mostrato come la IDT venga inizializzata prima dal bios e poi dal kernel) e poiché la prima operazione eseguita da KVMLSP consiste nel creare il checksum delle strutture di cui si vuole eseguire il monitoraggio, se tale checksum venisse calcolato subito dopo l avvio della VM, quello che verrebbe trovato nella memoria sarebbero tutti 0. In questo modo Figura 26: Inizializzazione strutture kernel verrebbe creato un checksum errato in grado di falsare tutto il sistema di monitoraggio. È per questo che in KVMLSP si ha bisogno di una prima fase detta di inizializzazione. Tale 35 Il checksum è una sequenza di bit che viene utilizzata per verificare l integrità di un dato o di un messaggio che potrebbe subire alterazioni.

47 44 5 IL PROGETTO KVMLSP fase può essere sviluppata secondo due modalità, ed anche questa volta si dovrà scegliere tra portabilità e sicurezza. La tecnica che garantisce un elevato livello di sicurezza a discapito della portabilità (KVMLSP ha adottato questa tecnica) consiste nell avviare la VM una prima volta in quella che viene chiamata esecuzione di setup. In tal esecuzione si deve prendere nota dei primi X valori (con X a scelta) della zona di memoria della quale si vuole tenere sotto controllo l integrità, per poterli poi inserire all interno del codice sorgente di cui è composto KVMLSP. Nelle successive esecuzioni della VM, KVMLSP controllerà i valori trovati nella suddetta zona di memoria, se in tale zona saranno presenti dei valori uguali a quelli precedentemente raccolti allora fase di inizializzazione sarà considerata completa e quindi si potrà procedere al monitoraggio, altrimenti tale controllo verrà rieseguito fino al soddisfacimento della condizione di cui sopra. La seconda tecnica consiste nel calcolare un intervallo di tempo 36 nel quale il SO riesce a concludere le fasi di inizializzazione e successivamente inserire tale intervallo all interno di KVM in modo tale che il controllo inizi ad eseguire solo dopo che questo sia trascorso. In questo modo si elimina la fase iniziale in cui bisogna avviare la VM per raccogliere i dati però ci si espone ad un rischio. Supponendo ad esempio che l intervallo sopra citato corrisponda a 60 secondi, se un attaccante riuscisse ad inserire un malware all interno del sistema nei primi 60 secondi di attività del SO, passati tali 60 secondi KVMLSP andrebbe a considerare i dati inseriti dall attaccante come dati fidati quando invece questi sono tutto l opposto. Riconoscimento della Fase di Ripristino KVMLSP dispone di una ulteriore capacità che aumenta il livello di sicurezza da esso fornito. Poiché questo progetto si occupa del rilevamento degli attacchi effettuati ad una macchina virtuale e non delle politiche di intervento qualora questi venissero individuati, potrebbe verificarsi il seguente scenario: un attaccante potrebbe inserire del codice malevolo all interno della VM e successivamente reinserire i dati originali all interno della memoria. A seguito del reinserimento, agli occhi di KVM, la situazione, tornata alla normalità, non desterebbe alcun sospetto. Se cosi fosse, un amministratore di sistema non sarebbe in grado di distinguere quali siano state le operazioni eseguite dalla VM durante l attacco e quali no e quindi quali sarebbero le operazioni da annullare e quali da considerare validi. Proprio per evitare questo, KVMLSP è in grado di riconoscere e segnalare il momento in cui le aree di memoria delle quali deve essere controllata l integrità vengono ripristinate ai valori di partenza. Queste informazioni quindi, supportate da un timestamp 37 permettono all amministratore di sistema di poter risalire all orario dell attacco ed anche alla durata di questo. 36 questo intervallo può essere relativo ad un particolare SO o può essere relativo a più SO anche diversi tra loro. 37 Il timestamp è una sequenza di caratteri che rappresentano una data e/o un orario per accertare l effettivo avvenimento di un certo evento.

48 5.3 Implementazione 45 Esecuzione KVMLSP è un applicazione non bloccante(figura 27), ovvero la normale esecuzione di kvm non deve attendere il completamento delle operazioni eseguite da KVMLSP per continuare il suo flusso di esecuzione. Per far ciò, KVMLSP è stato creato all interno di Figura 27: Struttura di esecuzione di KVMLSP un thread separato in modo tale che l ordine di avanzamento di quest ultimo e di kvm fosse deciso dallo scheduling della cpu come per tutti gli altri processi presenti nella macchina host. Il meccanismo usato per avviare il controllo di KVMLSP è stato quello dei semafori. I thread di KVMLSP e KVM usano un semaforo chiamato condition to start per sincronizzarsi e poiché il thread che comanda tra i due è quello di KVM allora inizialmente il semaforo è bloccato ed è compito di KVM sbloccarlo per lasciar eseguire KVMLSP con un certo intervallo. Tale intervallo di esecuzione viene scelto nel seguente modo: si sceglie un valore X, tale valore corrisponde al numero di cicli di kvm main loop che si desidera vengano eseguiti prima dell esecuzione di KVMLSP. Durante ciascun ciclo di kvm main loop, il valore di X viene incrementato di uno, e solo quando questo valore raggiunge un multiplo dell X di partenza allora il semaforo viene sbloccato ed il controllo di sicurezza eseguito. Le funzioni principali di cui è composto il codice sorgente di KVMLSP sono: do first checksum: esegue la creazione del checksum la prima volta che questa viene invocata e salva tale checksum in una struttura do checksum: esegue la creazione del checksum tutte le volte successive

49 46 5 IL PROGETTO KVMLSP digest compare: effettua la comparazione tra l ultimo checksum calcolato ed il checksum creato alla prima esecuzione ram check: controlla che nella memoria ci siano i valori raccolti precedentemente durante l esecuzione della VM in uno stato sicuro do md5: esegue il checksum di una data area di memoria Seguono ora le descrizioni dettagliate dell implementazione di ogni singola funzione qui sopra citata. do first checksum Questa funzione prende come parametri in input i seguenti valori: start size checksum value Il valore start rappresenta l indirizzo di partenza a partire dal quale bisogna leggere in memoria per creare il checksum. Il valore size corrisponde invece alla dimensione della zona di memoria di cui bisogna fare il checksum, ed il terzo ed ultimo valore, checksum value, è un vettore 38 nel quale verrà salvato il checksum creato. Questa funzione viene invocata solo una volta non appena il SO guest abbia terminato la fase di inizializzazione della memoria del guest. do checksum Questa funzione prende come parametri in input i seguenti valori: start size correct digest kern obj I valori start e size hanno lo stesso significato della precedente funzione. Il valore correct digest rappresenta il checksum calcolato dalla funzione do first checksum mentre il valore kern obj rappresenta il nome della struttura del kernel della quale si sta monitorando l integrità (ad esempio system call table ). All interno di questa funzione viene calcolato il checksum della memoria a partire dall indirizzo start per una lunghezza uguale a size e lo si confronta con il checksum memorizzato in correct digest. Se i valori sono uguali allora la struttura kern obj non 38 Un vettore è una struttura dati complessa usata in molti linguaggi di programmazione e chiaramente ispirata alla nozione matematica di vettore. È in genere classificato come un costruttore di tipo: in altre parole, esso consente di definire nuovi tipi di dati a partire da tipi preesistenti.

50 5.3 Implementazione 47 è stata alterata, altrimenti viene stampato a video un messaggio di allerta. È inoltre presente un altro valore importante chiamato warning check il quale serve ad evitare che il log 39 della macchina host sia pieno di messaggi. Se non ci fosse tale variabile ed il controllo di sicurezza fosse eseguito ogni 2 secondi, in seguito ad un attacco avvenuto nella macchina guest, la macchina host verrebbe notificata ogni 2 secondi il che sarebbe inutile e confusionario. Laddove KVMLSP si accorgesse che la situazione è tornata alla normalità in seguito ad un attacco, la variabile suddetta sarebbe ripristinata ad un valore uguale a 0 per permettere che i futuri attacchi possano essere di nuovo notificati alla macchina host. Se invece il valore della suddetta variabile fosse uguale a 1 significherebbe che la macchina host è già stata notificata dell avvenuto attacco e non necessita di ulteriori avvisi. digest compare Questa funzione prende in input due vettori corrispondenti a due checksum. Uno è quello originale calcolato alla prima esecuzione, il secondo è quello calcolato ultimamente per verificare il contenuto della memoria. La funzione torna un valore uguale a 1 se i due checksum sono uguali altrimenti torna un valore uguale a 0. ram check Questa funzione non ha nessun parametro in input. Il suo compito è quello di controllare se nella memoria ci sono i valori che sono stati raccolti durante una esecuzione sicura della VM. All interno di questa funzione vanno messi i controlli di tutte le strutture delle quali si intende tenere sotto controllo l integrità. Le strutture del kernel, durante la fase di caricamento del SO vengono inizializzate una alla volta e quindi è possibile che durante una esecuzione di questa funzione alcune strutture siano correttamente inizializzate mentre altre no. È quindi importante sottolineare che il valore di ritorno di questa funzione deve essere uguale a 1 solo e soltanto quando tutte le aree di memoria delle quali deve essere controllata l integrità sono state correttamente inizializzate(figura 28). do md5 Questa funzione prende come valori di input un buffer, una dimensione ed un vettore di destinazione. Nel buffer ci sono i valori che sono stati letti dalla memoria e di cui si vuole calcolare il checksum. La dimensione deve corrispondere alla dimensione del buffer. In fine il vettore di destinazione è il vettore dove viene messo il checksum calcolato. 39 Il log è un file sequenziale sempre aperto in scrittura, che viene chiuso e conservato a cadenze regolari e reso disponibile per l analisi delle operazioni che vengono eseguite in un SO

51 48 5 IL PROGETTO KVMLSP Figura 28: Inizializzazione memoria in KVMLSP

52 49 6 Analisi delle prestazioni Le prestazioni di un software sono un aspetto molto importante di questo tanto quanto la sua efficienza e sicurezza. Come anche precedentemente accennato, ottenere delle buone prestazioni è importante nello sviluppo di applicativi di sicurezza per due motivi: Usabilità: usare un software con buone prestazioni aumenta la produttività di esso stesso Sicurezza: nei casi in cui si deve rimanere trasparenti verso l attaccante, cercare di mantenere delle prestazioni il più simili possibile a quelle originali aiuta a mascherare la presenza del software agli occhi dell attaccante. In altri studi condotti sulla sicurezza delle VM come [35] si vede come spesso la sicurezza incida sulle prestazioni in modo negativo. Nello sviluppo di KVMLSP si è invece cercato di mantenere delle prestazioni il più possibile vicine a quelle ottenute con KVM originale pur garantendo un buon livello di sicurezza. Per misurare le prestazioni sono stati usati due diversi approcci. Da una parte sono stati eseguiti dei test a basso livello mediante l utilizzo di comandi forniti dal SO quali make, untar e lame. Tramite l utilizzo del comando time 40 abbinato ai comandi precedentemente introdotti si è risaliti ai tempi necessari per: Make: compilare un software partendo dai sorgenti di quest ultimo. (Il software usato per la compilazione è stato la versione 88 di KVM) Lame: eseguire la conversione di un file audio dal formato wav al formato mp3. (È stato usato un file delle dimensioni di 60 megabyte per la conversione) Untar: eseguire l estrazione di un archivio. (Anche qui l archivio usato per i test è stato quello della versione 88 di KVM) Oltre ai comandi precedentemente illustrati, per una ulteriore analisi delle prestazioni è stato usato un ben noto software di test denominato UnixBench [3]. Tale software è composto da una grande varietà di test di diverse tipologie che vengono invocati alla sua esecuzione. Per questo studio sono stati eseguiti i seguenti test: Execl: Questo test(figura 32) misura il numero di chiamate della funzione execl che possono essere eseguite in un secondo. Execl fa parte della famiglia di funzioni exec che rimpiazza l immagine del processo corrente con quella di uno nuovo. File Copy: Questo test(figura 33) misura il tasso con il quale i dati possono essere trasferiti da un file ad un altro. Più precisamente conta il numero di caratteri che possono essere scritti in un file in 10 secondi. 40 Il comando time restituisce in output il tempo trascorso per il completamento del comando che viene specificato all avvio nella seguente forma time nome comando

53 50 6 ANALISI DELLE PRESTAZIONI Pipe: La pipe è la più semplice forma di comunicazione tra processi. Questo test(figura 34) conta il numero di volte al secondo che un processo riesce a scrivere e successivamente a leggere 512 bytes all interno di una pipe. Creazione Processi: Questo test(figura 35) misura il numero di volte che un processo riesce ad eseguire una fork 41 in un certo intervallo di tempo. Con il termine creazione di un processo si fa riferimento alla creazione del process control block 42 di un processo e dell allocazione di memoria associata a quest ultimo. Di conseguenza questo test è rivolto all analisi delle prestazioni della memoria della macchina. Shell Script: Questo test(figura 36) misura il numero di volte per minuto che un processo riesce ad eseguire simultaneamente 8 script della shell. I test sono stati eseguiti su una macchina virtuale su cui è stato installato il SO Linux Fedora Core 11 a 32 bit. Dapprima sono state monitorate le prestazioni ottenute eseguendo una versione originale di Qemu-Kvm laddove con originale si intende senza il supporto di KVMLSP. Successivamente a questa fase, i test sono stati effettuati sullo stesso SO e su macchine virtuali con le stesse identiche risorse hardware ma con intervalli di esecuzione di KVMLSP diversi. Come precedentemente spiegato nei precedenti capitoli, l esecuzione del controllo di sicurezza di cui è composto KVMLSP viene controllata all interno di un ciclo di kvm denominato kvm main loop. Di conseguenza l unico fattore che è stato possibile modificare per ottenere delle configurazioni di esecuzione diverse della macchina virtuale è stato quello del numero di cicli di kvm main loop che devono essere attesi prima di ciascuna esecuzione di KVMLSP. Per poter associare ai cicli di kvm main loop che devono essere attesi dei corrispettivi valori in secondi è stato necessario calcolare l orario in cui viene avviato kvm, l orario in cui viene terminata l esecuzione di kvm ed in fine il numero totale di cicli kvm main loop eseguiti da kvm. Il numero di cicli è stato ricavato da un contatore incrementato ad ogni esecuzione di kvm main loop, mentre l orario di avvio e di terminazione di kvm è stato calcolato mediante la funzione gettimeofday della libreria time.h. In questo modo è stato possibile calcolare il tempo media di esecuzione di un singolo ciclo di kvm main loop che è risultato essere pari a 0,006 secondi. Grazie a questo risultato è stato possibile scegliere i seguenti intervalli di esecuzione con i quali sono stati eseguiti i test di prestazioni: 100 cicli 0 5 secondi 166 cicli 1 secondi 41 Una fork in programmazione è la modalità attraverso cui un processo crea in memoria una copia di sé stesso: la copia prenderà il nome di processo figlio, mentre il processo originale verrà chiamato processo padre. 42 Il Process Control Block o PCB di un processo è una struttura dati del nucleo del sistema operativo che contiene le informazioni essenziali per la gestione del processo.

54 cicli 2 secondi 666 cicli 4 secondi 1333 cicli 8 secondi 2666 cicli 16 secondi 5333 cicli 32 secondi Make Secondi Non 100 cicli 166 cicli 333 cicli 666 cicli Protetto (0.5 sec) (1 sec) (2 sec) (4 sec) 1333 cicli (8 sec) Intervallo tra le esecuzioni di controlli asincroni 2666 cicli5333 cicli (16 sec) (32 sec) Figura 29: Test Make

55 52 6 ANALISI DELLE PRESTAZIONI 60 Lame Secondi Non 100 cicli 166 cicli 333 cicli 666 cicli Protetto (0.5 sec) (1 sec) (2 sec) (4 sec) 1333 cicli (8 sec) Intervallo tra le esecuzioni di controlli asincroni 2666 cicli5333 cicli (16 sec) (32 sec) Figura 30: Test Lame Untar Secondi Non 100 cicli 166 cicli 333 cicli 666 cicli Protetto (0.5 sec) (1 sec) (2 sec) (4 sec) 1333 cicli (8 sec) Intervallo tra le esecuzioni di controlli asincroni 2666 cicli5333 cicli (16 sec) (32 sec) Figura 31: Test Untar

56 53 Execl 380 Numero di execl() eseguite in un secondo Non 100 cicli 166 cicli 333 cicli 666 cicli Protetto (0.5 sec) (1 sec) (2 sec) (4 sec) 1333 cicli (8 sec) Intervallo tra le esecuzioni di controlli asincroni 2666 cicli5333 cicli (16 sec) (32 sec) Figura 32: Test Execl File Copy 80,000 79,000 78,000 77,802 Caratteri 77,000 76,000 75,000 Non 100 cicli Protetto (0.5 sec) 166 cicli 333 cicli (1 sec) (2 sec) 666 cicli (4 sec) 1333 cicli2666 cicli 5333 cicli (8 sec) (16 sec) (32 sec) Intervallo tra le esecuzioni di controlli asincroni Figura 33: Test FileCopy

57 54 6 ANALISI DELLE PRESTAZIONI 56,000 Pipe-Based Context Switching 54,800 Esecuzioni 53,600 52,400 53,059 51,200 50,000 Non 100 cicli Protetto (0.5 sec) 166 cicli 333 cicli (1 sec) (2 sec) 666 cicli (4 sec) 1333 cicli2666 cicli 5333 cicli (8 sec) (16 sec) (32 sec) Intervallo tra le esecuzioni di controlli asincroni Figura 34: Test Pipe Process Creation Processi Non 100 cicli 166 cicli 333 cicli 666 cicli Protetto (0.5 sec) (1 sec) (2 sec) (4 sec) 1333 cicli (8 sec) Intervallo tra le esecuzioni di controlli asincroni 2666 cicli5333 cicli (16 sec) (32 sec) Figura 35: Test Process