Por Alexandre Siviero, Atila Altoé y Laura Cardillo
Nada más empezar 2022, un problema en el componente para escanear los archivos adjuntos en los correos electrónicos de los servidores Exchange interrumpió las colas de mensajería. Un punto interesante fue la similitud del fallo de programación con el efecto 2000. De ahí que se ganara el sobrenombre de efecto 200022.
Introducción
Para los administradores de servidores Exchange, el comienzo de 2022 trajo a la memoria el error del milenio. Un mensaje de error en el componente de análisis de adjuntos de correo electrónico interrumpió todo envío y recepción de mensajes nada más comenzar el nuevo año. Debido a esta similitud, el fallo que causó esta interrupción fue apodado informalmente Y2K22 (año dos mil veintidós, 2022), en alusión al término inglés para el fallo del milenio - Y2K (año dos mil, 2000).
Respuesta inicial al fracaso
En cuanto comenzó 2022, los administradores de entornos con el marco Exchange on premises notaron que las colas de envío y recepción de correo electrónico se detenían por completo. Reddit y Twitter concentraron a investigadores en busca de una explicación técnica.
Un mensaje de error era el hilo conductor entre los entornos afectados:
Descripción: El motor de escaneo FIP-FS "Microsoft" no pudo cargarse. PID: 23092, Código de error: 0x80004005. Descripción del error: No se puede convertir "2201010001" a long.
2201010001 es el número de versión que se asignó a la actualización más reciente del motor de filtrado de Microsoft. Tanto este número de versión como los anteriores siguen el patrón año/mes/día en su composición, es decir, 220101 equivale a una versión del 1 de enero de 2022.
El término long es un tipo de datos utilizado por Microsoft. Es una variable que recibe enteros (con o sin signo) de hasta 32 bits de longitud.
Valor máximo en un long
Para establecer cuál es el mayor número posible que puede escribirse con 32 bits es necesario recurrir a la notación binaria. Cada bit es un valor unitario que contiene los números 0 ó 1. Treinta y dos números uno, convertidos a notación decimal, equivalen a 4.294.967.295.
1111 1111 1111 1111 1111 1111 1111 1111
4.294.967.295 en notación binaria
Existe la posibilidad de almacenar números positivos y negativos, lo que se denomina signed long. En este caso, el último bit se utiliza para almacenar el signo: 0 significa positivo y 1 negativo. Con un bit menos para almacenar el propio número, el mayor valor posible es +2.147.483.647, mientras que el menor es -2.147.483.647.
0111 1111 1111 1111 1111 1111 1111 1111
+2.147.483.647 en notación binaria
Análisis técnico
Volviendo al problemático número de versión de la herramienta de escaneo de archivos adjuntos de Exchange, 2201010001. Separando los miles, tenemos el número 2.201.010.001. Según el mensaje de error, este valor no se puede convertir en una variable long porque el valor máximo de un long con signo es +2.147.483.647. He aquí la similitud con el error del milenio: al utilizar los dos últimos dígitos de 2022 en el número de versión, Microsoft creó una situación incompatible con un código de software, provocando un error que detuvo todas las colas de correo electrónico de los marcos Exchange on premise .
Mitigación
El 3 de enero, Microsoft publicó una corrección para este fallo. No hubo cambios en el código para soportar valores por encima de un máximo largo con signo; cambió el número de versión a 2112330001, volviendo a soportar valores en 32 bits con signo. Este cambio puede realizarse manualmente o mediante un script powershell. Ambos métodos están disponibles en la versión de Microsoft, aplicable solo para Exchange Server 2016 y 2019, donde la estructura de envío y recepción de correo electrónico es local(on premise).
Bibliografía
https://www.reddit.com/r/sysadmin/comments/rt91z6/exchange_2019_antimalware_bad_update/
https://www.fudzilla.com/news/54133-year-2022-bug-hits-microsoft-exchange
https://docs.microsoft.com/en-us/dotnet/api/system.int32?view=net-6.0
https://twitter.com/JRoosen/status/1477203087421018118?ref_src=twsrc%5Etfw