PROGRAM SECURITY Seminario di Sicurezza e Privacy A.A. 2007-2008 A cura di Nicolucci Luca.

Presentazione sul tema: "PROGRAM SECURITY Seminario di Sicurezza e Privacy A.A. 2007-2008 A cura di Nicolucci Luca."— Transcript della presentazione:

1 PROGRAM SECURITY Seminario di Sicurezza e Privacy A.A. 2007-2008 A cura di Nicolucci Luca

2 CAMBIAMENTI IMPROPRI Si occupa di dati e istruzioni che cambiano nel tempo Il pericolo è che i valori cambiati possono essere incongruenti con quelli precedenti I valori precedenti dettano il flusso di controllo del processo I valori modificati portano il programma ad effettuare azioni non corrette o non sicure sul percorso di controllo I dati e le istruzioni possono risiedere nella memoria condivisa nella memoria non condivisa sul disco Program Security 2/29

3 Memoria Ogni processo che può accedere alla memoria condivisa ne può manipolare i dati Ogni processo che vi accede può implementare un protocollo concomitante che gestisce i cambiamenti un processo può cambiare i dati ai quali un secondo processo si riferisce il secondo processo viola la politica di sicurezza Il primo processo legge il risultato prima che il secondo processo abbia completato la computazione per il dato corrente Un processo potrebbe consentire laccesso quando laltro lavrebbe negato o viceversa Program Security 3/29

4 Memoria Implementation Rule 29.5.5 Interazione tra processi sincronizzata In particolare tutte le possibili sequenze dovrebbero essere conosciute e per ogni interazione il processo dovrebbe assicurare la politica di sicurezza richiesta Program Security 4/29

5 Asynchronous Exception Handler Variante al problema dei processi concomitanti Se lhandler altera le variabili e poi ritorna al precedente punto del programma, i cambiamenti nelle variabili possono causare problemi simili al processo concomitante Per questo motivo se l exception handler altera ogni variabile sulle quali dipendono anche altre porzioni di codice, il programmatore deve capire i possibili effetti di questi cambiamenti Implementation Rule 29.5.6 AEH potrebbe non alterare nessuna variabile tranne quelle che sono allocate nellEXCEPTION HANDLING MODULE Un EH può bloccare tutte le altre applicazioni quando iniziano, e potrebbe non rilasciarle finché l handler non completi lesecuzione Program Security 5/29

6 Quando un utente immette false informazioni al programma e il programma le accetta, queste provocano un overflow del suo buffer, cambiando i suoi dati o inserendo istruzioni che possono essere eseguite dopo Loutput può essere costituito da un dato falso Questo abbassa la sua fedeltà rispetto all input Implementation Rule 29.5.7 Quando è possibile, i dati che il processo certifica e quelli che riceve da fonti non certificate possono essere messi in aree separate della memoria. Se il dato proveniente da una fonte certa è sovrascritto da dati di fonte non certa, si verifica un errore di memoria. Program Security 6/29

7 Applicazioni Queste regole possono essere applicate al nostro programma in varie maniere 1. Interazione con altri programmi Il programma non interagisce con altri programmi tranne che con lException Handler - esclude la IR 29.5.5 - 2. Illecita alterazione dei dati Se i dati di un utente sono letti nella memoria che li sovrappone a dati di altri programmi, li cancella o li modifica L IR 29.5.7 assicura che ogni accesso al buffer non si sovrapponga con altri buffer Program Security 7/29

8 Cambiamenti nei contenuti dei file Il contenuto dei file può cambiare in modo improprio Questo significa in molti casi che i permessi dei file sono settati incorrettamente o che molti processi stanno accedendo al file, come nel caso di processi concomitanti. Questi casi sono risolti abilmente dall IR 29.5.5 Implementation Rule 29.5.8 Non usare componenti che possono cambiare tra il tempo in cui il programma è cambiato e il tempo in cui il programma corre. Program Security 8/29

9 NOMI IMPROPRI Si riferisce allambiguità di identificare un oggetto Il programmatore riferisce il nome ad un oggetto e un assalitore ne manipola lo svolgimento e il processo deviandolo su un altro oggetto Per eliminare questo problema bisogna dare ad ogni oggetto un nome univoco e non ambiguo Management Rule 29.5.5 Unico oggetto necessita di un unico nome Oggetti intercambiabili possono condividere i nomi Program Security 9/29

10 NOMI IMPROPRI Un nome è interpretato senza un contesto A livello dellimplementazione il processo deve forzare il suo stesso contesto nell interpretazione, per essere sicuro che loggetto si riferisce alloggetto interessato Il contesto include informazioni sul tipo di carattere, sul percorso di ricerca, sulle variabili accessibili… Implementation Rule 29.5.9 Il processo deve assicurarsi che il contesto di un oggetto si riferisce alloggetto corrente Program Security 10/29

11 NOMI IMPROPRI Questo programma utilizza 4 nomi: 1.il nome del file di controllo dell accesso 2. i nomi degli utenti e ruoli 3. i nomi degli host 4. il nome dello shell interprete 2 vantaggi 1. il programma può analizzare lo sviluppo nel dettaglio 2. permette al sistema di evolvere senza compromettere la sicurezza del programma I nomi degli host rappresentano il nome finale Possono essere specificati dal nome o dall indirizzo IP Se la rete locale è malgestita o compromessa il nome di un host potrebbe riferirsi ad un altro piuttosto che a quello dovuto. Program Security 11/29

12 CANCELLAZIONE IMPROPRIA Non potendo cancellare informazioni sensibili si crea la possibilità che altri processi possano accedere a questi dati in un secondo momento In particolare per parole chiave crittografate, password e tutte quelle informazioni che dovrebbero essere scartate una volta usate La stessa cosa vale per i processi. Una volta finito con una risorsa questa risorsa dovrebbe essere deallocata Implementation Rule 29.5.10 quando il processo finisce di usare oggetti sensibili, questi ultimi dovrebbero essere annullati, poi deallocati o cancellati. Il nostro programma usa 3 tipi di informazioni sensibili CLEARTEXT PSWACCESS CONTROL INFORMATION LOG FILE Program Security 12/29

13 CONVALIDA IMPROPRIA - Confini Questo problema si verifica quando i dati non sono verificati per consistenza e correttezza un processo può controllare la correttezza solo guardando gli errori di codice oppure guardando semplicemente valori incorretti Spesso errori di convalida si presentano quando i dati sono fuori dai confini stabiliti Es: un buffer contiene numeri da 0 a 99. Se un indice prende un valore più grande di 99 o più piccolo di 0, si genera un errore Implementation Rule 29.5.11 Assicurarsi che tutti i riferimenti degli accessi dellarray siano elementi esistenti dellarray Non usare una funzione se non può assicurare che i riferimenti siano tutti esistenti nellarray Program Security 13/29

14 CONVALIDA IMPROPRIA - Confini I programmatori usano una sola funzione che controlla la lunghezza degli array 1. per leggere gli input 2. consente ai programmatori di specificare qual è la lunghezza massima di un array che deve essere letta FGETS è usata : Implementation Rule 29.5.12 Controllare il tipo di funzioni e parametri Un buon compilatore ed un codice ben scritto eviterà questo problema Tutte le funzioni devono essere dichiarate prima di essere usate Program Security 14/29 Management Rule 29.5.6 Quando compili un programma assicurati che il compilatore non riporti inconsistenza nei tipi

15 CONVALIDA IMPROPRIA 3 - Errori Un problema comune riguarda il fallimento del controllo dei valori di ritorno di una funzione Implementation Rule 29.5.13 Controllare tutte le funzioni e le esecuzione di procedure per errori Ogni funzione ritorna un valore il valore è controllato da eventuali errori prima che venga usato Program Security 15/29

16 CONVALIDA IMPROPRIA – Dati validi e non La convalida dovrebbe applicare un principio di sicurezza intrinseca Questo principio richiede che i valori validi siano conosciuti e accettati e che tutti gli altri valori siano respinti Sfortunatamente i programmatori spesso controllano i dati invalidi e presumono che tutti gli altri siano validi Implementation Rule 29.5.14 Controllare che tutti i valori delle variabili siano validi Questo programma controlla che il comando che deve essere eseguito si confronti con uno autorizzato Per ogni utente con un ruolo preciso e in un dato momento il programma troverà il comando invalido controllando nella lista di quelli autorizzati Program Security 16/29

17 CONVALIDA IMPROPRIA – Dati validi e non Management Rule 29.5.7 Se risulta una indecisione tra la sicurezza e altri fattori in un meccanismo o una procedura che può minacciare la sicurezza, si documenterà la ragione della decisione, il possibile effetto e le situazioni nelle quali è usato il metodo di compromesso. Questo informa altri della indecisione e dei rischi attesi Program Security 17/29

18 CONVALIDA IMPROPRIA - Input Tutti i dati provenienti da fonti non sicure devono essere controllati Gli utenti sono fonti non sicure!!!! Implementation Rule 29.5.15 Controllare tutti gli input degli utenti sia per la forma che per il contenuto In particolare controllare gli interi per valori che sono troppo grandi o troppo piccoli e controllare i caratteri dei dati per lunghezza e validità Il programma determina cosa fare sulla base di due dati che lutente fornisce : 1.Il ruolo 2.Il comando (se omesso significa che laccesso non è ristretto) Program Security 18/29

19 CONVALIDA IMPROPRIA - Input Gli utenti devono autenticarsi correttamente Il programma deve prima accertare che la password inserita sia corretta Dopo controlla le informazioni di accesso per determinare se allutente è consentito laccesso con quel ruolo, in quel momento e da quel luogo La lunghezza della password non deve essere più lunga del buffer nel quale è inserita Program Security 19/29

20 PROGETTARE LA CONVALIDA La sintassi deve essere bene definita e il modulo di controllo degli accessi nel programma controlla eventuali errori di sintassi Il modulo controlla anche username non validi nel campo user e richiede che tutti i percorsi nomi del comando siano specificati In caso di errore di qualsiasi tipo, il processo registra lerrore, se possibile, e termina role name users comma-separated list of users location comma-separated list of location time comma-separated list of times command command and arguments … command command and arguments endrole Qualche volta i dati possono non essere convalidati completamente Implementation Rule 29.5.16 Creare strutture dati e funzioni in maniera che possano essere convalidati Program Security 20/29

21 INDIVISIBILITA IMPROPRIA Si verifica quando un operazione è considerata come un unità (indivisibile) in astratto, ma è implementata come due unità (divisibile) Per Es il controllo dell access control file e la sua esecuzione dovrebbero essere eseguiti come un unica operazione Invece un attentatore può agire subito dopo la prima operazione e subito prima della seconda ed ottenere un accesso illecito Implementation Rule 29.5.17 Se due operazioni devono essere effettuate in sequenza usare un meccanismo che assicura che non possano essere divise Program Security 21/29

22 SEQUENZIALITA IMPROPRIA Significa che le operazioni sono svolte in un ordine non corretto Es. Un processo può creare un lock file e poi scrivere il log file. Un secondo processo potrebbe prima scrivere il log file e poi vedere se esiste il lock file Il primo processo usa la corretta sequenza di chiamate, il secondo no Implementation Rule 29.5.18 Descrivere la sequenza lecita di operazioni su una risorsa o oggetto. Controllare che tutte le possibili sequenze dei programmi coinvolgessero una o più sequenze lecite Program Security 22/29

23 SCELTA IMPROPRIA DI OPERAZIONI Prevenire errori di scelta di operazioni sbagliate richiede che lalgoritmo deve essere pensato attentamente, per assicurarsi che sono quelle appropriate A livello di implementazione questo implica che gli operandi debbano essere di tipo e valore appropriato le operazioni devono essere scelte per svolgere le funzioni desiderate La differenza rispetto alla CONVALIDA IMPROPRIA risiede nel programma Limplementazione impropria si riferisce ad un fallimento di convalida Gli operandi devono essere appropriati ma non viene svolto nessun controllo Management Rule 29.5.8 Usare ingegneri del software e affidarsi a tecniche che assicurano che le operazioni e gli operandi siano appropriati Program Security 23/29

24 TESTING, MANUTENZIONE E OPERAZIONI La fase di testing fornisce un convalida informale del progetto e dellimplementazione del programma Lobiettivo del testing è di mostrare che il programma incontri i bisogni dichiarati Se un il progetto e limplementazione sono guidati dai bisogni, il testing si occuperà solo di trovare problemi minori Solo un programma che è stato scritto e testato può essere installato La procedura di installazione deve assicurare che quando un utente lancia il processo, lambiente nel quale il processo è creato corrisponda al presupposto rappresentato nel progetto Linstallatore infine deve abilitare un utente certificato per modificare e aggiornare il programma Program Security 24/29

25 TESTING Il risultato di un test è più utile se effettuato nellambiente in cui il programma sarà usato Il primo passo nel testare un programma è quello di costruire un ambiente che corrisponda allambiente di produzione il tester dovrà testare il programma su tutti gli ambienti in cui dovrà funzionare Il processo di testing inizia con i bisogni e i requisiti. Sono appropriati? Risolvono il problema? La filosofia del testing è quella di eseguire tutti i possibili percorsi di controllo e controllare i risultati con quelli aspettati Il tester non deve testare solo i percorsi usati più comunemente, ma anche e soprattutto quelli usati meno comunemente Program Security 25/29

26 TESTARE IL MODULO Il modulo può invocare una o più funzioni Le funzioni fanno tornare risultati alla chiamata direttamente ( attraverso una lista di valori e parametri) indirettamente (attraverso la manipolazione dellambiente) 4 tipi di test Normal Data Test Fornisce dati ordinari Boundery Data Test Fornisce dati che testano ogni limite di interfaccia Es. numero di caratteri… Exception Test Determinano come il programma gestisce i trabocchetti e le interruzioni Random Data Test Fornisce input generati casualmente e osserva come reagisce il modulo Non compromette il modulo, se fallisce riprende il sistema da uno stato sicuro salvato Program Security 26/29

27 TESTARE MODULI COMPOSTI Consideriamo un modulo che chiama altri moduli Ognuno di essi ha una descrizione specifica delle sue azioni E necessario un altro tipo di test Error Handling Test Questo test presume che i moduli chiamati violino le loro specifiche in qualche maniera Lobiettivo di questo test è di verificare quanto robuste sono le chiamate Se fallisce facilmente, e ripristina il sistema ad uno stato salvato e sicuro, il modulo passa il test, altrimenti deve essere riscritto Program Security 27/29

28 TESTARE IL PROGRAMMA la fase finale del test inizia una volta che i tester hanno assemblato il programma e la sua documentazione I tester seguono qualcuno nell installazione e configurazione del programma Vedere se le istruzioni di configurazione e di installazione sono corrette e facili I tester devono valutare la semplicità e la chiarezza del programma e della documentazione poiché non tutti gli utenti hanno esperienza con i programmi Program Security 28/29

29 DISTRIBUZIONE Program Security 29/29 Una volta che il programma è stato completato, deve essere distribuito Viene messo in un deposito dove nessuno non autorizzato può modificarlo Nella politica di distribuzione devono essere considerati 3 fattori Chi può usare il programma? Organizzazioni, privato License key Come conservare lintegrità del master? Se un attentatore modifica il master, può compromettere lutilizzo del programma Come assicurare la reperibilità? Precauzioni di venditori on line CdRom….