¿Se conocen fallas en el aislamiento del dominio de aplicación de .NET?

Question

¿Se conocen fallas en el aislamiento del dominio de aplicación de .NET?

#1 de Polynomial (4 votos)

3

.NET AppDomains proporciona varios niveles de aislamiento para código no confiable o parcialmente confiable. El sandbox de AppDomain se implementa ampliamente en ASP.NET y Silverlight, aunque solo este último está diseñado para aislar el código completamente no confiable del resto del sistema operativo.

¿Se han producido escapes conocidos de los entornos de pruebas basados en dominio de aplicación? No he podido encontrar ningún aviso de seguridad relacionado con esto en una búsqueda rápida. Por supuesto, esto no significa que la caja de arena sea segura; Simplemente podría ser poco utilizado. Pero es un comienzo.

Lo pregunto porque la documentación de MSDN sobre si se debe confiar en el sandbox es contradictoria. Hay esta página que dice "desaconsejamos cargar y ejecutar código de origen desconocido sin implementar medidas de seguridad alternativas ". Y luego está este artículo cuyo título completo es "Cómo alojar de forma segura un complemento no confiable Ins ".

.net sandbox

pregunta RomanSt 28.04.2015 - 00:41

fuente

1 respuesta

Lea otras preguntas en las etiquetas .net sandbox

¿Debo crear un par de claves por cliente como proveedor de servicios en SAML? VeraCrypt seguro en público?

score 4 · Accepted Answer

Sí, hay muchos ejemplos.

MS14 -072 es uno de los más directos. Un atacante podría secuestrar una llamada remota para elevar los privilegios a otros AppDomains que se ejecutan dentro del mismo contexto de ejecución. Casi todos los errores de ejecución directa de código funcionan también como ejemplos, ya que una vez que se escapa del entorno de tipo seguro, puede realizar llamadas API directas al sistema que violan todas las garantías de seguridad.

También hay errores de nivel de aplicación que pueden violar las restricciones de dominio de aplicación. Por ejemplo, un error de escritura de archivo arbitrario podría hacer que un dominio de aplicación secundario cargue una DLL u otro objeto ejecutable, lo que podría comprometer ambas partes de la aplicación.

En lo que respecta al alojamiento de código no confiable, tenga en cuenta que el último artículo que vinculó es muy antiguo. En general, ahora se considera inseguro alojar cualquier tipo de código no confiable. La seguridad de acceso al código (CAS) ha quedado obsoleta en .NET debido a su ineficacia y dificultad de implementación. Microsoft proporciona consejos en caso de que absolutamente necesite hospedar código que no sea de confianza, pero generalmente esto se enfoca más en el uso de bibliotecas de terceros de código cerrado para las que no tiene métricas de seguridad, en lugar de "cargue un archivo ejecutable .NET y lo correré ".