Protección del código con las defensas de Visual C++
Protección del código con las defensas de Visual C++
Michael Howard
Gran parte del código está escrito en C y C++ y desgraciadamente una gran parte de este código tiene vulnerabilidades de seguridad que muchos desarrolladores no conocen.
Los programas escritos en cualquier lenguaje pueden tener vulnerabilidades que dejan a sus usuarios abiertos a un ataque, pero los lenguajes C y C++ ocupan un lugar especial en la historia de Internet porque muchas de sus vulnerabilidades de seguridad se deben al mismo motivo por el que estos dos lenguajes de programación son tan populares: el acceso sin restricciones al hardware del equipo y el rendimiento que esto conlleva. Cuando lee acerca de la seguridad y surge C o C++, las palabras "búfer" y "saturación" suelen aparecer muy cerca la una de la otra, ya que los búferes son un ejemplo muy común del acceso directo a la memoria. Este tipo de acceso directo es muy eficaz, pero también muy, muy peligroso.
Existen varias razones por las que se producen saturaciones de búfer en la producción de código C y C++. La primera ya la he mencionado: estos lenguajes proporcionan acceso directo a la memoria vulnerable. Segundo, los desarrolladores cometen errores. Y tercero, normalmente los compiladores no ofrecen defensas. Es posible proporcionar un remedio para el primer problema, pero entonces C y C++ comenzarían a transformarse en lenguajes distintos.
El que los desarrolladores cometan errores se puede resolver en parte mediante métodos educativos, pero realmente no veo ningún paso adelante de las instituciones pertinentes. Seguro que hay un lugar en la industria para la educación en materia de seguridad, pero todos somos parte de la solución o parte del problema y me encantaría que las universidades dedicaran más esfuerzos a la educación de sus alumnos en cuestiones de seguridad de software. Probablemente se estará preguntando, "¿por qué las instituciones educativas no intentan formar a los alumnos en esta materia tan crucial?" Francamente, no tengo la menor idea. Es algo deprimente, la verdad.
Finalmente, aún con una educación excelente, algunos problemas de seguridad son tan complejos que incluso los ingenieros más punteros no podrían resolverlos en su totalidad. Nosotros, los humanos, no somos perfectos.
La necesidad de crear más defensas en los compiladores es algo en lo que el equipo de Microsoft Visual C++ ha estado trabajando y, aunque lentamente, se han conseguido algunas mejoras con el paso de los años y la ayuda de nuestro equipo de la seguridad. Esta columna resume algunas de las defensas frente a la saturación del búfer disponibles en Visual C++® 2005 y versiones superiores. Tenga en cuenta que algunos compiladores ofrecen defensas, pero Visual C++ tiene dos ventajas muy importantes frente a los compiladores estilo gcc. Primero, todas estas defensas están en el conjunto de herramientas de forma predeterminada; no hay necesidad de descargar ningún complemento extraño. Segundo, las opciones son fáciles de usar.
Si ningún orden particular, las defensas ofrecidas por el conjunto de herramientas de Visual C++ son:
- Detección de la saturación del búfer basada en pilas (/GS)
- Controlador seguro de excepciones (/SafeSEH)
- Compatibilidad de prevención de ejecución de datos (DEP) (/NXCompat)
- Selección aleatoria de imágenes (/DynamicBase)
- Uso automático de llamadas de función más seguras
- C++ operator::new
Antes de tratar cada una de estas opciones en detalle quiero dejar claro que estas defensas no compensan la existencia de un código inseguro. Debe esforzarse siempre para crear el código más seguro posible, y si no sabe cómo hacerlo, entonces vaya corriendo a leer alguno de los excelentes libros que tratan sobre esta materia.
Pila típica comparada con una compilada con /GS (Hacer clic en la imagen para ampliarla)
También quiero señalar que todo esto es parte de los requisitos del Ciclo de vida de desarrollo de seguridad (SDL, Security Development Lifecycle) en Microsoft, lo que significa que los códigos C y C++ deben usar estas opciones para salir al mercado. Hay excepciones puntuales, pero se producen con poca frecuencia, así que no voy a hablar de ellas aquí.
Finalmente, debe tener presente un punto importante: Es posible, dependiendo del código en cuestión, sortear estas defensas tan elaboradas. Cuantas más defensas use el código, más difícil será evitarlas, pero ninguna defensa es perfecta. Todas ellas son obstáculos para reducir la posibilidad de éxito de una vulnerabilidad. ¡Queda advertido! La única variante es el uso de llamadas de función más seguras, que son verdaderas defensas y pueden eliminar vulnerabilidades. Observemos cada defensa en detalle.
Detección de la saturación del búfer basada en pilas (/GS)
La detección de la saturación del búfer basada en pilas es la defensa más antigua y más conocida disponible en Visual C++. El objetivo del marcador del compilador /GS es sencillo: reducir la oportunidad de que el código malintencionado se ejecute correctamente. La opción /GS está activada de forma predeterminada en Visual C++ 2003 y versiones posteriores, y detecta ciertas clases de desbordamiento de pila en tiempo de ejecución. Se trata de hacer esto incluyendo un número aleatorio en la pila de una función justo antes de la dirección de devolución de la pila. Cuando vuelva la función, el código de epílogo de función comprueba este valor para asegurarse de que no ha cambiado. Si la cookie, como así se llama, ha cambiado, la ejecución se detiene.
El código de prólogo de la función que establece la cookie se parece a esto:
Código:
sub esp, 8
mov eax, DWORD PTR ___security_cookie
xor eax, esp
mov DWORD PTR __$ArrayPad$[esp+8], eax
mov eax, DWORD PTR _input$[esp+4
]
Y aquí se muestra el código de epílogo de función que comprueba la cookie:
Código:
mov ecx, DWORD PTR __$ArrayPad$[esp+12]
add esp, 4
xor ecx, esp
call @__security_check_cookie@4
add esp, 8
Visual C++ 2005 también mueve los datos alrededor de la pila para que sea más difícil dañar los datos. Uno de los ejemplos sería el desplazamiento de los búferes a una memoria superior que los no búfer. Por ejemplo, este paso puede ayudar a proteger los punteros de función que residen en la pila. De manera alternativa, al desplazar los argumentos de puntero y búfer a una memoria inferior en el tiempo de ejecución se mitigan varios ataques de saturación del búfer. Consulte el diagrama para comparar una pila típica con una pila /GS.
La opción de compilador /GS no se aplica en ninguna de las situaciones siguientes:
- --Las funciones no contienen un búfer.
- --Las optimizaciones no están habilitadas.
- --Las funciones se han definido para tener una lista de argumentos variable.
- --Las funciones se han marcado con la palabra clave sencilla (C++).
- --Las funciones contienen código ensamblador en línea en la primera instrucción.
- --El búfer no es del tipo de 8 bytes y tiene un tamaño inferior a 4 bytes.
Se ha agregado una opción a Visual C++ 2005 SP1 para hacer la heurística de /GS mucho más agresiva y proteger así más funciones. Microsoft agregó esta opción porque se publicó un pequeño número de boletines de seguridad con código que tenía saturación del búfer basada en pilas y el código, a pesar de estar compilado con /GS, no estaba protegido por una cookie. Esta nueva opción aumenta el número de funciones protegidas de manera significativa.
Use esta opción colocando la línea siguiente en módulos en los que desee protección adicional, como el código que administra datos de Internet:
#pragma strict_gs_check(on)
Esta pragma es sólo un ejemplo de cómo Microsoft evoluciona constantemente la capacidad /GS. La versión original en Visual C++ 2003 era bastante sencilla, después se actualizó en Visual C++ 2005 SP1 y una vez más en Visual C++ 2008, ya que tuvimos conocimiento de nuevos ataques y maneras para sortear los ataques existentes. En nuestro análisis, hemos descubierto que /GS no causa problemas de compatibilidad ni de rendimiento.
Controlador seguro de excepciones (/SafeSEH)
El gusano CodeRed que afectó a Internet Information Server (IIS) 4.0 fue causado por una saturación del búfer basado en pilas. Curiosamente, /GS no habría detectado el problema explotado por el gusano porque el código no saturó la dirección de devolución de la función afectada, sino que dañó un controlador de excepciones de la pila. Este es un buen ejemplo de por qué usted debe centrarse constantemente en escribir código seguro y no confiar únicamente en estos tipos de defensas basadas en el compilador.
Un controlador de excepciones es un código que se ejecuta cuando ocurre una condición excepcional, como la división entre cero. La dirección del controlador se conserva en el marco de pila de la función y, por lo tanto, está sujeto a daños. El vinculador que se incluye con Visual Studio® 2003 y sus versiones posteriores incluye una opción que permite almacenar la lista de controladores de excepciones válidos en el encabezado PE de la imagen en el tiempo de compilación. Cuando se genera una excepción en tiempo de ejecución, el sistema operativo comprueba el encabezado de la imagen para determinar si la dirección de controlador de excepciones es correcta. Si no lo es, la aplicación finaliza. Esto habría evitado la acción de CodeRed si hubiera existido la tecnología en el momento en que se vinculó el código. La opción /SafeSEH no causa ningún tipo de descenso del rendimiento, salvo que cuando se genera una excepción, siempre debe vincularse a esta opción.
Compatibilidad de DEP (/NXCompat)
Prácticamente todas las CPU que se fabrican hoy en día son compatibles con la capacidad de no ejecución (NX), lo que significa que la CPU no ejecutará páginas sin código. Piense por un momento en las implicaciones de esto: casi todas las vulnerabilidades de saturación del búfer son errores de datos. Entonces, el atacante inserta los datos en el proceso mediante la saturación del búfer y continúa la ejecución dentro del búfer de datos malintencionados. ¿Por qué ejecuta la CPU los datos?
Al vincular con la opción de /NXCompat su archivo ejecutable estará protegido por la capacidad de no ejecución de la CPU. Según nuestra experiencia, el equipo de seguridad de Microsoft ha tenido muy pocos problemas de compatibilidad debidos a esta opción y, hasta ahora, no ha habido degradación del rendimiento.
Windows Vista SP1 agrega también una nueva API que habilita DEP para su proceso de ejecución y que una vez establecido, no se puede desactivar:
SetProcessDEPPolicy(PROCESS_DEP_ENABLE);
Selección aleatoria de imágenes (/DynamicBase)
Windows Vista y Windows Server® 2008 son compatibles con la selección aleatoria de imágenes. Esto significa que cuando se arranca el sistema, éste distribuye el orden aleatorio de las imágenes de sistema operativo en la memoria. El propósito de esta característica es simplemente eliminar parte de la capacidad de previsión de los atacantes. Esto se conoce también como selección aleatoria de la distribución del espacio de direcciones (ASLR, Address Space Layout Randomization). Tenga en cuenta que para que la ASLR sea útil, debe tener también DEP habilitado.
De manera predeterminada, Windows® sólo se permitirá mover los componentes del sistema. Si desea que su imagen circule por el sistema operativo (altamente recomendado), debe vincular con la opción /DynamicBase. Esta opción está disponible en Visual Studio 2005 SP1 y los conjuntos de herramientas posteriores. También se produce un efecto secundario interesante al vincular con /DynamicBase, que consiste en que el sistema operativo distribuye el orden aleatorio de la pila, lo que a su vez reduce la capacidad de previsión y dificulta que los atacantes pongan en peligro un sistema. Tenga en cuenta que también se distribuye el orden aleatorio del montón en Windows Vista y Windows Server 2008. No obstante, esto ocurre de forma predeterminada, por lo que no es necesario compilar ni vincular con ninguna opción especial.
Llamadas de función más seguras
Observe las siguientes líneas de código:
Código:
void func(char *p) { char d[20]; strcpy(d,p); // etc}
Suponiendo que *p contiene los datos que no son de confianza, este código representa una vulnerabilidad de seguridad. El aspecto más negativo de este código es que el compilador podría haber trasladado la llamada a strcpy a una llamada de función más segura que enlazara la operación de copia al tamaño del búfer de destino. ¿Por qué? Porque el tamaño del búfer es estático y conocido a la hora de compilar
Con Visual C++ puede agregar la siguiente línea a su archivo de encabezado stdafx.h:
#define _CRT_SECURE_COPP_OVERLOAD_STANDARD_NAMES 1
El compilador entonces seguirá adelante y emitirá el siguiente código desde la función inicial no segura:
Código:
void func(char *p) {
char d[20];
strcpy_s(d,__countof(d), p);
// etc}
Como puede ver, ahora el código es seguro, y el desarrollador sólo ha agregado un #define. Esta es una de mis adiciones favoritas a Visual C++, porque cerca del 50 por ciento de las llamadas de función no seguras pueden ascender a llamadas más seguras automáticamente.
C++ Operator::new
Finalmente, Visual C++ 2005 y las versiones posteriores agregan una defensa que detecta el desbordamiento de enteros al llamar a operator::new. Puede empezar con código de esta manera:
CFoo *p = new CFoo[count];
Visual C++ lo compila a:
Código:
00004 33 c9 xor ecx, ecx
00006 8b c6 mov eax, esi
00008 ba 04 00 00 00 mov edx, 4
0000d f7 e2 mul edx
0000f 0f 90 c1 seto cl
00012 f7 d9 neg ecx
00014 0b c8 or ecx, eax
00016 51 push ecx
00017 e8 00 00 00 00 call ??2@YAPAXI@Z ; operator new
Una vez calculada la cantidad de memoria para asignar (mul edx), se establece o no el registro de CL dependiendo del valor del indicador de desbordamiento después de la multiplicación, de modo que ECX será 0x00000000 o 0xFFFFFFFF. A causa de la operación siguiente (o ecx), el registro ECX será 0xFFFFFFFF o el valor incluido en EAX, que es el resultado de la multiplicación inicial. Esto entonces pasa a operator::new, que generará un error en el caso de la asignación 2^N-1.
Esta defensa es gratuita. No hay modificador de compilador; esto es simplemente lo que el compilador hace.
¿Qué ocurre si hay errores?
¡Ah! ¡Esa es la cuestión espinosa! Si cualquiera de las defensas enumeradas se activa, se produce un resultado bastante desagradable: la aplicación finaliza. Esto no es ideal, pero es mucho mejor que ejecutar el código malintencionado del atacante.
El SDL obliga a que el código nuevo use todas estas opciones defensivas, ya que hay tantos ataques que nunca puede comprobar que su código esté totalmente libre de vulnerabilidades. Una de las frases clásicas del SDL es "asuma que su código tendrá errores... ¿ahora qué?" En el mundo verdadero, "ahora que" significa oponer resistencia. No le ponga las cosas fáciles al código del atacante. Al contrario, vaya un paso por delante para que no consiga sus objetivos. ¡No se rinda!
Así que compile con la última versión del compilador C++ para obtener un mejor /GS y vincule con el último vinculador para beneficiarse de las defensas de CPU y sistemas operativos.
Envíe sus preguntas y comentarios a [email protected].
Michael Howard es administrador principal de programas de seguridad en Microsoft y se encarga de mejorar los procesos seguros y las prácticas recomendadas. Es coautor de cinco libros sobre seguridad, incluidos Writing Secure Code for Windows Vista, The Security Development Lifecycle, Writing Secure Code y 19 Deadly Sins of Software Security.
Consulte su blog en blogs.msdn.com/michael_howard
Via msdn2.microsoft.com
