PROGRAM SECURITY
Seminario di Sicurezza e Privacy
A.A. 2007-2008 A cura di
Nicolucci Luca
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
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 l’accesso quando l’altro l’avrebbe negato o viceversa
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
Asynchronous Exception Handler
Variante al problema dei processi concomitanti
Se l’handler 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 nell’EXCEPTION HANDLING MODULE
Un EH può bloccare tutte le altre applicazioni quando iniziano, e potrebbe non rilasciarle finché l’ handler non completi l’esecuzione
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 L’output 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.
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 l’Exception 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
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.
NOMI IMPROPRI
Si riferisce all’ambiguità 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
NOMI IMPROPRI
Un nome è interpretato senza un contesto
A livello dell’implementazione il processo deve forzare il suo stesso contesto nell’ interpretazione, per essere sicuro che l’oggetto si riferisce
all’oggetto 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 all’oggetto corrente
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.
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 PSW ACCESS CONTROL
INFORMATION
LOG FILE
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 dell’array siano elementi esistenti dell’array
Non usare una funzione se non può assicurare che i riferimenti siano tutti esistenti nell’array
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
Management Rule 29.5.6
Quando compili un programma assicurati che il compilatore non riporti inconsistenza nei tipi
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
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
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
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 l’utente fornisce : 1. Il ruolo
2. Il comando (se omesso significa che l’accesso non è ristretto)
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 all’utente è consentito l’accesso con quel ruolo, in quel momento e da quel luogo
• La lunghezza della password non deve essere più lunga del buffer nel quale è inserita
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 l’errore, 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
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
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
SCELTA IMPROPRIA DI OPERAZIONI
Prevenire errori di scelta di operazioni sbagliate richiede che l’algoritmo 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
L’implementazione 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
TESTING, MANUTENZIONE E OPERAZIONI
La fase di testing fornisce un convalida informale del progetto e dell’implementazione del programma
L’obiettivo del testing è di mostrare che il programma incontri i bisogni dichiarati Se un il progetto e l’implementazione 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, l’ambiente nel quale il processo è creato corrisponda al presupposto
rappresentato nel progetto
L’installatore infine deve abilitare un utente certificato per modificare e aggiornare il programma
TESTING
Il risultato di un test è più utile se effettuato nell’ambiente in cui il programma sarà usato
Il primo passo nel testare un programma è quello di costruire un ambiente che corrisponda all’ambiente 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
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 dell’ambiente)
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
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
L’obiettivo 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
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
DISTRIBUZIONE
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 l’integrità del master?
Se un attentatore modifica il master, può compromettere l’utilizzo del programma
Come assicurare la reperibilità?
Precauzioni di venditori on line CdRom….
