En el sentido de que puedes hacer que el programa actúe de una manera que no debería, entonces sí, esto es explotable. Hasta qué punto puedes explotar el proceso depende completamente del proceso. En sí.
Hacer que el proceso finalice con un error (Denegación de servicio) es fácil, simplemente escriba 4 bytes aleatorios en una ubicación aleatoria y probablemente lo tropiece.
Una sobrescritura de 4 bytes le permite reemplazar un valor de dirección de 32 bits. Lo primero que viene a la mente es subvertir el flujo del programa, ya sea un return , un call o un jump .
Si puedes encontrar un fragmento de código que te haga algo útil, normalmente mirando las bibliotecas que están cargadas, puedes saltar a eso. Incluso podría hacer una llamada al sistema si puede encontrar una situación que tenga los argumentos correctos cargados en la pila antes de una instrucción de flujo de programa.
Podría sobrescribir el valor de un puntero en la pila para que apunte a otra cosa, esto podría fácilmente llevar a divulgación de información . Como alterar el puntero que apunta a la cadena de su nombre de usuario para que apunte a una clave secreta, o un hash de contraseña, y luego interactuar con el programa de tal manera que generalmente haga eco de su cadena de nombre de usuario .
Puede alterar una entrada en la Tabla de compensación global para suplantar una llamada de función con otra llamada de función globalmente a lo largo del proceso. Esto le permitiría, por ejemplo, eliminar una función de envoltorio al hacer que todas las llamadas al envoltorio realmente sean llamadas a la función interna, eliminando potencialmente una función de seguridad, como una verificación de parámetros, que luego podría explotar.
Podría seguir, pero la idea es:
El hecho de que no pueda inyectar directamente Shellcode no significa que no pueda inyectarlo en absoluto. Tal vez haya una forma de cargar un archivo que abrirá la aplicación. Si la aplicación está escuchando en la red, puede comenzar a comunicarse con ella; incluso si se descarta rápidamente la solicitud porque no puede autenticarse, eso deja su paquete en la memoria. La inyección del código shell puede (y con frecuencia debe hacerse) por medios legítimos, con la vulnerabilidad que solo le permite saltar a él.
Si la aplicación realiza un paso de autenticación en cualquier punto, omítalo o niegue.
4 bytes le permite cambiar una dirección. Por ejemplo, puede sustituir una llamada de función por otra. Puede haber una cadena interesante para llamar a system ya en la memoria, o puede proporcionar una. Si la aplicación alguna vez abre un zócalo, haga arreglos para saltar al código de apertura del zócalo (por ejemplo, a una llamada bind ) mientras los registros apuntan a una estructura involuntaria que hace que escuche una conexión que proviene de usted. Cambiar de AF_UNIX a AF_INET en una llamada de socket (cambio de un solo byte) podría ser todo lo necesario si tienes suerte.