La variabile di inizializzazione è NULL o 0 o -1 una cattiva pratica dal punto di vista della sicurezza?

Sembra che si stiano combinando due obiettivi di sicurezza: protezione del codice contro il reverse engineering e protezione dell'applicazione dagli attacchi. Questi obiettivi sono spesso contraddittori: le protezioni contro il reverse engineering aumentano la complessità del codice e quindi rendono più probabile che il codice sia vulnerabile agli attacchi perché si comporta in modo inaspettato in determinate circostanze.

Esempio: se si inizializzano le variabili su valori casuali, è più difficile capire quando si esegue il reverse engineering che un blocco di memoria non è inizializzato. D'altra parte, tracciare le chiamate all'RNG mostrerà dove vengono inizializzate le variabili. Quindi non c'è alcun vantaggio di inizializzare le variabili su valori casuali.

Per quanto riguarda la sicurezza, l'inizializzazione delle variabili su valori casuali non è buona. Gli zeri sono molto più sicuri. Se si scopre che la variabile viene utilizzata senza essere inizializzata, uno zero è spesso meno dannoso: puoi ricontrollare se il valore non dovrebbe essere 0 e, se si tratta di un puntatore, porterà a un arresto anomalo la prima volta è dereferenziata. Al contrario, un valore casuale porterebbe a comportamenti imprevedibili, un potenziale buco di sicurezza.

La protezione dal reverse engineering è così costosa (perché il debugging è più difficile della programmazione, e questo è il doppio per l'offuscamento) che è estremamente raro che valga la pena. Se hai determinato che è necessario spendere sforzi per l'offuscamento, probabilmente sottovaluti la difficoltà. Se si sceglie comunque di offuscare, l'inizializzazione delle variabili su valori casuali non è una tecnica molto utile, perché è facile vedere sotto l'analisi statica o dinamica che i valori casuali non vengono comunque utilizzati. L'offuscamento richiederebbe che si usassero i valori casuali per eseguire calcoli, ma che il risultato finale non dipendesse dal valore.

Da un punto di vista sicurezza , l'inizializzazione delle variabili su NULL, 0 o altro valore sicuro e riproducibile è una buona pratica.

In molti linguaggi di programmazione, l'inizializzazione delle variabili locali è forzata, oppure il motore si rifiuta categoricamente di leggere i dati non inizializzati. Anche nelle lingue in cui puoi leggere le variabili non inizializzate e ottenere così una copia di ciò che è rimasto nella RAM in quella posizione, non puoi contare su di esso essere "casuale"; avrà la tendenza a contenere sempre lo stesso valore, a seconda di ciò che l'applicazione ha fatto in precedenza. Infatti, in C, le variabili locali vengono dallo stack e / o memorizzate nella cache nei registri della CPU, e queste sono risorse che vengono costantemente riutilizzate in tutta l'applicazione.

Se l'articolo che leggi raccomanda di non inizializzare la variabile locale, e poi per leggerli, e si aspetta che questo produca "casualità" , quindi questo articolo sarà bruciato sul rogo, per molte ragioni:

• La lettura di dati non inizializzati è una chiara violazione delle specifiche; nello standard del linguaggio di programmazione C, questo è chiamato "comportamento non definito" e può produrre risultati problematici, incluso un arresto anomalo dell'applicazione o, peggio ancora, un danneggiamento della memoria silenziosa.

• Questo tipo di casualità non può essere buono, da qualsiasi nozione di "casualità" di cui parlare.

• Il comportamento riproducibile è buono . Cercando di ottenere valori non riproducibili da variabili locali, l'articolo promuove solo rendendo il codice impossibile da eseguire il debug, che può solo essere descritto come una cosa stupida da fare . In particolare per la sicurezza. Ciò garantirà quasi la presenza di buchi di sicurezza di lunga durata e difficili da individuare.

Se vuoi casualità, utilizza ciò che il sistema operativo fornisce, ad es. %codice%. È incomparabilmente migliore, sotto tutti i punti di vista, dei rituali fatti in casa irrazionali che servono a propiziare gli dei della casualità.

Modifica: come sottolinea @TerryChia, la tua domanda potrebbe riguardare forzare un'inizializzazione casuale di variabili (locali o meno) da un PRNG, invece di lasciare l'impostazione predefinita valore lì (se c'è è un valore predefinito, ovviamente; in molti linguaggi di programmazione, le variabili locali non hanno alcun valore predefinito). Ciò che chiami "XOR" in quel contesto non è chiaro.

In questo caso, o non leggi le suddette variabili prima di memorizzare un valore significativo in esse, nel qual caso ciò che le variabili inizialmente contenute è completamente irrilevante: non influisce sul comportamento del tuo codice. O tu fai leggi le variabili e poi ottieni questi valori più o meno casuali da loro, rendendo il codice dell'applicazione non riproducibile e portando ai problemi spiegati sopra; vale a dire che il codice sarà difficile da eseguire il debug, aumentando la probabilità e la densità delle vulnerabilità effettive.

L'inizializzazione delle variabili fornisce un comportamento coerente. Dovresti usare un RNG che sia sufficientemente casuale da solo. XORare il tuo output casuale con qualsiasi cosa si trovi in quella posizione di memoria realisticamente non dovrebbe fornire alcun vantaggio.

Non è consigliabile affidarsi a una soluzione del genere per aumentare la casualità di un valore.

Ma fai attenzione a non rompere le cose correggendole .