Resumen
Microsoft es consciente de una nueva clase de vulnerabilidades publicadas que se conocen como "ataques de canal lateral de ejecución especulativa". Estas vulnerabilidades afectan a muchos procesadores y sistemas operativos modernos. Esto incluye conjuntos de chips de Intel, AMD y ARM.
Todavía no hemos recibido información que indique que estas vulnerabilidades se han usado para atacar a los clientes. Seguimos trabajando estrechamente con los partners del sector para proteger a los clientes. Esto incluye fabricantes de chips, OEM de hardware y proveedores de aplicaciones. Para obtener toda la protección disponible, se requieren actualizaciones de hardware o firmware y software. Esto incluye microcódigo de los OEM del dispositivo y, en algunos casos, actualizaciones del software antivirus. Hemos lanzado varias actualizaciones para ayudar a mitigar estas vulnerabilidades. Puede encontrar más información sobre las vulnerabilidades en el Aviso de seguridad de Microsoft ADV180002. Para obtener instrucciones generales, consulte también instrucciones para mitigar vulnerabilidades de canal lateral de ejecución especulativa. También hemos tomado medidas para ayudar a proteger nuestros servicios en la nube. Para obtener más detalles, consulte las secciones siguientes:
Versiones afectadas de Exchange Server
Debido a que se trata de ataques a nivel de hardware dirigidos a sistemas de procesadores basados en x64 y x86, todas las versiones compatibles de Microsoft Exchange Server se ven afectadas por este problema.
Recomendaciones
En la tabla siguiente se describen las acciones recomendadas para los clientes de Exchange Server. Actualmente, no se requieren actualizaciones específicas de Exchange. No obstante, recomendamos que los clientes ejecuten siempre la actualización acumulativa de Exchange Server más reciente y todas las actualizaciones de seguridad necesarias. Recomendamos que implementes correcciones mediante los procedimientos habituales para validar nuevos archivos binarios antes de implementarlos en entornos de producción.
| Escenario | Descripción | Recomendaciones |
|---|---|---|
| 1 | Exchange Server se ejecuta en equipos sin sistema operativo (sin máquinas virtuales) y ninguna otra lógica de aplicación que no sea de confianza (capa de aplicación) se ejecuta en la misma máquina sin sistema operativo. | Aplique todas las actualizaciones del sistema y de Exchange Server después de las pruebas de validación habituales previas a la producción. No es necesario habilitar la vigilancia de direcciones virtuales del kernel (KVAS) (consulte la sección relacionada más adelante en este artículo). |
| 2 | Exchange Server se ejecuta en una máquina virtual en un entorno de hospedaje público (nube). | Para Azure: Microsoft ha publicado detalles sobre los esfuerzos de mitigación para Azure (consulte KB 4073235 para obtener información detallada). Para otros proveedores de nube: consulte sus instrucciones. Se recomienda instalar todas las actualizaciones del sistema operativo en la máquina virtual invitada (VM). Consulte las instrucciones más adelante en este artículo sobre si habilitar KVAS. |
| 3 | Exchange Server se ejecuta en una máquina virtual en un entorno de hospedaje privado. | Consulte la documentación de seguridad del hipervisor para conocer las prácticas recomendadas de seguridad. Consulte KB 4072698 para obtener Windows Server e Hyper-V. Se recomienda instalar todas las actualizaciones del sistema operativo en la máquina virtual invitada. Consulte las instrucciones posteriores de este artículo sobre si habilitar KVAS. |
| 4 | Exchange Server se ejecuta en una máquina física o virtual y no está aislado de otra lógica de aplicación que se ejecuta en el mismo sistema. |
Recomendamos instalar todas las actualizaciones del sistema operativo. Se recomienda que los clientes implementen la actualización de producto más reciente disponible y las actualizaciones de seguridad asociadas. Consulte las instrucciones más adelante en este artículo sobre si habilitar KVAS. |
Asesoramiento de rendimiento
Recomendamos a todos los clientes que evalúen el rendimiento de su entorno específico al aplicar las actualizaciones.
Las soluciones proporcionadas por Microsoft para los tipos de vulnerabilidades que se describen aquí usarán mecanismos basados en software para proteger contra el acceso cruzado de procesos a los datos. Recomendamos a todos los clientes que instalen versiones actualizadas de Exchange Server y Windows. Esto debería tener un impacto mínimo en el rendimiento, según las pruebas realizadas por Microsoft en cargas de trabajo de Exchange.
Hemos medido el efecto de la vigilancia de direcciones virtuales del kernel (KVAS) en varias cargas de trabajo. Hemos observado que algunas cargas de trabajo experimentan una disminución significativa en el rendimiento. Exchange Server es una de esas cargas de trabajo que pueden experimentar una disminución significativa si KVAS está habilitado. Se espera que los servidores que muestran un uso elevado de la CPU o patrones de E/S muestren el mayor efecto. Recomendamos encarecidamente que primero evalúe el impacto en el rendimiento de habilitar KVAS ejecutando pruebas en un laboratorio que represente sus necesidades de producción antes de implementar en un entorno de producción. Si el impacto en el rendimiento de habilitar KVAS es demasiado alto, considere si aislar Exchange Server de código que no es de confianza que se ejecuta en el mismo sistema es una mejor mitigación para la aplicación.
Además de KVAS, aquí se detalla la información sobre el impacto en el rendimiento del soporte de hardware (IBC) de mitigación de destino de bifurcación. Un servidor que ejecute Exchange Server y que tenga implementada una solución IBC puede experimentar una disminución significativa en el rendimiento si IBC está habilitado.
Anticipamos que los proveedores de hardware ofrecerán actualizaciones a sus productos en forma de actualizaciones de microcódigo. Nuestra experiencia con Exchange indica que las actualizaciones del microcódigo aumentarán la caída del rendimiento. La medida en que esto ocurre depende en gran medida de los componentes y el diseño del sistema en el que se aplican. Creemos que ninguna solución, ya sea basada en software o hardware, es suficiente para abordar este tipo de vulnerabilidad por sí sola. Le animamos a evaluar el rendimiento de todas las actualizaciones para tener en cuenta la variabilidad en el diseño y el rendimiento del sistema antes de ponerlas en producción. El equipo de Exchange no tiene previsto actualizar la calculadora de tamaño que usan los clientes para tener en cuenta las diferencias de rendimiento actuales. Los cálculos proporcionados por esta herramienta no tendrán en cuenta los cambios en el rendimiento relacionados con las correcciones de estos problemas. Continuaremos evaluando esta herramienta y los ajustes que creemos que pueden ser necesarios, en función de nuestro propio uso y el de los clientes.
Actualizaremos esta sección a medida que haya más información disponible.
Habilitar la vigilancia de direcciones virtuales del kernel
Exchange Server se ejecuta en muchos entornos, incluidos sistemas físicos, máquinas virtuales en entornos de nube pública y privada y sistemas operativos Windows. Independientemente del entorno, el programa se encuentra en un sistema físico o en una máquina virtual. Este entorno, ya sea físico o virtual, se conoce como límite de seguridad.
Si todo el código dentro del límite tiene acceso a todos los datos dentro de ese límite, no es necesario realizar ninguna acción. Si no es así, se dice que el límite es multiinquilino. Las vulnerabilidades que se han encontrado hacen posible que cualquier código que se ejecute en cualquier proceso dentro de ese límite lea cualquier otro dato dentro de ese límite. Esto es así incluso con permisos reducidos. Si en algún proceso del límite se ejecuta código que no es de confianza , podría aprovechar estas vulnerabilidades para leer datos de otros procesos.
Para protegerse contra código que no es de confianza en un límite de varios inquilinos, siga uno de estos procedimientos:
- Quite el código que no es de confianza.
- Active KVAS para protegerse frente a lecturas de proceso a proceso. Esto tendrá un efecto en el rendimiento. Consulte las secciones anteriores de este artículo para obtener información detallada.
Para obtener más información sobre cómo habilitar KVAS para Windows, consulte KB 4072698.
Escenarios de ejemplo (KVAS se recomienda encarecidamente)
Escenario 1
Una máquina virtual de Azure ejecuta un servicio en el que los usuarios que no son de confianza pueden enviar código JavaScript que se ejecuta con permisos limitados. En la misma máquina virtual, Exchange Server se ejecuta y administra datos que no deberían ser accesibles para esos usuarios que no son de confianza. En esta situación, KVAS debe protegerse contra la divulgación entre las dos entidades.
Escenario 2
Un sistema físico local que hospeda Exchange Server puede ejecutar scripts o ejecutables de terceros que no sean de confianza. Es necesario habilitar KVAS para proteger contra la divulgación de datos de Exchange al script o ejecutable.
Nota El hecho de que se utilice un mecanismo de extensibilidad en Exchange Server no lo convierte automáticamente en inseguro. Estos mecanismos se pueden utilizar de forma segura dentro de Exchange Server siempre que cada dependencia se comprenda y sea de confianza. Además, hay otros productos compilados en Exchange Server que pueden requerir mecanismos de extensibilidad para funcionar correctamente. En su lugar, como primera acción, revise cada uso para determinar si el código se entiende y es de confianza. Esta guía se proporciona para ayudar a los clientes a determinar si tienen que habilitar KVAS debido a mayores implicaciones de rendimiento.
Habilitación del soporte de hardware de mitigación de inserción de destino de bifurcación (IBC)
IBC mitiga contra CVE 2017-5715, también conocido como la mitad de Spectre o "variante 2" en la divulgación de GPZ.
Estas instrucciones para habilitar KVAS en Windows también pueden habilitar IBC. Sin embargo, IBC también requiere una actualización de firmware del fabricante del hardware. Además de las instrucciones de KB 4072698 para habilitar la protección en Windows, los clientes tienen que obtener e instalar actualizaciones de su fabricante de hardware.
Escenario de ejemplo (se recomienda encarecidamente IBC)
Escenario 1
En un sistema físico local que hospeda Exchange Server, los usuarios que no son de confianza pueden cargar y ejecutar código JavaScript arbitrario. En este escenario, recomendamos encarecidamente a IBC que proteja frente a la divulgación de información de proceso a proceso.
En situaciones en las que no existe soporte de hardware IBC, se recomienda separar los procesos que no son de confianza y los procesos de confianza en máquinas físicas o virtuales diferentes.
Mecanismos de extensibilidad de Exchange Server que no son de confianza
Exchange Server incluye características y mecanismos de extensibilidad. Muchas de ellas se basan en API que no permiten ejecutar código no fiable en el servidor que ejecuta Exchange Server. Los agentes de transporte y el Shell de administración de Exchange podrían permitir que se ejecute código no fiable en un servidor que ejecuta Exchange Server en determinadas situaciones. En todos los casos, excepto en el caso de los agentes de transporte, las características de extensibilidad requieren autenticación antes de poder usarse. Se recomienda usar características de extensibilidad que estén restringidas al conjunto mínimo de archivos binarios, siempre que sea aplicable. También recomendamos que los clientes restrinjan el acceso al servidor para evitar que se ejecute un código arbitrario en los mismos sistemas que Exchange Server. Le recomendamos que determine si desea confiar en cada binario. Debe deshabilitar o quitar los archivos binarios que no sean de confianza. También debe asegurarse de que las interfaces de administración no estén expuestas en Internet.
Declinación de responsabilidades de terceros
Todos los productos de terceros que se tratan en este artículo son fabricados por empresas independientes de Microsoft. Microsoft no ofrece ninguna garantía, implícita ni de ningún otro tipo, con respecto al rendimiento o la confiabilidad de estos productos.