PROGRAM SECURITY

Seminario di Sicurezza e Privacy

A.A. 2007-2008A cura di

Nicolucci Luca

CAMBIAMENTI IMPROPRISi 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

MemoriaOgni 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.6AEH 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 falsoQuesto abbassa la sua fedeltà rispetto all’ input

Implementation Rule 29.5.7Quando è 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

ApplicazioniQueste 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.8Non 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 IMPROPRISi 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.5Unico 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.9Il processo deve assicurarsi che il contesto di un oggetto si riferisce

all’oggetto corrente

Program Security 10/29

NOMI IMPROPRIQuesto programma utilizza 4 nomi:

1. il nome del file di controllo dell’ accesso2. i nomi degli utenti e ruoli3. i nomi degli host4. 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 IMPROPRIANon 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.10quando 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 - ConfiniQuesto 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.11Assicurarsi 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 - ConfiniI programmatori usano una sola funzione che controlla la lunghezza degli array

1. per leggere gli input2. consente ai programmatori di specificare qual è la lunghezza massima

di un array che deve essere letta

FGETS è usata :

Implementation Rule 29.5.12Controllare 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.6Quando 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.13Controllare 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.14Controllare 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.7Se 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 - InputTutti i dati provenienti da fonti non sicure devono essere controllati

Gli utenti sono fonti non sicure!!!!

Implementation Rule 29.5.15Controllare 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

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

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.17Se 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.18Descrivere 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 OPERAZIONIPrevenire 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.8Usare 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

TESTINGIl 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 MODULOIl 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

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

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 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….