Epochalypse Now (ou como lidar com o Y2K38)

Milhões de sistemas de TI, sendo que alguns deles são industriais e outros de IoT, podem começar a se comportar de forma imprevisível em 19 de janeiro. As possíveis falhas incluem: falhas no processamento pagamentos com cartão; alarmes falsos de sistemas de segurança; operação incorreta de equipamentos médicos; falhas nos sistemas automatizados de iluminação, aquecimento e abastecimento de água; e muitos tipos de erros mais ou menos graves. O problema é que… isso acontecerá em 19 de janeiro de 2038. Não que isso seja motivo para relaxar, muito pelo contrário! O tempo restante para providenciar os preparativos talvez seja insuficiente. A causa dessa infinidade de problemas será um estouro nos números inteiros que armazenam data e hora. Embora a causa raiz do erro seja simples e clara, corrigi-lo exigirá esforços extensos e sistemáticos em todos os níveis : de governos e organismos internacionais a organizações e indivíduos.

O padrão informal da Época Unix

A Época Unix é o sistema de cronometragem adotado pelos sistemas operacionais Unix que se tornou popular em todo o setor de TI. Ele conta os segundos de 00:00:00 UTC em 1º de janeiro de 1970, considerado o ponto zero. Qualquer momento no tempo é representado como o número de segundos que se passaram desde aquela data. Para datas anteriores a 1970, são usados valores negativos. Essa abordagem foi escolhida pelos desenvolvedores do Unix por sua simplicidade, em vez de armazenar o ano, mês, dia e hora separadamente, apenas um único número é necessário. Isso facilita operações como classificar ou calcular o intervalo entre datas. Hoje, a Época Unix é usada muito além dos sistemas Unix: em bancos de dados, linguagens de programação, protocolos de rede e em smartphones executando iOS e Android.

A bomba-relógio Y2K38

Inicialmente, quando o Unix foi desenvolvido, foi tomada a decisão de armazenar o tempo como um inteiro com sinal de 32 bits. Isso permitia representar um intervalo de datas de aproximadamente 1901 a 2038. O problema é que, em 19 de janeiro de 2038, às 03:14:07 UTC, esse número atingirá seu valor máximo (2.147.483.647 segundos) e sofrerá um estouro, tornando-se negativo, fazendo com que os computadores se “teletransportem” de janeiro de 2038 para 13 de dezembro de 1901. Em alguns casos, no entanto, uma “viagem no tempo” mais curta pode acontecer, até o ponto zero, que é o ano de 1970.

Esse evento, conhecido como “problema do ano 2038”, “Epochalypse” ou “Y2K38”, poderá ocasionar falhas em sistemas que ainda usam a representação de tempo de 32 bits, como terminais POS, de sistemas integrados e roteadores, passando por automóveis, até equipamentos industriais. Os sistemas modernos resolvem esse problema usando 64 bits para armazenar o tempo. Isso estende o intervalo de datas para centenas de bilhões de anos no futuro. No entanto, milhões de dispositivos com datas de 32 bits ainda estão em operação e precisarão ser atualizados ou substituídos antes da chegada do “dia Y”.

Neste contexto, 32 e 64 bits se referem especificamente ao formato de armazenamento de data. Só porque um sistema operacional ou processador é de 32 bits ou 64 bits, isso não significa automaticamente que ele armazene a data em seu formato de bits “nativo”. Além disso, muitos aplicativos armazenam datas de maneiras completamente diferentes e podem ser imunes ao problema Y2K38, independentemente de sua quantidade de bits.

Nos casos em que não há necessidade de tratar datas anteriores a 1970, a data é armazenada como um número inteiro não assinado de 32 bits. Esse tipo de número pode representar datas de 1970 a 2106, portanto, o problema chegará em um futuro mais distante.

Diferenças do problema do ano 2000

O infame problema do ano 2000 (Y2K) do final do século 20 era semelhante. Naquelas circunstâncias, os sistemas que armazenavam o ano como dois dígitos poderiam confundir a nova data com o ano 1900. Tanto os especialistas quanto a mídia temiam um apocalipse digital, mas, no fim, houve apenas numerosas manifestações isoladas que não resultaram falhas catastróficas globais.

A principal diferença entre Y2K38 e Y2K é a escala da digitalização em nossas vidas. O número de sistemas que precisarão de atualização é muito maior do que o número de computadores no século 20, e a contagem de tarefas e processos diários gerenciados por computadores está além do cálculo. Enquanto isso, o problema Y2K38 já foi, ou será muito em breve, corrigido em computadores e sistemas operacionais comuns com atualizações de software simples. No entanto, os microcomputadores que gerenciam aparelhos de ar-condicionado, elevadores, bombas, fechaduras eletrônicas e linhas de montagem industriais podem muito bem continuar operando pela próxima década com versões de software desatualizadas e vulneráveis ao Y2K38.

Possíveis problemas do Epochalypse

A passagem da data para 1901 ou 1970 afetará sistemas diferentes, de maneiras diferentes. Em alguns casos, como em um sistema de iluminação programado para ligar todos os dias às 19h, a programação poderá passar completamente despercebida. Em outros sistemas que dependem de carimbos de data/hora completos e precisos, uma falha completa poderá ocorrer – por exemplo, no ano 2000, terminais de pagamento e catracas de transporte público pararam de funcionar. Casos cômicos também são possíveis, como a emissão de uma certidão de nascimento com uma data em 1901. Muito pior seria a falha de sistemas críticos, como o desligamento completo de um sistema de aquecimento ou a falha de um sistema de análise de medula óssea em um hospital.

A criptografia ocupa um lugar especial no Epochalypse. Outra diferença fundamental entre 2038 e 2000 é o uso generalizado de criptografia e assinaturas digitais para proteger todas as comunicações. Os certificados de segurança geralmente falham na verificação se a data do dispositivo estiver incorreta. Isso significa que um dispositivo vulnerável seria eliminado da maioria das comunicações, mesmo que seus aplicativos de negócios principais não tenham nenhum código que manipule incorretamente a data.

Infelizmente, o espectro completo de consequências só poderá ser determinado por meio de testes controlados de todos os sistemas, com a análise separada de uma potencial cascata de falhas.

A exploração maliciosa do Y2K38

As equipes de TI e InfoSec devem tratar o Y2K38 não como um simples bug de software, mas como uma vulnerabilidade que poderá ocasionar várias falhas, inclusive a negação de serviço. Em alguns casos, ela poderá até mesmo ser explorada por agentes maliciosos. Para fazer isso, eles precisarão ter a capacidade de manipular a hora no sistema de destino. Isso é possível em pelo menos dois cenários:

• Interferência nos dados do protocolo NTP ao fornecer ao sistema invadido um servidor de tempo falso
• Falsificação do sinal de GPS, caso o sistema dependa da hora via satélite

A exploração desse erro é mais provável em sistemas OT e IoT, onde as vulnerabilidades são tradicionalmente lentas para serem corrigidas e as consequências de uma falha podem ser muito mais substanciais.

Um exemplo de uma vulnerabilidade facilmente explorável relacionada à contagem de tempo é CVE-2025-55068 (CVSSv3 8.2, CVSSv4 base 8.8) nos consoles de medidor de tanque de combustível Dover ProGauge MagLink LX4. A manipulação do tempo pode causar uma negação de serviço no posto de gasolina e bloquear o acesso ao painel de gerenciamento da Web do dispositivo. Esse defeito ganhou seu próprio alerta da CISA.

O status atual da atenuação do Y2K38

Os parâmetros de resolução para o problema do Y2K38 foram estabelecidos com êxito nos principais sistemas operacionais. O kernel do Linux adicionou suporte para o tempo de 64 bits, mesmo em arquiteturas de 32 bits, a partir da versão 5.6, em 2020, e o Linux de 64 bits sempre foi protegido desse problema. A família BSD, macOS e iOS usam o tempo de 64 bits em todos os dispositivos modernos. Todas as versões do Windows lançadas no século 21 não são suscetíveis ao Y2K38.

A situação no armazenamento de dados e no nível do aplicativo é muito mais complexa. Sistemas de arquivos modernos, como ZFS, F2FS, NTFS e ReFS foram desenvolvidos com carimbos de data/hora de 64 bits, enquanto sistemas mais antigos como ext2 e ext3 permanecem vulneráveis. O Ext4 e o XFS exigem que sinalizadores específicos sejam ativados (inode estendido para ext4 e bigtime para XFS), além disso, eles podem necessitar da conversão off-line de sistemas de arquivos existentes. Nos protocolos NFSv2 e NFSv3, o formato de armazenamento de tempo desatualizado persiste. O cenário é igualmente fragmentado nos bancos de dados, o tipo TIMESTAMP do MySQL é intrinsecamente limitado ao ano de 2038 e exige migração para DATETIME, enquanto os tipos de carimbo de data/hora padrão do PostgreSQL são seguros. Para aplicativos escritos em C, os caminhos foram criados para usar o tempo de 64 bits em arquiteturas de 32 bits, mas todos os projetos precisam de recompilação. Linguagens como Java, Python e Go normalmente usam tipos que evitam o estouro, mas a segurança dos projetos compilados depende da possibilidade de interação com bibliotecas vulneráveis escritas em C.

Um grande número de sistemas de 32 bits, dispositivos integrados e aplicativos permanecem vulneráveis até que eles sejam reconstruídos e testados e, em seguida, tenham as atualizações instaladas por todos os usuários.

Várias organizações e entusiastas estão tentando sistematizar informações sobre isso, mas os esforços estão fragmentados. Consequentemente, não há um “banco de dados de vulnerabilidades Y2K38 comum” disponível (1, 2, 3, 4, 5).

Abordagens para correção do Y2K38

As metodologias criadas para priorizar e corrigir vulnerabilidades são diretamente aplicáveis ao problema do ano de 2038. O principal desafio consiste no fato de que nenhuma ferramenta contemporânea pode criar uma lista exaustiva de software e hardware vulneráveis. Portanto, é essencial atualizar o inventário de ativos de TI corporativos, garantir que ele seja enriquecido com informações detalhadas sobre firmware e software instalado e, em seguida, investigar sistematicamente a questão da vulnerabilidade.

A lista pode ser priorizada de acordo com a criticidade dos sistemas de negócios e com os dados na pilha de tecnologia na qual cada sistema está construído. As próximas etapas são: estudar o portal de suporte do fornecedor, fazer perguntas diretas aos fabricantes de hardware e software sobre seu status Y2K38 e, como último recurso, fazer a verificação por meio de testes.

Ao testar sistemas corporativos, é fundamental tomar precauções especiais:

• Nunca teste os sistemas que estão em produção.
• Crie um backup de dados imediatamente antes do teste.
• Isole o sistema em teste das comunicações, para que ele não interfira em outros sistemas da organização.
• Caso a alteração da data use NTP ou GPS, verifique e confirme se os sinais de teste do 2038 não podem alcançar outros sistemas.
• Após o teste, defina os horários de volta para a hora correta nos sistemas e documente minuciosamente todos os seus comportamentos observados.

Caso um sistema seja considerado vulnerável ao Y2K38, uma linha do tempo de correção deverá ser solicitada ao fornecedor. Caso uma correção seja impossível, planeje uma migração; felizmente, o tempo que nos resta ainda permite a atualização de sistemas bastante complexos e caros.

A coisa mais importante para enfrentar o Y2K38 é não pensar nele como um problema futuro distante cuja solução pode facilmente esperar mais cinco a oito anos. É altamente provável que já não tenhamos tempo suficiente para erradicar completamente o defeito. No entanto, dentro de uma organização com seu parque tecnológico, o planejamento cuidadoso e a abordagem sistemática para resolver o problema permitirão realmente fazer tudo isso em tempo hábil.