Frédéric Desbiens

Os carregadores do Module Manager não liberam o mutex do Module Manager quando ocorre um erro de estouro. Isso acontece quando o preâmbulo de um módulo declara um tamanho de dados ou de pilha que causa um estouro na aritmética de alocação. Consequentemente, o carregamento de tal imagem bloqueia todas as operações subsequentes de carregamento, inicialização, parada e descarregamento de módulos de outras threads, exigindo a reinicialização do sistema para recuperação.

Quando compilado com a descoberta de MTU de caminho IPv6, o manipulador de Pacote Muito Grande ICMPv6 não verifica se a entrada da tabela de destino foi adicionada com sucesso antes de utilizá-la. Um invasor remoto pode preencher a tabela de destino com mensagens de Pacote Muito Grande citando novos destinos. Isso leva a uma desreferenciação de ponteiro NULL na thread de auxílio IP, causando a falha do sistema em alvos que apresentam erro no endereço 0 e interrompendo todo o processamento de rede.

O manipulador PendSV das portas do módulo Cortex-M salva os registradores de uma thread de módulo em modo de usuário preempvida em modo privilegiado, utilizando endereços do ponteiro de pilha da thread. Como o manipulador não verifica o ponteiro em relação à pilha da thread, um módulo em modo de usuário com proteção de memória pode gravar até nove palavras (oito de sua escolha, ou 25 incluindo o estado de ponto flutuante) na memória localizada imediatamente abaixo de qualquer região em que possa gravar e, posteriormente, ler os dados armazenados.

Os serviços de controle de threads do Module Manager não verificam se uma thread fornecida por um módulo protegido de memória em modo de usuário pertence a esse módulo. Isso permite que qualquer módulo carregado execute ações não autorizadas em threads de aplicativos ou threads de outros módulos, incluindo suspender, retomar, terminar, resetar ou alterar a prioridade, bem como abortar suas esperas. Tais ações podem levar a uma negação de serviço ou alterações não autorizadas no escalonamento do sistema.

O servidor DTLS do NetX Secure aloca uma sessão de seu pool de sessões fixo ao receber o primeiro datagrama de um endereço e porta não reconhecidos, ocorrendo antes da troca de cookies. Como as sessões com handshakes interrompidos nunca são liberadas, um invasor remoto não autenticado pode esgotar o pool de sessões enviando um datagrama forjado por origem. Isso resulta em uma negação de serviço para clientes DTLS legítimos até que a aplicação reinicie as sessões.

Quando compilado com suporte a BSD raw socket e IPv6, o caminho de envio IPv6 raw não verifica se a entrada na tabela de destino foi adicionada com sucesso. Se a tabela de destino estiver cheia e um destino off-link for alcançado através de um roteador padrão cuja entrada de cache de vizinhos seja desconhecida, o envio em um socket IPv6 raw com inclusão de cabeçalho causa a desreferenciação de um ponteiro NULL. Um remetente remoto pode preencher a tabela, por exemplo, com mensagens ICMPv6 Packet Too Big, provocando a falha do thread de envio.

No caminho PASV do IPv4, o Cliente FTP aceita qualquer endereço enviado na resposta `227` do servidor. Como a validação abrange apenas a análise e os valores não nulos, um servidor malicioso pode nomear qualquer endereço e direcionar o Cliente para lá.

Ocorre uma desreferenciação de ponteiro NULL quando a tabela de atributos MSRP é esgotada. Uma desreferenciação de ponteiro NULL é um tipo de erro de software onde um programa tenta ler ou gravar em um endereço de memória que é NULL, geralmente levando ao travamento do sistema.

Ocorre uma desreferenciação de ponteiro NULL ao remover o único atributo MSRP (Media Service Resource Protocol). Uma desreferenciação de ponteiro NULL é um erro de software onde o programa tenta ler ou gravar em um endereço de memória que é NULL, geralmente resultando no travamento do sistema.

A validação inadequada de ponteiros não seguros (NS) em múltiplas funções de entrada chamáveis não seguras (NSC) permite que um invasor no mundo não seguro forneça ponteiros para a memória segura. O firmware seguro desreferencia esses ponteiros sem verificar se eles referenciam a memória não segura, resultando na divulgação não intencional de conteúdos da memória segura. Esta violação das garantias de isolamento pode ser utilizada como um primitivo de divulgação ou corrupção de memória que pode permitir a recuperação de material criptográfico sensível.

Existe um problema onde a análise não limitada de opções PPP IPCP causa a interrupção de um worker (worker stall) e uma leitura fora dos limites (out-of-bounds read). O PPP (Point-to-Point Protocol) IPCP (Internet Protocol Control Protocol) é utilizado para configurar os endereços IP de dois endpoints em um link ponto a ponto.

O problema envolve uma conexão de dados passiva FTP que não está vinculada ao peer de controle autenticado, o que pode permitir que terceiros não autorizados interceptem ou sequestrem o canal de dados.

Dois analisadores de handshake TLS/DTLS do lado do cliente contêm leituras fora de limites (out-of-bounds reads). Isso ocorre quando os analisadores leem campos de uma mensagem fornecida pelo servidor antes de validar se a mensagem é longa o suficiente para contê-los. O problema é acionado quando um cliente TLS ou DTLS se conecta a um servidor malicioso ou malformado; embora exista uma verificação de limites, ela é executada após a operação de leitura que deveria proteger.

Ocorre uma leitura fora dos limites (out-of-bounds read) devido ao uso de um comprimento de lista de atributos MSRP não validado. Este problema permite que o sistema leia dados além dos limites do buffer pretendido ao processar a lista de atributos.

Em compilações com `TX ENABLE EVENT TRACE` habilitado, um módulo de modo de usuário com proteção de memória usando `TXM MODULE USER MODE | TXM MODULE MEMORY PROTECTION` pode registrar um ponteiro de função arbitrário como o callback global de rastreamento completo. O kernel executa esse ponteiro diretamente a partir de código de kernel privilegiado, sem validação ou trampoline, quando o buffer de rastreamento é preenchido. Isso pode causar uma falha no kernel resultando em Negação de Serviço (DoS) se um ponteiro inválido for utilizado, ou permitir que o código dentro do módulo seja executado com privilégios de kernel (`CONTROL.nPRIV = 0`).

Dois problemas existem no carregador de módulos carregáveis. Estes são acionados quando um dispositivo carrega um objeto de módulo controlado por um invasor usando as APIs ` txm module manager memory load` ou ` txm module manager in place load`. Como essas APIs aceitam apenas um ponteiro base e nenhum comprimento de imagem, todos os campos de tamanho e deslocamento no `TXM MODULE PREAMBLE` são confiáveis. Isso leva a uma leitura fora dos limites (out-of-bounds read) do heap, onde a variável `code size` é confiada como o comprimento da imagem de origem durante o loop de cópia de código. Além disso, há uma lacuna de integridade do fluxo de controle onde os ponteiros de entrada, início, callback e parada do módulo são calculados como `code start + preamble offset` apenas com uma verificação de diferença de zero, e o `checksum` do preâmbulo não é verificado.

O software gera cookies previsíveis durante o processo DTLS HelloVerifyRequest. Essa previsibilidade pode ser explorada para ignorar o mecanismo baseado em cookies destinado a prevenir ataques de Negação de Serviço (DoS), que são tentativas de tornar uma máquina ou recurso de rede indisponível para seus usuários pretendidos.

Ocorre um heap-buffer-overflow quando um servidor DHCP ou um agente malicioso na rede local responde a uma mensagem DISCOVER. O problema decorre de uma verificação de limite incorreta durante o processo de varredura de opções, onde um ponteiro e um deslocamento (offset) ficam dessincronizados. Especificamente, para cada opção TLV (Tipo-Comprimento-Valor) ignorada, o deslocamento fica um byte atrás da posição de leitura real. Isso permite que o sistema leia aproximadamente um quilobyte além do final da mensagem recebida se uma longa sequência de opções ignoráveis for fornecida em uma mensagem OFFER. Esta operação de leitura ocorre na thread do cliente DHCP durante a inicialização, enquanto o cliente ainda não está configurado, e os bytes vazados podem ser usados para configurar a interface, tornando as informações reveladas observáveis. A falha está localizada na função ` nx dhcp search buffer()`, que é chamada por ` nx dhcp get option value()`.

Ocorre um heap-buffer-overflow quando um servidor TFTP responde com um pacote ERROR curto. O cliente verifica apenas se o datagrama tem pelo menos quatro bytes, mas falha ao comparar o `buffer ptr` com o `nx packet append ptr` ao copiar a string de mensagem. Se um pacote ERROR não possuir um byte NUL de terminação, o loop continua a leitura além do final do pacote até que um byte zero seja encontrado ou o buffer de destino de 64 bytes seja preenchido. Isso permite que a memória adjacente do pool de pacotes seja vazada para a variável `nx tftp client error string`, que pode então ser exibida ou registrada pela aplicação. Este problema afeta a função ` nxd tftp client file read()` e outros caminhos de recebimento no arquivo `nxd tftp client.c`.