Alexcrichton

O componente `wasmtime-wasi` anexa novamente uma barra final aos caminhos de origem de renomeação. Em hosts macOS e FreeBSD, isso faz com que a função `renameat()` siga links simbólicos de diretório. Um convidado com acesso de gravação na sandbox pode explorar isso renomeando um link simbólico relativo, como `up/`, para mover diretórios do host para dentro da sandbox, permitindo a leitura e gravação não autorizadas nesses diretórios.

Existe um vazamento de recursos na implementação nativa do WASIp1 dentro da função `fd renumber()`. O problema ocorre porque o descritor de arquivo que está sendo renumerado não é fechado corretamente; a implementação atualiza a tabela de descritores do WASIp1, mas falha em atualizar a tabela de descritores subjacente do host. Consequentemente, embora a operação pareça correta para o guest, recursos são vazados no host e só são recuperados quando o Store correspondente é destruído. Um invasor pode chamar repetidamente a função `fd renumber()` em um loop para esgotar os recursos e os descritores de arquivo do host. Este problema afeta apenas runtimes que carregam módulos core WebAssembly, expõem a função `fd renumber()` e permitem a aquisição de descritores de arquivo, como por meio de operações de abertura de arquivos.

A lógica de alocação para uma tabela WebAssembly contém aritmética verificada que entra em pânico (panic) em caso de estouro (overflow) quando uma tabela de tamanho extremamente grande é alocada. Isso ocorre durante a instanciação de um módulo ou componente WebAssembly e é possível quando o recurso WebAssembly `memory64` está habilitado, permitindo tamanhos de tabela na faixa de 64 bits. O problema afeta especificamente o alocador de instâncias sob demanda, que é o alocador padrão, e pode levar a uma negação de serviço ao causar o pânico do processo hospedeiro.

O Wasmtime, um runtime para WebAssembly, pode sofrer um panic quando o embedder do host descarta o future retornado por `wasmtime::component::[Typed]Func::call async` antes de sua resolução e, em seguida, chama a mesma função novamente com a mesma instância de componente. Isso ocorre porque a instância do componente entra em um estado não reentrável, levando a um trap e subsequente panic durante o descarte da tarefa. O problema surge de um bug na implementação de `[Typed]Func::call async` introduzido com a feature `component-model-async`, que se tornou o padrão a partir da versão 39.0.0. O `Endpoint da API` envolvido é `wasmtime::component::[Typed]Func::call async`. A `variável` representando o future retornado não é nomeada explicitamente, mas seu manejo inadequado dispara o problema. O problema não afeta incorporações com a feature de tempo de compilação `component-model-async` desativada.

A implementação do recurso `wasi:http/types.fields` do Wasmtime é suscetível a pânico quando um número excessivo de campos é adicionado ao conjunto de cabeçalhos. O crate `wasmtime-wasi-http` utiliza uma estrutura de dados que entra em pânico quando atinge sua capacidade, e essa condição não foi tratada adequadamente. Um pânico em uma implementação WASI pode levar a uma Negação de Serviço para os incorporadores.

O Wasmtime, um runtime para WebAssembly, contém vazamentos de memória em sua API C/C++ ao utilizar bindings para valores WebAssembly `anyref` ou `externref`. Este problema decorre de uma regressão introduzida durante o desenvolvimento da versão 37.0.0, especificamente relacionada a uma refatoração de `ManuallyRooted<T>` para `OwnedRooted<T>` em Rust. As APIs C e C++ não foram totalmente atualizadas para refletir as novas semânticas de propriedade de `OwnedRooted<T>`, levando a vazamentos de memória. Especificamente, um erro de digitação na função `wasmtime val unroot` impediu o desenraizamento adequado, e funções definidas pelo host que retornam valores `wasmtime {externref,anyref} t` nunca tiveram suas raízes removidas. A API C++ carecia de destrutores em tipos relevantes, contribuindo ainda mais para o problema. Esses vazamentos ocorrem quando `anyref` ou `externref` são usados na API C/C++, e o crate Rust `wasmtime` não é afetado.

O problema está relacionado à implementação do Wasmtime de chamadas de cauda do WebAssembly combinadas com rastreamentos de pilha, o que pode resultar em uma falha de tempo de execução em determinados módulos do WebAssembly. Isso pode ocorrer quando uma função exportada em um módulo do WebAssembly executa um `return call` (ou `return call indirect` ou `return call ref`) para uma função host importada que captura um rastreamento de pilha. A falha é causada por uma assertiva interna no código de rastreamento de pilha que gera um `panic!()` do Rust. O impacto desse problema é um vetor de negação de serviço, no qual um módulo ou componente WebAssembly malicioso pode causar a falha do host. Não há outro impacto no momento além da disponibilidade do serviço, já que o resultado da falha é sempre uma falha e nada mais.

The issue is related to a bug in the Cranelift code generator of wasmtime, which mistakenly calculates a 35-bit effective address instead of the defined 33-bit effective address for WebAssembly. This allows a malicious module to read or write memory up to 34G away from the base of linear memory, potentially leading to arbitrary code execution or data corruption. The bug is specific to x86 64 targets and does not affect the AArch64 backend. Affected embedders are recommended to analyze preexisting wasm modules for potential exploitation and consider workarounds to mitigate the issue.

Existe um bug na implementação da API C do Wasmtime, em que a definição de `wasmtime trap code` não corresponde à sua assinatura declarada no arquivo de cabeçalho `wasmtime/trap.h`. Essa discrepância faz com que a implementação da função execute uma gravação de 4 bytes em um buffer de 1 byte fornecido pelo chamador, levando à gravação de três bytes nulos além do local de 1 byte fornecido pelo chamador. Esse problema afeta usuários da função da API C `wasmtime trap code`, mas não usuários do crate `wasmtime`.

Existe um bug na implementação do alocador de instâncias em pool do Wasmtime, pelo qual, quando uma memória linear é reutilizada para outra instância, o instantâneo inicial da pilha da instância anterior pode ficar visível, erroneamente, para a instância seguinte. Esse bug ocorre quando um slot no alocador de pooling foi usado anteriormente para um módulo com uma imagem de heap, e a instância seguinte dentro desse slot não contém, por si só, uma imagem de heap. É altamente improvável que o bug seja acionado acidentalmente e, de outra forma, exigiria um acionamento intencional com um módulo criado manualmente. Na prática, os módulos devem ser deliberadamente criados para não terem uma imagem de heap inicial, a fim de visualizar o conteúdo de uma imagem anterior.

Existe um bug na implementação do alocador de instâncias em pool do Wasmtime quando o alocador é configurado para atribuir às instâncias do WebAssembly um máximo de zero páginas de memória. Nessa configuração, o mapeamento de memória virtual para as memórias do WebAssembly não atendia aos requisitos de configuração exigidos pelo compilador para a execução segura de módulos do WebAssembly. As configurações padrão do Wasmtime exigem que falhas de página de memória virtual indiquem que as leituras/gravações do wasm estão fora dos limites, mas a configuração do alocador de pool não criaria um mapeamento de memória virtual apropriado para isso, o que significa que leituras/gravações fora dos limites podem ler/gravar com sucesso memória não relacionada à sandbox do wasm dentro do intervalo do endereço base do mapeamento de memória criado pelo alocador de pool. Este bug só pode ser acionado definindo `InstanceLimits::memory pages` como zero. Espera-se que essa seja uma configuração muito rara, já que isso significa que os módulos Wasm não podem alocar nenhuma página de memória linear. É altamente provável que todos os módulos Wasm produzidos por todas as cadeias de ferramentas atuais utilizem memória linear; portanto, é improvável que essa configuração seja definida como zero em qualquer incorporação do Wasmtime em produção.

Existe um bug no gerador de código do Wasmtime, o Cranelift, em que funções que utilizam tipos de referência podem estar incorretamente sem os metadados necessários para a coleta de lixo em tempo de execução. Isso significa que, se ocorrer uma coleta de lixo em tempo de execução, a passagem de coleta de lixo irá erroneamente considerar que essas funções não possuem referências ativas a valores coletados, recuperando-os e desalocando-os. A função continuará então a usar os valores, assumindo que eles não foram recolhidos, levando posteriormente a um uso após liberação (use-after-free). Esse bug foi introduzido na migração para o alocador de registros `regalloc2`, que ocorreu na versão 0.37.0 do Wasmtime.

O problema está relacionado à implementação do Wasmtime da proposta SIMD para WebAssembly em x86 64, que continha dois bugs nas conversões de instruções implementadas no Cranelift. Os bugs estavam presentes nas instruções WebAssembly `i8x16.swizzle` e `select`. A instrução `select` é afetada apenas quando as entradas são do tipo `v128`. As instruções do Cranelift afetadas correspondentemente foram `swizzle` e `select`. Esse bug representa uma implementação incorreta da semântica especificada dessas instruções de acordo com a especificação do WebAssembly. O impacto disso é benigno para hosts que executam WebAssembly, mas representa possíveis vulnerabilidades na execução de um programa convidado. Por exemplo, um programa WebAssembly poderia tomar ramificações indesejadas ou materializar valores incorretos internamente, o que corre o risco de expor o próprio programa a outras vulnerabilidades relacionadas que podem ocorrer devido a compilações incorretas.

Foi descoberta uma vulnerabilidade de confusão de tipos na API segura das APIs `Linker::func *`. Esse problema ocorre quando um `Engine` é usado para criar o `Linker`, depois um `Engine` diferente é usado para criar um `Store` e, em seguida, o `Linker` é usado para instanciar um módulo nesse `Store`. O uso de funções entre `Engines` diferentes não é suportado no Wasmtime, o que pode resultar em confusão de tipos de ponteiros de função, permitindo que uma função seja chamada com segurança com o tipo errado. Além disso, havia um bug de liberação inválida e leitura e gravação fora dos limites ao executar Wasm que usa `externref`s no Wasmtime. Espera-se que o impacto desses problemas seja relativamente pequeno, pois o uso de mais de um `Engine` em uma incorporação e o uso de `externref` são atualmente bastante raros.