¿Se considera inseguro el uso de IsBadReadPtr y IsBadWritePtr?

2

Estoy auditando (ingeniería inversa) una aplicación x86 C ++ sin código fuente. El análisis estático reveló que la aplicación está utilizando las funciones IsBadReadPtr y IsBadWritePtr Win32 en casi TODOS los casos, para verificar los parámetros de la función. Por lo tanto, estas dos funciones se llaman desde casi todas las funciones encontradas en la aplicación.

Me he encontrado con las siguientes publicaciones, diciendo que no se deben usar las funciones de IsBadXXXPtr. No pude entender el riesgo de seguridad de usar las funciones mencionadas anteriormente, ¿alguien me lo puede explicar?

pregunta madmax25 15.02.2016 - 22:19
fuente

1 respuesta

2

TL;DR

La razón por la que son malas se encuentra en los enlaces que has proporcionado. Debido a la forma en que está diseñado el sistema operativo Windows, la forma en que se codificaron las funciones y el hecho de que determinar si la memoria es válida es difícil hace que estas funciones sean inherentemente inestables de usar.

No hay una buena manera de determinar si un puntero está utilizando una parte válida de la memoria. La memoria liberada no necesariamente se pone a cero o se reinicia. Si hay un puntero malo flotando alrededor, podría apuntar a datos que están en una parte válida de la memoria. El hecho de que no pueda hacer referencia al indicador no significa que los datos en sí sean válidos.

Esas dos funciones utilizan excepciones de protección de página para determinar si la memoria es válida. El diseño de estas excepciones no debe utilizarse como una verificación de "dirección de memoria válida". Como se describe en el primer enlace:

  

La función IsBadXxxPtr detectará la excepción y devolverá "no un   puntero valido ". Pero las excepciones de la página de guardia se levantan solo una vez. Tú   sólo sopló tu única oportunidad. Cuando el código que está gestionando la guardia.   La página accede a la memoria por lo que cree que es la primera vez (pero es   realmente el segundo), no obtendrá la excepción de la página de guardia, pero   en lugar de obtener una infracción de acceso normal

Básicamente, incluso al usar estas funciones puede causar violaciones de acceso debido al diseño general del sistema operativo Windows y cómo se codificaron estas funciones. Incluso si no está utilizando protectores de páginas, no hay garantía de que otras bibliotecas compartidas que está cargando no estén utilizando protectores de páginas.

Tratar de detectar excepciones del sistema operativo que intentan decirte que las cosas han salido terriblemente mal es una mala idea. Hay un error de programación en alguna parte y la mejor opción es bloquearse. Tratar de volver a un buen estado cuando las cosas salen mal puede causar un comportamiento indeterminado.

La conclusión es que no puedes arreglar lo que salió mal con la memoria. La ejecución continua solo te quemará más tarde.

    
respondido por el RoraΖ 18.02.2016 - 19:57
fuente

Lea otras preguntas en las etiquetas