Autoprotección para software antivirus

Viejo conocido, pero bueno

Las técnicas ASLR y DEP tienen ya más de 10 de antigüedad, pero son más actuales que nunca. Su verdadero sentido es el siguiente:

El código de un programa extenso casi nunca está libre de fallos. Según la página alemana de Wikipedia los mejores programas contienen solo un fallo en cada 2000 líneas de código. Pero, por ejemplo, Photoshop CS6 consta de unos 9 millones de líneas de código, Windows XP de unos 40 millones. Puede encontrar una buena vista general del número de líneas de código de los programas en el infográfico del diseñador londinense David McCandless.

Los inevitables fallos pueden convertirse más tarde en puntos débiles por los que puede introducirse el código malicioso de un atacante. Una suite de seguridad conoce estos puntos débiles e intenta rellenar los agujeros. No obstante, la suite de seguridad también es un programa compuesto de numerosos archivos y un montón de líneas de código. La propia suite podría ser un punto débil del que podría aprovecharse un atacante. Evidentemente, las consecuencias serían fatales.

Si durante la programación se incluye la compatibilidad con las técnicas ASLR y DEP, el riesgo de que pueda aprovecharse de hecho uno de los posibles puntos débiles existentes disminuye. Sin embargo, no se puede decir de forma general que un software que no utiliza ASLR y DEP sea inseguro, puesto que si la programación no contiene ni un solo fallo, la seguridad no se puede aumentar. ASLR y DEP son, por tanto, una protección adicional por si acaso de la que no se debería prescindir, dado que su uso es de lo más sencillo. Se trata de funciones existentes en el compilador que simplemente se activan adicionalmente. La extensión del código o el tiempo de ejecución del programa no se ven afectados por ello.

32 productos examinados

AV-TEST quería averiguar hasta qué punto utilizan los fabricantes esta protección adicional en sus productos. Para ello se instaló cada uno de los productos y se hizo un protocolo de todos los archivos nuevos. Después, para la evaluación se utilizaron los archivos PE (Portable Executable) User Mode para 32 y 64 bits. Todos los demás archivos, inclusive los llamados archivos PE nativos eran irrelevantes para la prueba. Entre los archivos PE están, por ejemplo:

.exe o "Executable", es decir, un programa o módulo ejecutable
.dll o "Dynamic Link Library", una biblioteca de programas
.sys o "System", un software de sistema
.drv o "Driver", un archivo de controlador para un equipo

Entre un 5 y un 45 por ciento de los archivos instalados de una solución de seguridad son archivos PE, sobre los cuales se comprobó si su código cuenta con la protección adicional DEP y ASLR.

En las tablas se recoge de manera porcentual cuántos archivos PE de un programa (separados en 32 y 64 bits) cuentan con la protección adicional. El resultado es un tanto sorprendente puesto que algunos fabricantes utilizan ASLR y DEP en parte o por completo, mientras que, por otro lado, algunos prescinden de ella por completo.

Productos para el consumidor: la protección adicional no sirve para todos

El laboratorio ha clasificado los resultados por productos para usuario privados y productos para empresas. En el caso de las suites de seguridad de Internet para usuarios privados se examinaron en total 24 productos, separados entre 32 y 64 bits. Los únicos productos que utilizan ASLR y DEP al 100 por cien son los de ESET (Consumer) y Symantec (Business). Avira, G Data, McAfee y AVG (ambos productos) solo utilizan la protección adicional al 100 por cien en los archivos de 64 bits de sus productos. En los de 32 bits, el valor oscila entre el 90 y 100 por ciento.

En resumen, la mitad de todos los paquetes de protección utilizan ASLR y DEP en más de un 90 por ciento. A partir de ahí, el uso desciende de producto a producto en pasos de un 10 por ciento aproximadamente hasta el valor más bajo de aproximadamente un 5 por ciento. En el caso único de Kingsoft, incluso al 0 por ciento por lo que respecta a 64 bits.

En el caso de muchos archivos para 64 bits, el uso de la técnica de protección, ya sea ASLR o DEP, es superior que en el de los archivos para 32 bits. Sin embargo, no puede establecerse ninguna norma.

Productos para empresas: una cuota elevada

En las soluciones para empresas, los fabricantes recurren mucho más a la autoprotección adicional con ASLR y DEP. Únicamente Symantec utiliza la protección al 100 por cien sin excepciones. Sophos solo en los archivos para 64 bits. Si se añaden los valores de 32 y 64 bits de cada producto, 6 de 8 productos utilizan la protección entre un 81,5 y hasta más de un 97 por ciento. Trend Micro es el único que no apuesta por esta técnica y solo usa ASLR y DEP en un caso 19 por ciento de sus archivos PE.

En general es evidente que la autoprotección se utiliza con más frecuencia en archivos para 64 bits que para 32 bits. No obstante, esto es una tendencia y no una regla.

Resumiendo: Más protección adicional nunca está de más

El uso de las técnicas ASLR y DEP disponibles gratuitamente es recomendable para todos los fabricantes. Al fin y al cabo es una protección adicional que no puede perjudicar. Hay que reconocer que es posible sortear ASLR con técnicas de spraying, como puede leerse en este artículo en Internet escrito en alemán "Die Rückkehr der Pufferüberläufe" (El retorno de sobrecarga de búfer). No obstante, esto exige un mayor esfuerzo por parte de quien escribe el código malicioso. Un esfuerzo que normalmente prefieren evitarse.

Tampoco es DEP (o NX-Bit) una protección infalible para los archivos, pero hace que los programadores de exploits tengan que sortear obstáculos adicionales, lo cual también supone un mayor esfuerzo.

Como casi siempre, es la suma de las cosas lo que marca la diferencia. El esfuerzo que supone salvar dos, tres o más muros de protección le cuesta al atacante tiempo, recursos y pasos adicionales que un software de seguridad posiblemente podría reconocer más fácilmente como ataque.

Esto es lo que dicen los fabricantes al respecto

AV-TEST ha enviado los resultados del examen a los fabricantes y, al mismo tiempo, les ha preguntado por qué en algunos casos no utilizan DEP y ASLR. Este es el resumen de las respuestas:

• Algunas de las bibliotecas adquiridas no utilizan DEP y ASLR. Pero, en el futuro, tienen la intención de comprar solo libraries que usen estas técnicas.
• Algunos archivos funcionan con una técnica de protección de desarrollo propio que no sería compatible con DEP y ASLR.
• Algunos archivos han sido creados con un compilador no conforme con Microsoft para protegerlos de manera especial, pero esto que no sean compatibles con DEP y ASLR.
• Determinados archivos ya no se utilizan activamente en el programa y por eso no es necesario tenerlos en cuenta.Se utilizan técnicas de protección de desarrollo propio como CFI (Control Flow Integrity ) y la técnica de sandboxing.