Amazon Ion-C pode cair com um arquivo — a versão 1.1.6 limita a recursão

A AWS publicou em 2 de setembro de 2026 um aviso sobre uma falha de recursão não controlada no Amazon Ion-C anterior à versão 1.1.6. Conforme o boletim de segurança da AWS, dados Ion preparados por um agente remoto sem autenticação podem esgotar a pilha nativa e derrubar a aplicação que incorporou a biblioteca, causando negação de serviço.

O projeto Ion-C também divulgou o problema em 2 de setembro, e o registro da VulDB confirma a mesma data de divulgação, o impacto sobre versões anteriores à 1.1.6 e a classificação CWE-674. A correção está disponível na versão 1.1.6, que passa a impor um limite padrão de profundidade; portanto, um arquivo com dados Ion especialmente construídos pode derrubar uma aplicação vulnerável quando ela processa esse conteúdo pelo caminho afetado.

Quais chamadas expõem a aplicação

A falha não atinge indistintamente toda operação de leitura. O aviso técnico do projeto Ion-C identifica o caminho que reescreve dados de um leitor para um escritor por meio de ion_writer_write_one_value ou ion_writer_write_all_values. Uma entrada com aninhamento profundo pode fazer essas chamadas recursivas consumirem a pilha do processo.

Esse recorte é importante para avaliar a exposição: receber dados Ion não basta, por si só, para demonstrar que a aplicação percorre o caminho vulnerável. Ao mesmo tempo, não encontrar as duas funções no código principal também não encerra a análise, pois uma biblioteca intermediária, um componente incorporado ou um fork pode chamá-las.

Na versão 1.1.6, a biblioteca interrompe a operação ao alcançar o limite padrão e retorna IERR_STACK_OVERFLOW. O processo pode então tratar ou rejeitar a entrada, desde que a aplicação verifique o código de retorno; a atualização impede a recursão ilimitada descrita no aviso, mas não corrige um tratamento de erros ausente no software consumidor.

Como localizar cópias diretas e transitivas

O inventário precisa cobrir tanto as declarações de dependência quanto o código incorporado ao artefato. Pesquise por ion-c, amazon-ion, pelas duas funções afetadas e pelo endereço do repositório em CMakeLists.txt, módulos CMake, scripts de compilação, submódulos Git e diretórios como vendor ou third_party. Referências em FetchContent, ExternalProject ou add_subdirectory podem indicar que a biblioteca é obtida e compilada junto com a aplicação.

Em projetos que usam Conan, examine o grafo e o lockfile da configuração realmente empregada na compilação. No vcpkg, confira o manifesto, o baseline e as dependências declaradas pelo port. Depois, compare esses registros com os logs de uma compilação limpa: uma receita fixada, um cache de integração contínua ou uma árvore vendorizada pode manter uma versão antiga mesmo após a alteração da dependência de nível superior.

• Associe cada ocorrência ao componente que a introduz, à revisão resolvida e ao artefato final que recebe o código.
• Inclua imagens de contêiner, bibliotecas internas e versões de manutenção ainda distribuídas.
• Trate forks separadamente, porque uma identificação local de versão não prova que o patch foi incorporado.

A inspeção do binário complementa, mas não substitui, os arquivos de construção. Em sistemas ELF, readelf ou ldd podem revelar uma biblioteca compartilhada, enquanto nm e readelf podem localizar símbolos das funções afetadas. A ausência dos nomes não prova que Ion-C está ausente: ligação estática, remoção de símbolos, otimizações e alterações em forks podem ocultá-los.

Atualização e alternativa temporária

A correção preferencial é recompilar e redistribuir a aplicação com Ion-C 1.1.6 ou uma versão posterior que contenha o patch. Para um fork, é necessário verificar a presença efetiva da mudança que limita a profundidade, sem confiar apenas na etiqueta ou nos metadados do pacote.

1. Atualize a receita, o manifesto ou a referência que realmente resolve a dependência.
2. Faça uma compilação limpa para evitar a reutilização de objetos produzidos com a versão vulnerável.
3. Confirme a procedência nos logs do linker, no SBOM e nos metadados disponíveis do artefato entregue.
4. Republique contêineres, bibliotecas internas e releases suportados que carregavam a cópia antiga.

Quando a atualização imediata não for possível, a alternativa documentada é deixar de usar as APIs que reescrevem automaticamente os valores lidos. O fluxo pode percorrer manualmente a árvore de valores, de forma iterativa ou com recursão protegida por um limite explícito. Trata-se de uma mitigação temporária: uma implementação manual que continue sem limite reproduz o risco de esgotamento da pilha.

Como validar o comportamento corrigido

A validação pode empregar uma entrada Ion sintética com contêineres progressivamente aninhados, sempre em um ambiente isolado e com limites de tempo e recursos. O teste deve passar pelo mesmo caminho de integração usado pela aplicação, incluindo uma das chamadas de reescrita afetadas; testar apenas outra API do leitor não demonstra que a condição vulnerável foi exercitada.

No artefato compilado com a versão 1.1.6, uma entrada que exceda o limite deve resultar em IERR_STACK_OVERFLOW, sem encerrar o processo. Esse é um teste funcional da correção, não um benchmark de profundidade: os avisos não estabelecem um número universal que deva ser usado como medida de desempenho entre ambientes.

Registre a versão resolvida, o hash do artefato, a configuração de compilação e o retorno observado. Se o processo ainda cair, isso pode indicar que o teste carregou uma cópia anterior, uma dependência estática não inventariada ou um fork sem o patch. Se o erro for devolvido, mas a aplicação não o tratar corretamente, o limite da biblioteca está ativo e a falha restante pertence ao fluxo de tratamento do software consumidor.

O estado confirmado desde 2 de setembro é que versões anteriores à 1.1.6 estão afetadas e que a 1.1.6 contém a correção. A incerteza que resta para cada equipe não está no status publicado da biblioteca, mas em provar qual revisão chegou a cada binário, contêiner ou produto distribuído.

Leia também:

• Aprender prompt não basta: quatro habilidades para trabalhar com agentes de IA
• E-mail sem clique invade o Zimbra: atualizar o servidor não pode esperar
• Falha no IBM Test Management pode derrubar o serviço — não há mitigação