¿Por qué no se pueden reparar las vulnerabilidades de shellcode de Javascript mediante la "prevención de ejecución de datos"?

los"pulverización en pilas" El artículo de wikipedia sugiere que muchas vulnerabilidades de JavaScript implican colocar un código shell en algún lugar del código ejecutable del script o la memoria del espacio de datos y luego hacer que el intérprete salte allí y lo ejecute. Lo que no entiendo es, ¿por qué no se puede marcar todo el montón del intérprete como "datos" para que DEP no pueda ejecutar el intérprete? Mientras tanto, la ejecución del código de bytes derivado de javascript sería realizada por una máquina virtual que no le permitiría modificar la memoria perteneciente al intérprete (esto no funcionaría en V8 que parece ejecutar código de máquina, pero probablemente funcionaría en Firefox que usa algún tipo de bytecode).

Supongo que lo anterior suena trivial y, de hecho, probablemente se está haciendo algo así. Entonces, estoy tratando de entender dónde está la falla en el razonamiento, o la falla en las implementaciones de intérpretes existentes. P.ej. ¿confía el intérprete en la asignación de memoria del sistema en lugar de implementar su propia asignación interna cuando JavaScript solicita memoria, por lo tanto, hace que sea demasiado difícil separar la memoria que pertenece al intérprete y a JavaScript? ¿O por qué los métodos basados en DEP no pueden eliminar completamente los códigos de shell?

Respuestas a la pregunta(1)

Su respuesta a la pregunta