Resumen
Microsoft es consciente de una nueva clase de vulnerabilidades publicadas que se conocen como “ataques de ejecución especulativa de canal lateral” que afectan a muchos procesadores y sistemas operativos modernos. Entre ellos se incluyen los conjuntos de chips de Intel, AMD y ARM.
Todavía no hemos recibido información que indique que estas vulnerabilidades se hayan usado para atacar a los clientes. Continuamos trabajando estrechamente con nuestros asociados del sector para proteger a los clientes. Entre ellos se incluyen los 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 de 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. Encontrará más información acerca de las vulnerabilidades en Aviso de seguridad ADV180002 de Microsoft: Para una guía general, vea también Instrucciones para mitigar vulnerabilidades frente a ataques de ejecución especulativa de canal lateral. También hemos tomado medidas para ayudar a proteger nuestros servicios en la nube. Para obtener más información al respecto, consulte las secciones siguientes.
Versiones de Exchange Server afectadas
Puesto que se trata de ataques de nivel de hardware cuyo objetivo son los sistemas de procesadores basados en x64 y en 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. No existen actualizaciones específicas necesarias para Exchange actualmente. Sin embargo, recomendamos que los clientes ejecuten siempre la actualización acumulativa de Exchange Server más reciente y cualquier actualización de seguridad necesaria. Recomendamos implementar las correcciones mediante los procedimientos habituales para validar los archivos binarios nuevos antes de implementarlos en entornos de producción.
|
Escenario |
Descripción |
Recomendaciones |
|
1 |
Exchange Server se ejecuta sin sistema operativo (sin máquinas virtuales) y ninguna otra lógica de aplicación no sea de confianza (capa de aplicación) se ejecuta en la misma máquina virtual.
|
Aplique todas las actualizaciones del sistema y de Exchange Server después de las pruebas habituales de validación de preproducción. No se requiere la habilitación de la sesión concurrente de dirección virtual de kernel (KVAS) (vea 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 los detalles sobre los esfuerzos de mitigación para Azure (vea KB 4073235 para obtener información detallada). Para otros proveedores de nube: vea sus instrucciones. Consulte las instrucciones más adelante en este artículo sobre si se debe 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 obtener los procedimientos recomendados de seguridad. Vea KB 4072698 para Windows Server e Hyper-V. Consulte las instrucciones más adelante en este artículo sobre si se debe 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 la instalación de todas las actualizaciones del sistema operativo. Consulte las instrucciones más adelante en este artículo sobre si se debe habilitar KVAS. |
Aviso de rendimiento
Aconsejamos a todos los clientes evaluar el rendimiento del entorno específico al aplicar las actualizaciones.
Las soluciones proporcionadas por Microsoft para los tipos de vulnerabilidades que se explican aquí usarán mecanismos basados en software para la protección contra el acceso a datos de procesos cruzados. Aconsejamos a todos los clientes instalar versiones actualizadas de Exchange Server y Windows. Esto debería tener un efecto mínimo sobre el rendimiento, según las pruebas que Microsoft ha efectuado de cargas de trabajo de Exchange.
Hemos medido el efecto de la sesión concurrente de dirección virtual de kernel (KVAS) en varias cargas de trabajo. Hemos observado que algunas cargas de trabajo experimentan un descenso significativo del rendimiento. Exchange Server es una de estas cargas de trabajo que pueden experimentar un descenso significativo si se habilita KVAS. Se espera que en los servidores que presentan patrones de uso elevado de CPU o de uso elevado de E/S el efecto sea más grande. Recomendamos encarecidamente que primero evalúe el efecto que la habilitación de KVAS tiene en el rendimiento, ejecutando pruebas en un laboratorio que represente las necesidades de producción, antes de la implementación en un entorno de producción. En caso de que el efecto sobre el rendimiento al habilitar KVAS sea demasiado elevado, valore si aislar Exchange Server del código que no es de confianza y que se ejecuta en el mismo sistema mitiga mejor el problema en la aplicación.
Además de KVA, encontrará información sobre el efecto en el rendimiento de la compatibilidad del hardware de mitigación de la inserción de destino de bifurcación (IBC) aquí. Un servidor que ejecuta Exchange Server y que tiene implementada una solución IBC, puede experimentar un descenso significativo del rendimiento si IBC se habilita.
Prevemos que los proveedores de hardware ofrecerán actualizaciones para sus productos en forma de actualizaciones de microcódigo. Nuestra experiencia con Exchange indica que las actualizaciones de microcódigo aumentarán la caída del rendimiento. Su alcance dependerá en gran medida de los componentes y el diseño del sistema en el que se apliquen. Creemos que ninguna solución única, ya sea basada en software o en hardware, será suficiente para solucionar sola este tipo de vulnerabilidad. Animamos a evaluar el rendimiento de todas las actualizaciones para considerar la variabilidad del diseño y el rendimiento del sistema antes de colocarlas en producción. El equipo de Exchange no tiene previsto actualizar la calculadora de tamaño que los clientes usan actualmente para considerar las diferencias. Los cálculos proporcionados por esta herramienta no tomarán en consideración los cambios de rendimiento que estén relacionados con las correcciones de estos problemas. Continuaremos con la evaluación de esta herramienta y los ajustes que creemos que pueden requerir, en función de nuestro propio uso y el de los clientes.
Actualizaremos esta sección a medida que haya disponible más información.
Activación de la sesión concurrente de dirección virtual de kernel
Exchange Server se ejecuta en muchos entornos, incluidos sistemas físicos, máquinas virtuales en entornos de nube públicos y privados y sistemas operativos Windows. Independientemente del entorno, el programa está ubicado en un sistema físico o una máquina virtual. Este entorno, físico o virtual, se conoce como límite de seguridad.
Si todo el código que hay en el límite tiene acceso a todos los datos que hay en este, no se requiere ninguna acción. Si no es el caso, se dice que el límite es multiempresa.Las vulnerabilidades que se han encontrado permiten que el código que se ejecute en cualquier proceso dentro de ese límite pueda leer todos los demás datos que se encuentren en dicho límite. Es cierto incluso con permisos reducidos. Si algún proceso en ese límite ejecuta código que no es de confianza, puede usar estas vulnerabilidades para leer datos de otros procesos.
Para protegerse contra el código que no es de confianza en un límite multiempresa, siga uno de estos pasos:
-
Elimine el código que no es de confianza.
-
Active KVAS para la protección contra lecturas de proceso a proceso. Esto afectará al rendimiento. Vea las secciones anteriores de este artículo para información detallada.
Para obtener más información sobre cómo habilitar KVAS en Windows, vea KB 4072698.
Escenarios de ejemplo (se recomienda KVAS encarecidamente)
Escenario 1
Una máquina virtual de Azure ejecuta un servicio en el que usuarios que no son de confianza pueden enviar código JavaScript que se ejecuta con permisos limitados. En la misma máquina virtual, se ejecuta Exchange Server y se gestionan datos que no son accesibles para los usuarios que no son de confianza. En esta situación, se requiere KVAS como protección contra la divulgación entre las dos entidades.
Escenario 2
Un sistema físico local que hospeda Exchange Server puede ejecutar scripts o ejecutables no de confianza de terceros. Es necesario habilitar KVAS como protección contra la divulgación de datos de Exchange al script o ejecutable.
Nota El uso de un mecanismo de extensibilidad en Exchange Server no implica automáticamente que aquel no sea seguro. Estos mecanismos se pueden usar de forma segura en Exchange Server siempre que se comprendan todas las dependencias y se confíe en ellas. Además, existen otros productos creados sobre Exchange Server que pueden requerir mecanismos de extensibilidad para funcionar correctamente. En su lugar, como primera acción, revise los usos para determinar si se comprende el código y se confía en él. Estas instrucciones se proporcionan para ayudar a los clientes a determinar si es necesario habilitar KVAS, ya que esto tiene implicaciones de mayor alcance sobre el rendimiento.
Habilitar la compatibilidad del hardware de mitigación de la inserción de destino de bifurcación (IBC)
IBC mitiga CVE 2017-5715, también conocido como una mitad de Spectre o “variante 2” en la divulgación de GPZ.
Estas instrucciones para habilitar KVAS en Windows también pueden habilitar IBC. No obstante, IBC también necesita una actualización de firmware del fabricante del hardware. Además de las instrucciones contenidas en KB 4072698 para habilitar la protección en Windows, los clientes tienen que obtener las actualizaciones del fabricante del hardware e instalarlas.
Escenario de ejemplo (se recomienda IBC encarecidamente)
Escenario 1
En un sistema físico local que hospeda Exchange Server, se permite que usuarios no de confianza carguen y ejecuten código JavaScript arbitrariamente. En este escenario, recomendamos encarecidamente IBC como protección contra la divulgación de información proceso a proceso.
En situaciones en las que no existe compatibilidad del hardware para IBC, recomendamos separar los procesos que no son de confianza de los que sí lo son y colocarlos en distintas máquinas físicas o virtuales.
Mecanismos de extensibilidad de Exchange Server que no son de confianza
Exchange Server incluye funciones y mecanismos de extensibilidad Muchas de ellas se basan en API que no permiten ejecutar código que no sea de confianza en el servidor que ejecuta Exchange Server. Los agentes de transporte y el Shell de administración de Exchange pueden permitir que se ejecute código que no es de confianza en un servidor que ejecuta Exchange Server en determinadas situaciones. En todos los casos, excepto en los agentes de transporte, se requiere la autenticación antes de poder usar las funciones de extensibilidad. Recomendamos usar funciones de extensibilidad que se restrinjan al conjunto de archivos binarios mínimo siempre que se pueda. También recomendamos que los clientes restrinjan el acceso al servidor para evitar la ejecución arbitraria de código en los mismos sistemas que Exchange Server. Aconsejamos determinar si cada uno de los archivos binarios es de confianza. Debe deshabilitar o quitar los archivos binarios que no sean de confianza. También debe asegurarse de que las interfaces de administración no se expongan en Internet.
Los productos de terceros que analiza este artículo los fabrican compañías independientes de Microsoft. Microsoft no ofrece ninguna garantía, ya sea implícita o de otro tipo, sobre la confiabilidad o el rendimiento de dichos productos.
