Por Alexandre Siviero, Atila Altoé e Laura Cardillo
Assim que 2022 começou, um problema no componente de scan de anexos em e-mails em servidores Exchange interrompeu as filas de mensageria. Um ponto interessante foi a semelhança da falha de programação com o bug do milênio. Por isso, ganhou o apelido de Y2K22.
Introdução
Para os administradores de servidores Exchange, o início de 2022 trouxe lembranças do bug do milênio. Uma mensagem de erro no componente de scan de anexos de e-mails interrompeu todo o envio e recebimento de mensagens logo que o novo ano começou. Por essa similaridade, a falha que causou essa interrupção foi informalmente apelidada de Y2K22 (year two thousand and twenty two, 2022), em alusão ao termo em inglês para o bug do milênio – Y2K (year two thousand, 2000).
Resposta inicial à falha
Assim que 2022 começou, administradores de ambientes com a estrutura on premises do Exchange perceberam que as filas de envio e recebimento de e-mail pararam totalmente. Reddit e Twitter concentraram pesquisadores em busca de uma explicação técnica.
Uma mensagem de erro era o ponto comum entre os ambientes afetados:
Description: The FIP-FS "Microsoft" Scan Engine failed to load. PID: 23092, Error Code: 0x80004005. Error Description: Can't convert "2201010001" to long.
2201010001 é o número de versão que foi atribuído à atualização mais recente da Filtering Engine da Microsoft. Tanto esse quanto os números de versões anteriores seguem o padrão ano/mês/dia em sua composição, ou seja: 220101 equivale a uma versão de primeiro de janeiro de 2022.
O termo long é um data type utilizado pela Microsoft. Trata-se de uma variável que recebe números inteiros (com ou sem sinal) de até 32 bits de tamanho.
Valor máximo em um long
Para estabelecer qual o maior número possível de ser escrito com 32 bits é necessário recorrer à notação binária. Cada bit é um valor unitário que contém os números 0 ou 1. Trinta e dois números um, quando convertidos à notação decimal, equivalem a 4.294.967.295.
1111 1111 1111 1111 1111 1111 1111 1111
4.294.967.295 em notação binária
Existe a possibilidade de armazenar números positivos e negativos, o que é chamado de signed long. Nesse caso, o último bit é utilizado para armazenar o sinal: 0 significa positivo e 1 significa negativo. Com um bit a menos para armazenar o número em si, o maior valor possível é +2.147.483.647, enquanto o menor valor é -2.147.483.647.
0111 1111 1111 1111 1111 1111 1111 1111
+2.147.483.647 em notação binária
Análise técnica
Retomando o número da versão problemática da ferramenta de scan de anexos do Exchange, 2201010001. Separando os milhares, temos o número 2.201.010.001. Segunda a mensagem de erro, esse valor não pode ser convertido em uma variável long porque o valor máximo de um signed long é +2.147.483.647. Eis a semelhança ao bug do milênio: ao utilizar os dois últimos dígitos de 2022 no número de versão, a Microsoft criou uma situação incompatível com um código de software, causando um erro que parou todas as filas de e-mail das estruturas on premise do Exchange.
Mitigação
No dia 03 de janeiro, a Microsoft lançou uma correção para essa falha. Não houve alteração do código para suportar valores acima do máximo de um signed long; mudou-se o número da versão para 2112330001, retornando para valores suportados em 32 bit com sinal. Essa alteração pode ser feita manualmente ou via script de powershell. Ambos os métodos estão disponíveis em publicação da Microsoft, aplicável apenas para Exchange Server 2016 e 2019, onde a estrutura de envio e recebimento de e-mails é local (on premise).
Bibliografia
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