Considerazioni sulla sicurezza nelle applicazioni concorrenti

Quando si verifica un deadlock, l'elaborazione si interrompe. Questo è un denial-of-service, che, come qualsiasi altro DoS , può servire come passo intermedio per un attacco più grande. Ad esempio, se un Sistema di rilevamento delle intrusioni smette di funzionare (ad esempio entra in una situazione di stallo), allora le intrusioni saranno in grado di procedere inosservati . Hollywood, nella sua infinita saggezza, ha elaborato esposizioni molto grafiche di tali scenari ( quello è un classico).

Deadlock sono un problema classico nella programmazione concorrente. Sono così classici che alcuni sistemi includono meccanismi di "resurrezione" che cercano di rianimare un processo dopo un deadlock. Ad esempio, quando un thread tenta di acquisire un blocco che chiude il cerchio del deadlock, il sistema di blocco potrebbe rilevarlo e non acquisire il blocco, riportando invece un errore. Se il chiamante non controlla correttamente la condizione di errore, può procedere senza il blocco, modificando i dati senza la sincronizzazione con altri chiamanti. La corruzione dei dati e altre conseguenze indesiderate potrebbero quindi verificarsi.

Evitare i deadlock è una questione di correttezza : un deadlock si verifica a causa di un difetto nella progettazione complessiva dell'applicazione (i deadlock sono considerati un tipo di errore "difficile" perché non possono essere individuati in un una singola posizione in cui un programmatore ha dimenticato di mettere un test o calculato una costante, i bug deadlock appaiono a livello di architettura). La relazione con la sicurezza è generica: non è sufficiente per garantire che i bug non vengano attivati in condizioni normali, poiché gli aggressori possono spesso imporre condizioni anormali. Ad esempio, anche se il nome di un utente normale si adatta a meno di 100 caratteri, dovresti comunque controllare che il nome inserito dall'utente non sia troppo grande prima di provare a copiarlo in un 100- buffer di caratteri. Allo stesso modo, anche se un deadlock non può verificarsi in una data applicazione quando si verificano eventi esterni a un "ritmo normale", un utente malintenzionato può attivare intervalli insoliti, ad es. avvio di 15 operazioni di "modifica della password" simultaneamente sullo stesso account.

Un deadlock, di per sé, non consente generalmente a un utente malintenzionato di influenzare il flusso del programma. Per definizione, in una situazione di stallo, il programma smette di progredire, quindi a quel punto non sta accadendo nulla: desiderabile o indesiderabile.

Ci sono molti altri problemi di sicurezza nelle applicazioni multithread:

• Assicurarsi che i thread stiano solo leggendo / scrivendo memoria destinata a loro. (Questo è molto ampio, ovviamente, ma dipende molto dalla tua applicazione.)
• Se dipendi da dati casuali (come per le chiavi crittografiche) assicurati che gli RNG per i tuoi thread non siano nello stesso punto. L'utilizzo degli stessi RNG per più thread può causare punti deboli crittografici.
• È più probabile che le condizioni di gara si verifichino nei programmi multi-thread. Queste condizioni di gara possono comportare varie vulnerabilità, come problemi di TOCTOU (time-of-check-in-time-to-use) o altri tipi di vulnerabilità della sicurezza.

C'è molto che può andare storto, e i problemi specifici che devi cercare dipendono strongmente dal tipo di applicazione che stai creando.

No, non è possibile sfruttare i deadlock direttamente per scopi dannosi. Tuttavia, se una procedura di sicurezza importante è in qualche modo forzata in un punto morto, allora può portare a una possibilità di un attacco più grande. Un deadlock è definito come una condizione che un programma non sta facendo più progressi, sia perché il programma è in attesa di una risorsa non disponibile o motivi simili. Devi capire che i deadlock sono solitamente causati da 2 (o più) azioni / processi concorrenti ed è una condizione possibile nella maggior parte dei sistemi operativi e quindi devono essere gestiti in modo appropriato. L'immagine sotto è un semplice esempio di ciò che accade in un deadlock:

• Il processo 1 richiede una risorsa 1 che appartiene al processo 2
• Il processo 2 richiede la risorsa 2, che è di proprietà del processo 1

(entrambi i processi stanno aspettando la risorsa desiderata in cosa è chiamata "ciclo di attesa circolare infinito")

Perquantoriguardaithreadsimultaneinell'applicazione:

Sesiutilizzapiùhardwareperl'elaborazionesimultanea,quindi inalcunicasidevigestiremanualmente"l'esclusione reciproca"  altrimenti il verificarsi della razza è altamente probabile. Comunque su un singolo  piattaforma, l'esclusione reciproca è solitamente fornita dal sistema operativo e dalla gara    le condizioni non si verificano.