Si sta utilizzando IsBadReadPtr e IsBadWritePtr considerati non sicuri?

2

Sto verificando (reverse engineering) un'applicazione x86 C ++ senza codice sorgente. L'analisi statica ha rivelato che l'applicazione utilizza le funzioni IsBadReadPtr e IsBadWritePtr Win32 in quasi tutti i casi, per verificare i parametri della funzione. Quindi, queste due funzioni sono chiamate da quasi tutte le funzioni trovate nell'applicazione.

Ho trovato i seguenti post, dicendo che le funzioni IsBadXXXPtr non dovrebbero essere usate. Non ero in grado di capire il rischio per la sicurezza di usare le funzioni sopra menzionate, qualcuno può spiegarmelo?

posta madmax25 15.02.2016 - 22:19
fonte

1 risposta

2

TL; DR

Il motivo per cui sono cattivi è elencato nei link che hai fornito. A causa della progettazione del sistema operativo Windows, del modo in cui le funzioni sono state codificate e del fatto che determinare se la memoria è valida è difficile rende queste funzioni intrinsecamente instabili da utilizzare.

Non esiste un buon modo per determinare se un puntatore utilizza una parte di memoria valida. La memoria libera non viene necessariamente azzerata o ripristinata. Se c'è un puntatore errato che gira intorno potrebbe puntare a dati che in una porzione di memoria valida. Solo perché è possibile dereferenziare il puntatore non significa che i dati stessi siano validi.

Queste due funzioni utilizzano le eccezioni di page guard per determinare se la memoria è valida. Il progetto di queste eccezioni non dovrebbe essere usato come un controllo di "indirizzo di memoria valido". Come descritto dal primo link:

The IsBadXxxPtr function will catch the exception and return “not a valid pointer”. But guard page exceptions are raised only once. You just blew your one chance. When the code that is managing the guard page accesses the memory for what it thinks is the first time (but is really the second), it won’t get the guard page exception but will instead get a normal access violation

Fondamentalmente, anche utilizzando queste funzioni, è possibile causare violazioni di accesso a causa del design generale del sistema operativo Windows e del modo in cui queste funzioni sono state codificate. Anche se non utilizzi le protezioni di pagina, non è garantito che altre librerie condivise che stai caricando non utilizzino le protezioni di pagina.

Cercare di catturare le eccezioni dal sistema operativo che stanno cercando di dirti che le cose sono andate molto male è una cattiva idea. C'è un errore di programmazione da qualche parte e l'opzione migliore è crash. Cercare di tornare a uno stato buono quando le cose vanno così male può causare un comportamento indeterminato.

La linea di fondo è che non è possibile risolvere ciò che è andato storto con la memoria. L'esecuzione continua ti brucerà solo più tardi.

    
risposta data 18.02.2016 - 19:57
fonte