Come evitare problemi simili a Heartbleed in futuro?

1

I ha fatto una domanda su StackOverflow , ma suppongo che questo sito sia più adatto per questo.

L'idea è di prevenire i problemi quando viene fuori il prossimo bug di overflow del buffer.

Nella mia comprensione il problema con Heartbleed era l'accesso alla memoria di richieste precedenti? Non è possibile cancellare la memoria dopo averla usata? Per utilizzare diversi spazi di memoria per ogni richiesta, che non sono accessibili da quello successivo? Se il server web (ad es. Apache o nginx) viene avviato con più processi, condivide ancora la memoria contenente le informazioni dell'utente?

In breve, la mia domanda: è possibile configurare Apache / Nginx / Linux / altri per utilizzare un modello di accesso alla memoria più sicuro?

La riduzione delle prestazioni non avrebbe importanza dal momento che alla fine verrà Heartbleed 2.0 e poi avrai solo una risata veloce invece di molto lavoro.

    
posta Ikarus 03.05.2014 - 22:01
fonte

1 risposta

5

(Gran parte di questo si basa sulla mia risposta qui )

Esistono tecniche, come le pagine di protezione della memoria e la cancellazione della memoria deallocata, che avrebbe dovuto arrestare Heartbleed o un attacco simile in futuro. OpenBSD, ad esempio, li usa per impostazione predefinita. Heartbleed è stato reso peggiore perché utilizza il proprio allocatore di memoria che funziona attivamente per annullare la protezione della memoria .

C'è un limite alla quantità di protezione che un sistema operativo può fornire contro la programmazione incompetente. Heartbleed ha superato tale limite.

    
risposta data 03.05.2014 - 23:03
fonte

Leggi altre domande sui tag