Primero, una pequeña aclaración: los aerosoles de pila clásicos nunca se necesitaron para llenar la dirección virtual completa de todos modos. Solo necesitaban llenar suficiente memoria para cubrir el rango de incertidumbre que tiene para la dirección de si el código de shell será. Por lo tanto, 100 MB o menos fueron suficientes.
La imagen cambió mucho con la llegada de DEP, porque ya no se puede aplicar Shellcode; ahora uno debe rociar una pila de ROP (por ejemplo). Podría pensar que ASLR también hizo que la fumigación con pilas fuera más difícil, pero VirtualAlloc asigna en direcciones deterministas incluso si ASLR está habilitado (tal vez todavía lo esté), lo que hizo que la predicción de la dirección sea mucho más fácil. Finalmente, el espacio de direcciones de 64 bits aumentó la cantidad de variabilidad disponible para ASLR, lo que tiene el potencial de realizar algunos ataques de "heap spray" harder .
El cambio más grande se encuentra en Windows 8, que hizo dos cambios importantes que probablemente harán que los sprays más difíciles sean más difíciles. Primero, HiASLR permite una mayor entropía para ASLR. En plataformas de 64 bits, HiASLR presenta un rango de posibilidades de 1TB para la base del montón. Esto hace que sea más difícil predecir la dirección de algo en el montón. En segundo lugar, Windows 8 hace que las asignaciones no sean deterministas: cuando asigna un objeto utilizando el asignador predeterminado, la posición que se usa es aleatoria (ya no es determinista), introduciendo la aleatorización de grano fino en el nivel del objeto individual. La aleatorización objeto por objeto no se usa para todo (solo para el asignador LFH, que creo que solo se usa para objetos de pila que tienen un tamaño máximo de 16 KB), pero agregará un desafío adicional.
Dicho esto, la fumigación con pilas puede ser posible en algunos casos. La situación en la que la pulverización de pilas se vuelve útil es cuando tenemos un conocimiento parcial de un valor de puntero (o cuando algún objeto estará en la memoria), pero no un conocimiento exacto. En esa situación, un montón de rociado puede ser una técnica útil para hacer que el exploit sea confiable a pesar de la falta de previsibilidad perfecta en esa dirección.
Por ejemplo, un ejemplo es La vulnerabilidad de Ivan Fratric de 64 bits IE11 , donde usó un aerosol para hacer que el exploit fuera confiable. En esa vulnerabilidad, el atacante podría activar una escritura en la dirección A + 256MB, donde A es la dirección de algún objeto de pila. Debido a ASLR, no podemos predecir el valor de A , y debido al montón de 64 bits, no podemos rociar lo suficiente para llenar todo el montón, pero Ivan se dio cuenta de que en este caso es suficiente para Rocíe alrededor de 256 MB de datos en el montón. Esto hace probable que la dirección de un objeto de montón aleatorio, más 256 MB, aterrice en la región rociada.
Entonces, como explica Ivan Frartic, la fumigación con pilas puede ser útil para el atacante si "podemos hacer que una memoria de eliminación de referencias de aplicaciones vulnerables en una dirección de pila válida + un gran desplazamiento" (por ejemplo, imagine el código con errores do_something_with(a[i]) , donde i podría ser un desplazamiento que apunta más allá del final de la matriz). Da otro ejemplo de una vulnerabilidad anterior que también tenía este formulario, para ilustrar que este caso es bastante común.
Finalmente, se pueden usar procesos de 32 bits en los casos que no esperaría. Por ejemplo, incluso el IE de 64 bits en plataformas de 64 bits utilizará procesos secundarios de 32 bits para cada nueva pestaña , en Windows 8.1. ¿Quién sabía?
Conclusión: no, no podemos decir que no hay que preocuparse por los sprays de pila contra procesos de 64 bits. Eso fue de hecho demasiado ingenuo.