Come fare in modo che le ottimizzazioni del compilatore non introducano un rischio per la sicurezza?

Question

Devo scrivere un servizio Windows che gestisca ad un certo punto dati riservati (come codici PIN, password e così via). Queste informazioni sono necessarie per un periodo di tempo molto breve: in genere vengono inviate quasi immediatamente a un lettore di smart card.

Consente di considerare questo pezzo di codice:

{ 
    std::string password = getPassword(); // Get the password from the user 

    writePasswordToSmartCard(password); 

    // Okay, here we don't need password anymore. 
    // We set it all to '\0' so it doesn't stay in memory. 
    std::fill(password.begin(), password.end(), '\0'); 
} 

Ora la mia preoccupazione è di circa ottimizzazioni del compilatore. Qui il compilatore potrebbe rilevare che la password sta per essere eliminata e che la modifica del suo valore a questo punto è inutile e basta rimuovere la chiamata.

Non mi aspetto che il mio compilatore si preoccupi del valore della memoria futura senza riferimento.

Le mie preoccupazioni sono legittime? Come posso essere sicuro che una tale parte di codice non verrà ottimizzata?

Answer 1

Sì, le tue preoccupazioni sono legittime. È necessario utilizzare funzioni appositamente progettate come SecureZeroMemory() per impedire alle ottimizzazioni di modificare il comportamento del codice.

Non dimenticare che la classe stringa deve essere stata progettata specificamente per la gestione delle password. Ad esempio, se la classe rialloca il buffer per contenere una stringa più lunga, deve cancellare il buffer prima di riconnetterlo all'allocatore di memoria. Non sono sicuro, ma è probabile che lo std::string non lo faccia (almeno per impostazione predefinita). L'utilizzo di una classe di gestione delle stringhe inadeguata rende tutte le tue preoccupazioni prive di valore: avrai la password copiata su tutta la memoria del programma, fino a quando non lo saprai.

Answer 2

È problematico, ma per un altro motivo. Chi ha detto che std::string password = getPassword(); non lascia ancora un'altra copia in memoria? (Probabilmente hai bisogno di scrivere una classe di allocatori "sicura" per questa memoria di zeri su "destruct" o "deallocate")

Nella tua tranquillità di codice puoi evitare l'ottimizzazione ottenendo un puntatore volatile ai dati di stringa (I non so se puoi farlo in modo standard) e quindi azzerare i dati.

Answer 3

Dichiarare la password volatile per impedire al compilatore di formulare ipotesi sulla rimozione di letture o scritture esplicite.

volatile std::string password = getPassword(); // Get the password from the user 

Answer 4

Perché non disattivare l'ottimizzazione per il codice in questione?

#pragma optimize("", off) 

// Code, not to optimize goes here 

#pragma optimize("", on) 

Questo campione di #pragma optimize è specifico per MSVC, ma altri compilatori supportano pure.

Answer 5

In questo caso specifico, sarei davvero sorpreso se il compilatore può ottimizzare una chiamata al metodo che potrebbe chiaramente avere effetti collaterali. Oppure è std :: compilare in linea in modo che il compilatore possa vedere l'implementazione? (Non sono un programmatore C++).

Detto questo, questo genere di cose può essere una preoccupazione in generale. Ma devi pensare a quanto sia facile da sfruttare. Per leggere la memoria di un altro processo, un utente malintenzionato avrebbe bisogno di un certo livello di accesso come amministratore (in caso contrario, perché stai usando quel sistema operativo). Se la macchina è compromessa a quel livello, hai già perso.

Answer 6

Non uso std::string per le password, in quanto non zero fuori di essa la memoria quando si fa riassegnazioni o distruzione - progettare il proprio ConfidentialString classe, invece.Quando si progetta quella classe, si potrebbe voler approfittare di CryptProtectMemory ... e stare molto, molto attenti quando è necessario utilizzare la versione decrittografata, soprattutto quando si chiama il codice esterno.