implicaciones de seguridad de la desreferencia NULL

Question

implicaciones de seguridad de la desreferencia NULL

#1 de Thomas Pornin (8 votos)
#2 de D.W. (5 votos)

11

Supongamos que tenemos un código como este:

struct somedata {
   int a;
   int b;
};
struct somedata *data;
/* ... */
data = malloc(sizeof(struct somedata));
data->a = something;

Ahora, como puede ver, falta la comprobación del puntero NULO. La pregunta es: ¿tiene esto implicaciones de seguridad en caso de que malloc falle? Asumamos que el proceso que sale de SEGV por sí mismo no es un problema en este caso. ¿Hay alguna otra forma en que esto pueda ser un problema desde el punto de vista de la seguridad? La aplicación que contiene este código no es SUID o tiene privilegios elevados, pero procesa entradas externas, por lo que algunas partes de su memoria pueden ser controladas por el usuario.

P.S. Soy consciente de CWE-476 pero las implicaciones de seguridad se describen de una manera muy vaga ("En circunstancias y entornos muy raros, la ejecución del código es posible ", ¿qué circunstancias? ¿qué entornos? ¿Qué tan raros son los golpes de meteoros que son raros o raros una vez al año? Y me gustaría ver algunos Información más específica sobre cuál es la amenaza.

attacks source-code appsec c

pregunta StasM 28.07.2011 - 19:00

fuente

2 respuestas

5

En el código del kernel, este error es una vulnerabilidad grave . El código de usuario puede solicitar que se vuelva a asignar la página comenzando en la dirección 0, y esa asignación también se aplicará al código del kernel. Entonces, si esto sucede, el kernel ahora está leyendo (o escribiendo) en la memoria controlada por el usuario en lugar de en la memoria controlada por el kernel, lo que podría violar la integridad (o confidencialidad) del cálculo de los kernels. Por ejemplo, si el kernel lee un puntero de esta página y luego lo elimina, pueden suceder cosas muy malas. Por lo tanto, este tipo de error puede habilitar la escalada de privilegios, permitiendo que un proceso de usuario no root malicioso ataque el kernel y haga cosas que no debería permitir hacer.

En el código de aplicación de nivel de usuario, este error generalmente no es un problema de seguridad, porque no hay forma de que un atacante pueda volver a asignar la página cero sin la cooperación de la aplicación. (Excepción: hay algunas aplicaciones que vuelven a asignar la página a la dirección 0. Estoy pensando, por ejemplo, en Wine. No sé si existen implicaciones de seguridad para esas aplicaciones excepcionales.)

Gracias a @ this.josh por el enlace a una explicación de la vulnerabilidad en el código de nivel de kernel.

respondido por el D.W. 03.08.2011 - 00:00

fuente

Lea otras preguntas en las etiquetas attacks source-code appsec c

Recuperar archivos de un USB posiblemente infectado Trabajo de seguridad independiente

score 8 · Accepted Answer

"El proceso que sale de SEGV por sí solo no es un problema en este caso": esto ya es una suposición importante. Lo que sea que esté haciendo el proceso no estará terminado; la persona que llama recibe un código de error; Si el proceso ha creado archivos temporales, esos archivos no se borran. Asegurarse de que realmente no haya problemas es complicado.

Además, lo que crea SEGV es el acceso a un área de memoria que el sistema operativo ha marcado deliberadamente como no válido; a saber, la primera "página" del espacio de direcciones (una página que tiene 4096 bytes en una PC). Considera lo siguiente:

data = malloc(1000000 * sizeof(struct somedata));
data[800000].a = something;

Si struct somedata tiene una longitud de 8 bytes, y la asignación falla, entonces el código intentará escribir algo en la dirección +6400000. Incluso si el sistema operativo no asignó los primeros 4096 bytes, es muy posible que la dirección 6400000 sea válida y se use para otra cosa, que se sobrescriba silenciosamente. En ese punto, todo vale. De nuevo, saber si un NULL dado devuelto por malloc() implicaría un fallo de seguridad inmediato o una corrupción silenciosa puede ser difícil.

Si el proceso no tiene derechos especiales y el atacante ya tiene la capacidad de ejecutar archivos ejecutables con los mismos privilegios, entonces no comprobar el valor devuelto por malloc() no descubre nuevos problemas de seguridad. Es simplemente descuidado.