¿Cuál es el punto de escapar de la caja de arena de un intérprete?

1

Suponiendo que el atacante ya tiene ejecución de código (que es el caso de cada intérprete de escape de un entorno aislado que conozco), ¿no podría usar una función / método (como Runtime.getRuntime (). exec () en Java?) o os.system () en Python) para ejecutar cualquier comando de shell en el contexto del usuario que está ejecutando el intérprete?

¿Cuál es el punto de buscar una vulnerabilidad nativa difícil de encontrar en un programa complejo, a veces de código cerrado, y desarrollar un exploit que tenga que pasar por alto las mitigaciones para lograr el mismo resultado (probablemente con una fiabilidad que no sea del 100%)?

    
pregunta Not Now 02.04.2018 - 06:59
fuente

1 respuesta

2

Considere JavaScript. La mayoría de las páginas web en estos días sirven algunos JS. Su navegador ejecuta este JS, sin ninguna solicitud de usuario u otro permiso (a menos que use una extensión como NoScript), cada vez que carga una página que contiene un script. El motor JS del navegador es extremadamente potente; puede (por ejemplo) emular una computadora Linux x86 completa en ella . También puede definir clases, extraer secuencias de comandos externas, iniciar trabajadores en segundo plano, etc. Sin embargo, esto es, en su mayor parte, seguro de hacer, porque el navegador cajones de arena JavaScript. No puede, sin un escape de la caja de arena , hacer cosas como "modificar los documentos del usuario" o "implementar algo malicioso como ransomware" o "obtener un shell en el sistema operativo que ejecuta el navegador".

Otro ejemplo, relevante para sus ejemplos, es el caja de arena del applet de Java . Los applets de Java rara vez se usan en la actualidad (en parte porque las personas siguieron encontrando escapes de sandbox para ellos, por lo que no fue seguro habilitarlos), pero durante un tiempo fueron muy populares porque te permitieron hacer cosas mucho más avanzadas y algo más rápidas. que los motores JS de la época (y te permiten escribir código en Java, que incluso entonces era mucho más maduro que JS). Los applets están hechos de bytecode Java y se ejecutan utilizando la JVM, al igual que cualquier otra aplicación Java. La diferencia es que están en espacio aislado , de modo que solo pueden hacer cosas consideradas seguras para una página web. Por ejemplo:

  

• No pueden acceder a los recursos del cliente, como el sistema de archivos local, los archivos ejecutables, el portapapeles del sistema y las impresoras.

     

• No pueden conectarse ni recuperar recursos de ningún servidor de terceros (cualquier servidor que no sea el servidor desde el que se originó).

Estas protecciones significan que el código que se ejecuta en un applet no puede simplemente invocar Runtime.getRuntime().exec() ; Aunque esa clase y funciones existen en la JVM, y se pueden llamar desde aplicaciones Java normales, intentar llamarlas desde un applet de espacio aislado a través de algún tipo de SecurityException . Si desea hacerlo sin obtener una excepción (por ejemplo, para ejecutar algún malware), debe escapar de la zona de pruebas.

    
respondido por el CBHacking 02.04.2018 - 08:54
fuente

Lea otras preguntas en las etiquetas