Buscando vulnerabilidades a través de una comparación de código similar. ¿Es un vector de ataque viable?

Para el registro, la respuesta es mayormente sí.

El problema es analizado exhaustivamente por varios investigadores como Hongzhe Li et al. en "Un enfoque escalable para el descubrimiento de vulnerabilidades Basado en los parches de seguridad "(Springer, 2014) y Silvio Cesare, Yang Xiang y Jun Zhang:" Clonewise - Detección de clones a nivel de paquete mediante aprendizaje automático "(Springer, 2013).

El primer documento muestra evidencia de que es un método de trabajo, el segundo sugiere que puede ser incluso semiautomatizado a través del aprendizaje automático.

Problema estrechamente relacionado discutido en Amir H. Moin y Mohammad Khansari: "Localización de errores utilizando el análisis de registro de revisión y la categorización de texto del repositorio de errores abierto" (Springer, 2010)

Entonces la respuesta es:

• sí, es un vector de ataque viable,
• no, no tiene nombre (todavía),
• y, sí, hay algunas investigaciones en existencia que explican el tema (ver más arriba).

En teoría, sí, esto es posible y ha habido algunos intentos para hacerlo. Sin embargo, la técnica no es tan práctica porque hay demasiadas variables involucradas para generalizar el enfoque. De lo que habla es en realidad solo un subconjunto de análisis de código estático y se ha utilizado durante mucho tiempo. El problema es que tiene muchas limitaciones.

1. Por lo general, es específico del idioma. Tratar de desarrollar una solución para todos los códigos de software es demasiado complejo
2. A menudo necesita trabajar en el nivel AST para eliminar nombres de variables, estilo de código, etc. Necesita representaciones abstractas de alto nivel, lo que lo hace lento
3. Puede ser difícil identificar los problemas que no se encuentran en el código. por ejemplo, un agujero de seguridad solo puede existir si hay un conjunto de condiciones previas repartidas en varios archivos o módulos de código
4. A menudo proporciona un gran número de falsos positivos que deben verificarse manualmente.

Habiendo dicho todo esto, hay una serie de herramientas de análisis estático que pueden ayudar a reducir el espacio de búsqueda para posibles agujeros de seguridad. Estos a menudo se centran en un tipo específico de problema de seguridad, como la inyección de SQL o las vulnerabilidades de XSS y generalmente están restringidos a un idioma específico. Muchos de los mejores son muy caros.

El potencial para tal análisis ciertamente ha aumentado debido al crecimiento en los repositorios disponibles, como github. Definir exactamente el alcance a utilizar también puede significar que tales enfoques pueden ser beneficiosos. Este es especialmente el caso debido al crecimiento en el uso de bibliotecas y marcos de código abierto. Por ejemplo, si conoce una vulnerabilidad en una biblioteca o un marco popular, no es demasiado difícil identificar el código que utiliza esos marcos o bibliotecas como posibles candidatos para una búsqueda más intensiva. Del mismo modo, el crecimiento en el uso de la programación del estilo 'cortar y pegar' puede tener cierto potencial. Si encuentra un ejemplo popular de cómo implementar algún patrón / algoritmo que tenga un defecto, puede encontrar ese patrón en los repositorios públicos. etc.

Este tipo de análisis estático no automatizará el proceso, pero sin duda podría ayudar a reducir el espacio de búsqueda de código con problemas de seguridad. Sin embargo, al final del día, normalmente se requerirá que alguien tome los resultados y realice un análisis e inspección manual.