Encontrar problemas de seguridad en un código dado

Question

¿Puede alguien decirme un enfoque para encontrar fallas de seguridad en un código dado? Por ejemplo: en un programa de socket dado. Cualquier buen ejemplo o buenas recomendaciones de libros son bienvenidos.

Gracias & Saludos,

Mousey

Answer 1

La fruta que cuelga más bajo en esta categoría sería simplemente buscar la fuente para las funciones que son comúnmente mal utilizados o que son difícil uso con seguridad, tales como:

• strcpy
• strcat
• sprintf
• obtiene

y comienza a buscar los que no son muy malos, pero que podrían ser mal utilizados. En particular, cualquier cosa que se escriba en un búfer puede ser potencialmente peligrosa si se utiliza incorrectamente.

• memcpy
• memmove
• recv/leer
• envío/escribir
• toda la familia printf siempre debe tener un constante para la cadena de formato

NOTA: todos de estos (excepto gets) se pueden usar correctamente, así que no piense que es un error solo porque la función se utiliza, en su lugar eche un vistazo a cómo se usa. También tenga en cuenta que gets es siempre un defecto.

NOTA2: esta lista es no exhaustiva, investigue un poco acerca de las funciones comúnmente mal usadas y cómo se pueden evitar.

cuanto a las herramientas, que recomiendan cosas como valgrind y splint

Answer 2

que tomaron una clase de seguridad donde se utilizó un producto comercial llamado Fortify 360, que hizo el análisis estático de código C++. Lo ejecutamos contra una versión vieja y antigua de OpenSSL, y encontró muchas cosas, y proporcionó una guía para rectificar los defectos (que, dicho sea de paso, la última versión de OpenSSL había resuelto).

En cualquier caso, es una herramienta comercial útil.

Answer 3

Aquí está la recomendación del libro: Writing Secure Code. Demuestra no solo cómo escribir código seguro, sino también trampas y prácticas comunes que exponen los agujeros de seguridad. Está un poco anticuado (mi copia dice que fue publicado en 2002), pero los conceptos de seguridad que enseña siguen siendo bastante aplicables incluso 8 años después.

Answer 4

Un tema importante que no se cubrió en la respuesta de Evan es el número entero de desbordamientos.He aquí algunos ejemplos:

wchar_t *towcs(const char *s) 
{ 
    size_t l = strlen(s)+1; 
    mbstate_t mbs = {0}; 
    wchar_t *w = malloc(l*sizeof *w), *w2; 
    if (!w || (l=mbsrtowcs(w, (char **)&s, l, &st))==-1) { 
     free(w); 
     return 0; 
    } 
    return (w2=realloc(w, l*sizeof *w)) ? w2 : w; 
} 

Aquí, una cadena gigante (> 1gig de 32 bits) hará que la multiplicación por el tamaño (estoy asumiendo 4) de desbordamiento, lo que resulta en una pequeña asignación y posteriores escrituras en el pasado fin de eso

Otro ejemplo más común:

uint32_t cnt; 
fread(&cnt, 1, 4, f); 
cnt=ntohl(cnt); 
struct record *buf = malloc(cnt * sizeof *buf); 

Este tipo de código se convierte en la lectura de datos de archivos/red mucho, y es objeto de la misma clase de desbordamientos.

Básicamente, cualquier aritmética realizada en valores obtenidos de una fuente que no es de confianza, que eventualmente se utilizará como un tamaño de asignación/desplazamiento de matriz, necesita ser verificada. Usted puede hacerlo de la manera barata (imponer límites arbitrarios en el valor de lectura que lo mantienen significativamente fuera del rango que podría desbordarse, o puede probar de desbordamiento en cada paso: En lugar de:

foo = malloc((x+1)*sizeof *foo); 

Es necesario hacer:.

if (x<=SIZE_MAX-1 && x+1<=SIZE_MAX/sizeof *foo) foo = malloc((x+1)*sizeof *foo); 
else goto error; 

Un grep simple para malloc/realloc con los operadores aritméticos en su argumento encontrarán muchos de estos errores (pero no aquellos en los que se produjo el desbordamiento ya unas pocas líneas anteriores, etc.)

Answer 5

Algunos construcciones de código fuente puede estar atento a ar e:

• Funciones que no hacen comprobación de límites. Evan lo cubrió bastante bien.
• Validación de entrada & desinfección, o la falta de ella.
• Desregulación de punteros NULL
• fork() s, execve() s, pipe() s, system() llamado con parámetros no estáticos (o peor, con la entrada del usuario).
• Objetos compartidos entre subprocesos con duraciones de almacenamiento inadecuadas (punteros a variables automáticas o incluso objetos "muertos" en el almacenamiento local de subprocesos).
• Al tratar con la manipulación de archivos, asegúrese de utilizar los tipos de variables correctos para los resultados de retorno de las funciones. Asegúrate de que se comprueben si hay errores. No haga suposiciones sobre la implementación: permisos de archivos creados, exclusividad de nombres de archivos, etc.
• Deben evitarse las fuentes de aleatoriedad deficientes (para cifrado, comunicación, etc.).
• Los errores simples u obvios (tal vez por descuido) deben repararse de todos modos. Nunca se sabe qué es explotable, a menos que lo sea.

Además, son los datos protegidos? Bueno, si no te importa, está bien. :-)

Algunas herramientas que se pueden considerar son:

• valgrind: expone fallas de memoria, que en aplicaciones de gran tamaño suelen ser crítico.
• férula: un corrector estática
• fuzzing marcos
• RATS: a, herramienta gratuita de código abierto. La compañía de sus autores fue adquirida por Fortify.

Answer 6

Algunas personas de OpenBSD publicaron recientemente un presentation on their coding practices.