Tal vez esto pueda responderse con una respuesta a una pregunta más general, como por ejemplo qué programas pueden ser comprobados como seguros .
¿Se puede (o se ha comprobado) formalmente que una caja de arena es segura?
Tal vez esto pueda responderse con una respuesta a una pregunta más general, como por ejemplo qué programas pueden ser comprobados como seguros .
¿Se puede (o se ha comprobado) formalmente que una caja de arena es segura?
El término "caja de arena" es amplio, genérico y, a menudo, se utiliza incorrectamente y se entiende mal.
Consideremos un tipo de espacio aislado, una máquina virtual que se ejecuta bajo el control de un hipervisor . El sistema huésped está aislado nominalmente y no puede "ver" el sistema host. Sin embargo, esto es relativo a la implementación del hipervisor, que es una combinación de software y hardware, los cuales son susceptibles a errores (el hardware siempre está involucrado en que todo el asunto, en última instancia, se ejecuta en una CPU; no estoy hablando de usar o no usar los códigos de operación AMD-V / Intel-VT). Escapó de los hipervisores que han sucedido . "Probar" que el hipervisor es correcto significaría probar que está libre de errores. Probar que el software está libre de errores ha sido un objetivo difícil de alcanzar durante el último medio siglo ... y para el hardware, incluso más.
Por otra parte, los entornos limitados no equivalen a la seguridad . Para que una caja de arena sea útil, debe tener algunas puertas abiertas: ejecuta algún software en la caja de arena, pero querrá ver el resultado, ya sea algo que se muestre, archivos guardados en algún lugar o alguna actividad de la red. Cuando las personas usan un navegador web en un recinto de seguridad, quieren que el navegador diga navegar en la web, por lo que se deben permitir las conexiones de red externas desde el recinto de seguridad; y el navegador de espacio aislado también debe tener la posibilidad de mostrar cosas, por lo que tiene acceso al hardware gráfico (posiblemente un acceso controlado, pero si desea una aceleración 3D, los controles estrictos se vuelven difíciles). Desea una zona de pruebas porque sospecha que el navegador podría ser subvertido y secuestrado por un atacante. Pero, en ese momento, ya perdiste (no toda la guerra, pero aún así se trata de batallas significativas): el navegador subvertido, sandbox o no, es capaz de conectarse en red y puede usarse como retransmisión para atacar otros sitios o enviar spam, aparentemente originario de su dirección.
En palabras más sucintas, la amputación no es el tipo de medicamento más recomendable.
Veamos otro tipo de sandbox, la Java Virtual Machine y su compatibilidad con los applets. Tiene dos facetas principales:
El "código" no es un código binario sin procesar para la CPU local, sino "bytecode": códigos de operación para una máquina abstracta y conceptual, que vive en un mundo sin hardware donde no se permiten aritméticos de punteros genéricos. Las referencias tienen tipos que no se pueden escapar, y los accesos a la matriz se controlan por límites.
Las facilidades de acceso externo para el código del applet están restringidas: las conexiones de red se pueden hacer solo al servidor de origen; los archivos locales no se pueden leer ni escribir en; y así sucesivamente.
Cuando se debe ejecutar el bytecode, primero se analiza : la implementación de JVM realiza un análisis de flujo de control que demuestra formalmente (sí, en el sentido de "seguridad comprobable") que el código cumple. las reglas de tipo para el código de bytes (es decir, que nunca llama a un método en un objeto que no presenta ese método). Esto permite la traducción a código nativo eficiente, sin necesidad de hardware de virtualización especializado. Además, protege contra muchos tipos de subversión (los desbordamientos de búfer se detectan de manera confiable, no hay punteros colgantes ni doble libertad debido a Gestión de memoria basada en GC ...). Este tipo de protección no es suficiente para la "seguridad" porque aún desea los controles de acceso (por ejemplo, el bloqueo de las conexiones externas, excepto al servidor de origen) que aplican las clases del sistema. El análisis del código de bytes está allí para garantizar que solo se usen las clases del sistema y se usen correctamente; el resto depende de las clases del sistema.
Por supuesto, a lo largo de la historia de Java, se ha encontrado que tanto el analizador de bytecode como las implementaciones de clases del sistema tienen fallas. No son intrínsecos: lo que intentan lograr no es matemáticamente imposible. Pero, seamos sinceros: los errores ocurren. La JVM es una pieza de software bastante compleja que está lejos de ser probada como libre de errores. Además, la JVM se ejecuta dentro de un sistema operativo y en algún hardware tangible, ninguno de los cuales está libre de errores tampoco.
Esto ilustra mis puntos:
Supongamos que has probado que tu sandbox es inmune a todos los ataques . Si esta prueba se realizó hace aproximadamente 10 años, no habría tenido en cuenta el puntero colgante y padding oracle ataca porque estos métodos de explotación eran desconocidos en ese momento. Por lo tanto, no podría haber probado que esta caja de arena era totalmente segura, ya que sería una contradicción - > < -
Su pregunta parece indicar un malentendido de lo que es la seguridad. La seguridad probada es un oxímoron. Nada puede ser completamente seguro, o como dice el viejo chiste de seguridad de TI, el único almacenamiento comprobable es escribir en dev / null (es decir, destrucción). La seguridad es simplemente un juego de recursos y costos. Intenta equilibrar la necesidad de que los usuarios legítimos obtengan información mientras previenen que los atacantes hagan lo mismo, pero con cualquier acceso permitido, con recursos y tiempo suficientes, siempre será posible o al menos factible romper el sistema y obtener acceso.
Los sistemas autodestructivos son un intento de evitar este problema al limitar la cantidad de acceso que se puede hacer, pero los medios inventivos pueden eludir la mayoría de estos recursos si se les da suficiente esfuerzo y recursos (a veces hasta el nivel de capas realmente disueltas de chips, capa por capa).
La pregunta realmente necesita más aclaración para ser respondida. ¿Quizás quiere decir que se puede probar la protección contra un tipo particular de ataque? Si es así, ¿qué tipo de ataques le preocupan?
Depende de qué tipo de seguridad comprobable hablas (por lo que es imposible y sin sentido). Pero en algoritmos de seguridad, la seguridad demostrable significa que, para romper su algoritmo, alguien necesita romper el cifrado subyacente. Por lo tanto, si consideramos que nuestro cifrado es seguro y escribes una prueba de que solo al romper el cifrado podrás romper tu algoritmo, no significa nada, es solo algo que se puede investigar y publicar nada más. . Y estoy de acuerdo con que los patrones de ataque de Rook están evolucionando, por lo que la prueba por ahora no estará segura dentro de una década.