Fuzzing bibliotecas compartidas

No, o al menos no de una manera que proporcione información útil.

El problema está en el paso 2, "determinar la firma de la función". La gran mayoría de las bibliotecas compartidas están escritas en C, o están escritas en otros idiomas, pero aún utilizan la convención de llamadas cdecl . En tal caso, la firma de la función no contiene información sobre los tipos o incluso el número de parámetros; ni el tipo ni el número están fijos (considere printf() ). Puede intentar deducirlo mediante análisis estático, pero los recuentos de argumentos variables, el tipo de letra y los programadores de lenguaje ensamblador demasiado inteligentes tenderán a frustrar el análisis.

Ciertamente, podría bloquear una función de biblioteca colocando datos aleatorios en la pila y luego llamando a la función, pero esto generalmente no le dará información útil sobre vulnerabilidades: los datos aleatorios casi nunca corresponderán a una situación que podría ser establecido en el uso del mundo real. Terminará deduciendo cosas como "si paso dos punteros aleatorios a strcpy() , se bloquea", o "Si no paso suficientes parámetros a printf() , se bloquea".

El LibFuzzer de LLVM puede ser útil. Es un conjunto de herramientas para ayudar con la eliminación de las bibliotecas en el proceso.

No resuelve el problema de identificar automáticamente las firmas de función de cada función exportada e inyectar datos aleatorios del tipo apropiado a cada una. En su lugar, espera que escriba un pequeño arnés de prueba que invoque la función exportada con datos del tipo apropiado, de modo que tenga que hacer la parte manualmente. Sin embargo, si hace esa parte manualmente, automatiza el resto del trabajo de fuzzing, utilizando técnicas similares a American Fuzzy Lop (la AFL fuzzer ).