Han estado apareciendo errores Xen, lo que hace temer por la seguridad del software de virtualización de código abierto. Conozca por qué el código abierto no es culpable de las trampas de seguridad.
El Proyecto Xen ha reportado múltiples errores de escape huésped/anfitrión durante el año pasado, lo que ha conducido a preocupaciones crecientes sobre la seguridad del hipervisor. ¿Hay algo que se pueda hacer para protegerse contra estos riesgos hasta que se libere un parche? ¿Se debería evitar el software de virtualización de código?
Cada vez que una importante vulnerabilidad se encuentra en cualquier software, las empresas deben evaluar el impacto potencial en sus sistemas. Por ejemplo, una vulnerabilidad de desbordamiento de montículo (heap overflow) en Xen puede permitir que un huésped privilegiado, en un sistema operativo invitado, obtenga privilegios de administrador cuando se habilita un CD-ROM IDE emulado. Si ninguno de sus sistemas operativos invitados tiene permitidos los controladores de CD-ROM virtual, entonces esta vulnerabilidad no afecta a su organización.
Mientras se espera un parche, puede optar por ejecutar sus servidores virtualizados en máquinas dedicadas. AWS ofrece una opción para utilizar hardware dedicado al iniciar una instancia. Tendrá que pagar más, pero sus máquinas virtuales solo van a compartir hosts con otras VM que se ejecutan desde su cuenta.
La pregunta acerca de evitar el software de virtualización de código abierto parece dar a entender que la probabilidad de una vulnerabilidad existente en el software es una función del modelo bajo el cual se distribuye. No he visto ninguna evidencia para indicar que este es el caso; las vulnerabilidades se meten tanto en código abierto, como en sistemas propietarios por muchas razones. A veces, por ejemplo, los programadores cometen errores, como no revisar los límites de las referencias de matriz al utilizar lenguajes que no proporcionan comprobaciones de límites.
Este tipo de riesgo puede ser mitigado realizando revisiones de código, empleando herramientas de análisis estático, y usando lenguajes de memoria segura que eviten las operaciones de puntero potencialmente inseguras. En este caso, las opciones de diseño y las prácticas de ingeniería de software tienen más que ver con la probabilidad de una vulnerabilidad que la cuestión de software de fuente abierta versus comercial.
La complejidad es otro factor que se debe considerar al evaluar las opciones de software de virtualización de código abierto. OpenSSL, por ejemplo, se compone de cientos de miles de líneas de código a través de dos componentes principales para los servicios de TLS y criptografía. El error Heartbleed fue una de las vulnerabilidades más importantes encontradas en cualquier software recientemente, pero no puedo recordar a nadie argumentando que se debía a que OpenSSL era un proyecto de código abierto. Amazon cree que el problema radica más en la evolución de OpenSSL a un nivel de complejidad que no es manejable. Como solución al problema, Amazon lanzó s2n, una alternativa de código abierto a los componentes TLS de OpenSSL que solo requiere varios miles de líneas de código. Reducir la complejidad –aunque a costa de eliminar características en el proceso– es otra manera de reducir el riesgo de vulnerabilidades.
Es posible que desee considerar la cuestión de lo comercial contra el código abierto por razones de negocio legítimas, pero si la seguridad es su principal preocupación, hay muchos otros factores de diseño de aplicaciones y prácticas de ingeniería de software que deben ser considerados primero. software de virtualización
