Boletín de seguridad

Boletín de seguridad de Microsoft MS02-037 - Moderado

La respuesta del servidor al comando EHLO del cliente SMTP da como resultado la saturación del búfer (Q326322)

Publicado: 24 de julio de 2002 | Actualizado: 25 de julio de 2002

Versión: 1.1

Publicado originalmente: 24 de julio de 2002

Resumen

Quién debe leer este boletín: Administradores del sistema que usan Microsoft® Exchange Server 5.5.

Impacto de la vulnerabilidad: capacidad de ejecutar código arbitrario

Clasificación de gravedad máxima: Moderado

Recomendación: Los administradores del sistema deben considerar la posibilidad de aplicar la revisión.

Software afectado:

  • Microsoft Exchange Server 5.5

Información general

Detalles técnicos

Descripción técnica:

El Conectar or de Correo de Internet (IMC) permite a Microsoft Exchange Server comunicarse con otros servidores de correo a través de SMTP. Cuando el IMC recibe un comando de protocolo SMTP extendido Hello (EHLO) desde un servidor SMTP conectado, responde enviando una respuesta de estado que comienza con lo siguiente:

250-Id<.>de servidor de Exchange Hello< Conectar id. de servidor>

Donde:

  • <El identificador> del servidor Exchange es el nombre de dominio completo (FQDN) del servidor Exchange.
  • <Conectar el identificador> de servidor es el FQDN o la dirección IP del servidor que inició la conexión. El FQDN se usaría si el IMC de Exchange5.5 es capaz de resolver esta información a través de una búsqueda inversa de DNS; la dirección IP se usaría si no se pudo realizar una búsqueda de DNS inversa o no se pudo resolver la dirección IP de los servidores de conexión.

Un resultado de vulnerabilidad de seguridad debido a un búfer no activado en el código IMC que genera la respuesta al comando del protocolo EHLO. Si la longitud total del mensaje supera un valor determinado, los datos saturarían el búfer. Si el búfer se sobreejese con datos aleatorios, daría lugar a un error del IMC. Sin embargo, si el búfer se sobreejese con datos cuidadosamente elegidos, podría ser posible que el atacante ejecute código en el contexto de seguridad del IMC, que se ejecuta como cuenta de servicio exchange5.5.

Es importante tener en cuenta que el atacante no pudo simplemente enviar datos al IMC para saturar el búfer. En su lugar, el atacante tendría que crear un conjunto de condiciones que haría que el IMC sobreasigne su propio búfer cuando generó la respuesta EHLO. En concreto, el atacante tendría que asegurarse de que una búsqueda inversa de DNS no solo se realizaría correctamente, sino que proporcionaría un FQDN cuya longitud era suficiente para dar lugar a la saturación del búfer.

Factores de mitigación:

  • La creación de un entorno en el que la búsqueda inversa de DNS del IMC no solo se realizaría correctamente, sino que también resultaría difícil la saturación del búfer. El atacante podría configurar un servidor DNS no autorizado y rellenar manualmente la información de FQDN falsa en él, pero en esto requeriría que el atacante tenga algún medio de forzar al IMC a consultar el servidor DNS no autorizado al realizar la búsqueda inversa de DNS.
  • El IMC se puede deshabilitar en los casos en los que no se necesita compatibilidad con SMTP. Si esto se ha hecho, no se pudo aprovechar la vulnerabilidad.
  • Los clientes pueden deshabilitar la búsqueda de DNS inverso en EHLO estableciendo una clave del Registro tal como se define en Q190026. No se pudo aprovechar la vulnerabilidad en un sistema configurado de tal manera.
  • Si la saturación del búfer provocó un error en el IMC, el servicio normal podría restaurarse reiniciando el servicio IMC de Exchange 5.5.

Clasificación de gravedad:

Servidores de Internet Servidores de intranet Sistemas cliente
Exchange 5.5 SP4 Moderado Moderado None

La evaluación anterior se basa en los tipos de sistemas afectados por la vulnerabilidad, sus patrones de implementación típicos y el efecto que la vulnerabilidad tendría en ellos. Hemos clasificado esta vulnerabilidad como moderada debido a la dificultad de aprovechar la vulnerabilidad.

Identificador de vulnerabilidad:CAN-2002-0698

Versiones probadas:

Microsoft probó Exchange 2000 y Exchange 5.5 para evaluar si se ven afectados por estas vulnerabilidades. Las versiones anteriores ya no se admiten y pueden verse afectadas o no por estas vulnerabilidades.

Preguntas más frecuentes

¿Cuál es el ámbito de la vulnerabilidad?
Se trata de una vulnerabilidad de saturación del búfer. En el peor de los casos, podría permitir que un atacante obtenga un control completo sobre un servidor Exchange afectado. En el caso más probable, podría permitir que un atacante produzca un error en el servicio Exchange. Un atacante que busca aprovechar esta vulnerabilidad se enfrentaría a un desafío muy abrumador. En la mayoría de los casos, aprovechar la vulnerabilidad requeriría que el atacante no solo pudiera establecer una conexión con un servidor de correo vulnerable, sino también poder forzar al servidor a consultar un servidor DNS de la elección del atacante durante el ataque.

¿Qué causa la vulnerabilidad?
Hay un búfer sin marcar en el código dentro del Conectar or correo de Internet de Exchange 5.5 que responde al comando Hello extendido. En las condiciones que se describen a continuación, podría ser posible que el búfer se sobreejese.

¿Cuál es el Conectar or de Correo de Internet?
El Conectar or de Correo de Internet (IMC) es un componente de Exchange Server que permite a Exchange interoperar con los servidores de correo de otros proveedores. Exchange puede usar cualquiera de estos dos protocolos para comunicarse con otros servidores de correo: un protocolo propietario que se usa al comunicarse con otro servidor Exchange; y Protocolo simple de transferencia de mensajes (SMTP), un protocolo estándar del sector que se usa al comunicarse con servidores de terceros. EL IMC es la parte de Exchange que controla las comunicaciones a través de SMTP. Exchange IMC no se instala de forma predeterminada. También se conoce a veces como servicio de correo de Internet de Exchange Server.

¿Cuál es el comando Hello extendido?
Para explicar el comando Hello extendido (EHLO), primero es necesario analizar las extensiones de servicio SMTP. Aunque el protocolo SMTP especifica un conjunto completo de operaciones básicas de correo, también hay un conjunto de servicios y funciones adicionales, denominados extensiones SMTP, que admiten muchos servidores de correo. Estos se especifican en RFC 1869. Cuando dos servidores de correo basados en SMTP inician una conversación, es importante que el servidor inicie la conexión para saber qué, si existe, de las extensiones de servicio SMTP son compatibles con el otro servidor de correo. El comando EHLO forma parte de este proceso. El intercambio de mensajes entre los dos servidores continúa de la siguiente manera:

  1. El servidor 1 establece una conexión a Server 2.
  2. Server 2 envía un "banner".
  3. El servidor 1 envía un EHLO para que pueda determinar qué extensiones SMTP admite Server 2.
  4. Si Server 2 admite EHLO, Server 2 responde al EHLO enviando un mensaje "Hello", identificando a sí mismo y server 1 como los dos participantes en la conexión y enumerando todas las extensiones de servidor que admite.
  5. El servidor 1 comienza a cobrar solicitudes al servidor 2.

¿Qué ocurre con cómo se implementa el comando EHLO en el IMC de Exchange 5.5?
El IMC controla correctamente el comando EHLO entrante. Sin embargo, el software que el IMC utiliza para formular su respuesta ( específicamente, el código usado para construir el Hello en el paso 4 de la pregunta anterior) contiene un búfer sin marcar. Podría ser posible que un atacante construya un escenario en el que responder al comando Hello, a través de un proceso bastante complejo, provocaría que el IMC generara datos que saturarían su propio búfer.

¿Qué permitiría a un atacante hacer?
Al igual que muchas saturaciones de búfer, esta podría usarse para lograr cualquiera de estos dos objetivos en función de los datos exactos proporcionados. Si el búfer se sobreecutó mediante datos aleatorios, el efecto sería hacer que el IMC no se realice correctamente. Por otro lado, si el búfer se sobreecutó mediante datos seleccionados cuidadosamente, podría ser posible, en esencia, modificar el proceso de IMC para realizar tareas de la elección del atacante. Dado que el IMC se ejecuta con privilegios de nivel de sistema, esto concedería al atacante el control completo sobre el servidor.

¿Cómo podría un atacante aprovechar esta vulnerabilidad?
Aprovechar la vulnerabilidad sería sencillo en teoría: el atacante tendría que crear un entorno adecuado y, a continuación, desencadenar un ataque mediante la conexión a un IMC de Exchange 5.5 vulnerable y enviar un comando EHLO. Sin embargo, la creación de un entorno adecuado podría ser bastante difícil.

¿Qué significa "un entorno adecuado"?
Cuando el IMC responde a un comando EHLO, crea una respuesta inicial que identifica ambos servidores, como se explicó anteriormente. Se identifica mediante su nombre de dominio de calidad completa (FQDN) (por ejemplo, "mailserver.microsoft.com"). Identifica el otro servidor a través de su dirección IP o su FQDN, en función de las circunstancias. Por un "entorno adecuado", significamos uno en el que se cumplen las condiciones siguientes:

  • El IMC podría determinar el FQDN del otro servidor.
  • La longitud del FQDN propio del IMC, además de la del FQDN del otro servidor, superó un valor determinado.

Estas condiciones provocarían que el IMC sobreejese su búfer y esto provocaría que el IMC fallase. Para hacer que el IMC sobreejeje su búfer y ejecute el código de la elección del atacante, se necesitaría una condición adicional, es decir, el FQDN del otro servidor tendría que incluir código ejecutable.

¿Qué determina si el IMC usa la dirección IP del otro servidor o su FQDN?
EL IMC siempre intenta usar el FQDN del otro servidor. Sin embargo, para ello, debe realizar una búsqueda inversa de DNS; es decir, debe consultar un servidor DNS, proporcionarla con la dirección IP y recibir el FQDN correspondiente a cambio. Si se produjo un error en la búsqueda inversa de DNS por cualquier motivo, el IMC usaría la dirección IP y esto nunca provocaría que el búfer se sobreaplicara.

¿Qué difícil sería que el atacante realice correctamente la búsqueda inversa de DNS?
El atacante tendría que proporcionar datos falsos a los servidores DNS cercanos y esperar a que los datos se propaguen al servidor DNS que usa el servidor de correo vulnerable. Sin embargo, hay un golpe. El estándar del sector pertinente coloca un máximo en cuánto tiempo puede ser un FQDN y, en la mayoría de los casos, este valor es menor que lo que se necesita para saturar el búfer. Por lo tanto, es probable que los servidores DNS compatibles con estándares no acepten los datos falsos. En su lugar, es probable que el atacante necesite configurar un servidor DNS e insertar manualmente los datos falsos. Pero eso significaría que el atacante tendría que asegurarse de que el IMC vulnerable consultó al servidor DNS del atacante. Claramente, esto haría que aprovechar la vulnerabilidad fuera bastante difícil.

¿Es posible deshabilitar la búsqueda inversa de DNS?

Los clientes pueden deshabilitar la búsqueda de DNS inverso en EHLO estableciendo una clave del Registro tal como se define en Q190026. Los clientes que lo hacen están protegidos contra la saturación del búfer. Los clientes que lo hacen están protegidos contra la saturación del búfer. Cuando la búsqueda inversa de DNS está deshabilitada, el servicio de correo de Internet ya no resolverá el nombre de host en la parte "Recibido desde" del encabezado del mensaje SMTP al nombre de dominio completo, sino que usará la dirección del Protocolo de Internet (IP) con el formato nnn.nnn.n.n.nnn. Si la dirección ya está en el formulario protocolo de Internet (IP), la dirección permanecerá como tal.

¿Afecta la vulnerabilidad a Exchange 2000?
No.

¿Afecta la vulnerabilidad al servicio SMTP que se incluye en Windows 2000?
No.

¿Cómo elimina la revisión la vulnerabilidad?
El parche instituye el control adecuado del búfer en el código IMC de Exchange 5.5.

Disponibilidad de revisiones

Ubicaciones de descarga de esta revisión

Información adicional sobre esta revisión

Plataformas de instalación:

Esta revisión se puede instalar en sistemas que ejecutan Microsoft Exchange 5.5 Service Pack 4.

Inclusión en futuros Service Packs:

None

Reinicio necesario: No

Se puede desinstalar la revisión: Sí

Revisiones reemplazadas: Ninguna.

Comprobación de la instalación de revisiones:

  • Para comprobar que la revisión se ha instalado en la máquina, confirme que se ha creado la siguiente clave del Registro en el equipo:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Novedades\Exchange Server 5.5\SP5\Q326322

  • Para comprobar los archivos individuales, use la información de fecha y hora y versión proporcionada en la siguiente clave del Registro:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Novedades\Exchange Server 5.5\SP5\Q326322\Filelist

Advertencias:

None

Localización:

Las versiones localizadas de esta revisión están disponibles en las ubicaciones descritas en "Disponibilidad de revisiones".

Obtención de otras revisiones de seguridad:

Las revisiones de otros problemas de seguridad están disponibles en las siguientes ubicaciones:

  • Las revisiones de seguridad están disponibles en el Centro de descarga de Microsoft y se pueden encontrar con más facilidad mediante una búsqueda de palabras clave para "security_patch".
  • Las revisiones para las plataformas de consumidor están disponibles en el sitio web de WindowsUpdate

Otra información:

Confirmaciones

Microsoft agradece a Dan Ingevaldson de Sistemas de seguridad de Internet para informar de este problema a nosotros y trabajar con nosotros para proteger a los clientes.

Soporte técnico:

  • El artículo de Microsoft Knowledge Base Q326322 describe este problema y estará disponible aproximadamente 24 horas después del lanzamiento de este boletín. Los artículos de Knowledge Base se pueden encontrar en el sitio web de Soporte técnico en línea de Microsoft.
  • El soporte técnico está disponible en los Servicios de soporte técnico de Microsoft. No hay ningún cargo por las llamadas de soporte técnico asociadas a las revisiones de seguridad.

Recursos de seguridad: el sitio web de seguridad de Microsoft TechNet proporciona información adicional sobre la seguridad en los productos de Microsoft.

Renuncia:

La información proporcionada en Microsoft Knowledge Base se proporciona "tal cual" sin garantía de ningún tipo. Microsoft renuncia a todas las garantías, ya sea expresas o implícitas, incluidas las garantías de comerciabilidad y idoneidad para un propósito determinado. En ningún caso, Microsoft Corporation o sus proveedores serán responsables de cualquier daño, incluyendo daños directos, indirectos, incidentales, consecuentes, pérdida de beneficios empresariales o daños especiales, incluso si Microsoft Corporation o sus proveedores han sido informados de la posibilidad de tales daños. Algunos estados no permiten la exclusión o limitación de responsabilidad por daños consecuenciales o incidentales, por lo que es posible que no se aplique la limitación anterior.

Revisiones:

  • V1.0 (24 de julio de 2002): Boletín creado.
  • V1.1 (25 de julio de 2002): se ha cambiado para indicar que se puede desinstalar la revisión.

Compilado en 2014-04-18T13:49:36Z-07:00

  • Last updated on