Seguí muchos tutoriales sobre la explotación de vulnerabilidades UAF, pero nunca se explicó cómo encontrar y detectar vulnerabilidades UAF en JavaScript o HTML (es decir, con un análisis estático).
Mi pregunta es: ¿cómo aplicar ingeniería inversa a las funciones de JavaScript para ver si un objeto fue liberado, mediante esta función, y con qué función puedo usarlo nuevamente (después de que fue liberado) para provocar un uso después de la edición gratuita?
Aunque JavaScript y HTML como lenguajes no tienen uso después de liberarse por diseño (debido a la falta de acceso a memoria de bajo nivel), todavía pueden usarse para explotar UAF en los motores que interpretan y ejecutan JavaScript / HTML. .
Así es como se encuentran las vulnerabilidades de UAF:
Para comenzar, puedes estudiar informes de errores públicos (por ejemplo, errores de gravedad media / alta / crítica de Chrome ( pautas de gravedad ), ( pautas de gravedad ), cualquier CVE). JavaScript es un lenguaje altamente dinámico, a veces puede hacer cosas que los diseñadores / implementadores de una determinada característica no pretendieron o esperaron, lo que generó vulnerabilidades de seguridad (por ejemplo, un serializador JSON que no tuvo en cuenta el hecho de que las devoluciones de llamada personalizadas pueden modificar la entrada ). La mayoría de los errores no están en el motor de JavaScript en sí, sino en la implementación de las API disponibles (por ejemplo, DOM no es parte de JavaScript).
Si está disponible, use AddressSanitizer porque facilita la detección y clasificación del tipo de error de memoria. Puede compilarlo desde la fuente o usar los binarios precompilados (ver, por ejemplo, Firefox o Chrome ).
Nota: Encontrar el UAF es el paso más fácil, en realidad explotarlo es mucho más difícil. Los programas modernos utilizan todo tipo de medidas preventivas para contrarrestar las vulnerabilidades (por ejemplo, ASLR , pilas no ejecutables, protectores de pila / pila, < a href="https://wiki.ubuntu.com/Security/Features"> y más ).
Tu pregunta es incorrecta en muchos niveles.
Primero, JavaScript es un lenguaje administrado por memoria. Es decir, un desarrollador nunca libera realmente la memoria. En su lugar, el intérprete de JavaScript gestiona todo eso. Por lo tanto, si el intérprete de JavaScript está escrito correctamente, no puede haber vulnerabilidades de uso después del libre. Como tal, el análisis estático de JavaScript nunca encontrará una vulnerabilidad de uso después del libre.
HTML realmente no tiene un concepto de administración de memoria para siquiera discutir el uso después de liberarse.
En cuanto a las funciones de ingeniería inversa de JavaScript, eso no tiene sentido. JavaScript no está compilado por lo que siempre tienes la fuente disponible. Tal vez el JavaScript fue ofuscado, pero aún tienes el código, es difícil de leer.
Lea otras preguntas en las etiquetas exploit javascript exploit-development use-after-free
 y / o vp; bug_status = NEW & amp. Fuego los errores altos / críticos de buey </a){kind=link}