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
Program Security 2/29
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
Program Security 3/29
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
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
Program Security 5/29
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.
Program Security 6/29
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
Program Security 7/29
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
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
Program Security 9/29
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
Program Security 10/29
NOMI IMPROPRI
Questo programma utilizza 4 nomi:
1.
2.
3.
4.
il nome del file di controllo dell’ accesso
i nomi degli utenti e ruoli
i nomi degli host
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
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
Program Security 12/29
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
Program Security 13/29
CONVALIDA IMPROPRIA - Confini
I programmatori usano una sola funzione che controlla la lunghezza degli array
FGETS è usata :
1. per leggere gli input
2. consente ai programmatori di specificare qual è la lunghezza massima
di un array che deve essere letta
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
Program Security 14/29
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
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
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
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)
Program Security 18/29
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
Program Security 19/29
PROGETTARE LA CONVALIDA
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
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
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
Program Security 20/29
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
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
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
Program Security 23/29
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
Program Security 24/29
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
Program Security 25/29
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
Exception Test
Fornisce dati che testano
ogni limite di interfaccia
Determinano come il
programma gestisce i
trabocchetti e le
interruzioni
Es. numero di caratteri…
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
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
Program Security 27/29
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
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?
Come conservare l’integrità del master?
Come assicurare la reperibilità?
Organizzazioni, privato
Se un attentatore modifica il master, può
compromettere l’utilizzo del programma
Precauzioni di venditori on line
License key
CdRom….
Program Security 29/29