Claude

A flaw was found in GStreamer's gst-plugins-good, specifically in the H.264 RTP depayloader element. When processing MTAP16 or MTAP24 multi-time aggregation RTP packets, a signed/unsigned integer conversion error causes the remaining-length counter to underflow to a large positive value when the packet is truncated. This allows a remote, unauthenticated attacker to trigger an out-of-bounds heap read of up to approximately 64 KiB of process memory by sending a single malformed RTP packet. Successful exploitation can crash the receiving GStreamer pipeline (denial of service), and in relay or transcoding deployments where output is accessible to the attacker, may expose adjacent heap contents.

Em portas com MPU habilitado e conjuntos de filas (queue sets) ativados, a chamada de sistema de seleção de conjunto de filas carece de validação de tipo adequada. Isso permite que uma tarefa local não privilegiada escreva dados controlados pelo ator além de um objeto do tamanho de um ponteiro na pilha do kernel privilegiado, afetando a memória privilegiada através da fronteira de isolamento da MPU (Unidade de Proteção de Memória).

Ocorre exaustão de recursos em todas as plataformas devido a múltiplos analisadores que não limitam os tamanhos declarados pelo cliente ou o tamanho da saída descompactada. Isso permite que invasores causem consumo desproporcional de memória e travem o processo. O problema originou-se de várias causas: os descompactadores gzip, zlib e snappy não impõem limites de saída, pois o `-max body size` verifica apenas bytes compactados; leitores de string AMF alocam comprimentos declarados antes que os bytes estejam disponíveis; cabeçalhos de chunk RTMP permitem redclarações de comprimento de mensagem ilimitadas durante a transmissão; o analisador sofa-pbrpc não limita o `meta size`; e o mcpack2pb confia em contagens de itens declaradas para `Reserve()`, onde um `value size` de 0 pode causar um underflow no tamanho do buffer.

Uma desreferenciação de ponteiro NULL na implementação do protocolo RTMP permite que atacantes remotos causem a negação de serviço ao travar o servidor. Isso ocorre quando a função `RtmpService::NewStream()` retorna um fluxo nulo para rejeitar um comando `createStream`. Se o servidor falhar ao escrever a resposta de rejeição para o cliente — como quando um cliente fecha a conexão imediatamente após enviar o comando — o caminho de tratamento de erros na função `RtmpChunkStream::OnCreateStream()` tenta acessar a variável `stream-> onfail id` usando o ponteiro nulo, resultando no travamento do processo.

O analisador de respostas do serviço de nomes Discovery falha ao validar se os valores JSON são objetos antes de chamar os acessores exclusivos de objeto do RapidJSON. Uma resposta malformada contendo entradas que não sejam objetos nos membros de dados, serviços ou lista de instâncias pode desencadear uma leitura de memória fora dos limites, potencialmente travando o cliente. Isso ocorre nas funções `DiscoveryNamingService::GetServers()` e `DiscoveryNames::ListDiscoveryNodes()` no arquivo `src/brpc/policy/discovery naming service.cpp`. O problema pode ser acionado se um backend Discovery comprometido ou mal configurado retornar respostas malformadas através dos endpoints '/discovery/nodes' ou '/discovery/fetchs'.

O acúmulo ilimitado de memória no caminho de remontagem de mensagens de stream permite que atacantes remotos causem a negação de serviço enviando uma sequência interminável de quadros de dados de continuação. Embora o protocolo RPC de streaming limite cada quadro de dados individual pelo `max body size`, mensagens de stream fragmentadas acumulam quadros de continuação no buffer ` pending buf` sem limite de tamanho. Como as configurações de controle de fluxo padrão (`socket max streams unconsumed bytes=0`) não restringem a taxa de envio, um peer malicioso pode forçar o receptor a acumular uma mensagem em memória arbitrariamente grande, levando ao esgotamento da memória e falhas no sistema. Isso afeta serviços que aceitam streams de clientes não confiáveis via `brpc::StreamAccept` ou `brpc::StreamCreate` usando o protocolo de streaming integrado.

A ausência de autenticação no caminho de RPC de streaming permite que um invasor remoto ignore a autenticação do servidor e injete ou entregue frames de streaming quando um servidor está configurado com um Authenticator. Isso ocorre porque os frames de RPC de streaming são consumidos diretamente pela função `ParseStreamingMessage()` e ignoram o gancho de autenticação no `InputMessenger`. Além disso, os streams aceitos pelo servidor são vinculados tardiamente ao primeiro frame que carrega seu id, permitindo potencialmente que um stream aceite um frame de um socket diferente daquele que criou o stream.

O consumo descontrolado de recursos no caminho de recebimento HTTP/2 (h2) permite que um invasor remoto não autenticado trave o servidor ou cause o crescimento ilimitado da memória enviando quadros HTTP/2 manipulados. O analisador h2, habilitado por padrão em todas as portas do servidor e usado por clientes h2/gRPC, não impõe os limites do lado do receptor. Especificamente, o servidor não verifica `SETTINGS MAX CONCURRENT STREAMS`, permitindo um número ilimitado de fluxos pendentes por conexão. Além disso, `SETTINGS MAX HEADER LIST SIZE` não é imposto, permitindo uma bomba HPACK onde pequenos quadros HEADERS são amplificados em listas de cabeçalhos decodificadas massivas, ou a memória se acumula via blocos HEADERS/CONTINUATION incompletos. Reconhecimentos de quadros de controle (incluindo PING, SETTINGS, RST STREAM, GOAWAY e WINDOW UPDATE) ignoram o limite de gravação `-socket max unwritten bytes`, permitindo que os buffers de conexão cresçam durante um flood de PING. Por fim, a atualização do tamanho da tabela dinâmica HPACK é validada em relação a um padrão do protocolo em vez do `SETTINGS HEADER TABLE SIZE` anunciado, o que pode levar à dessincronização do decodificador e a um travamento por desreferência de ponteiro NULL.

O consumo descontrolado de recursos no componente de RPC de streaming permite que um invasor remoto cause a negação de serviço ao esgotar a memória do servidor. Isso ocorre quando um cliente envia uma única solicitação RPC contendo um número excessivo de identificadores de fluxo no campo `stream settings.extra stream ids` dos metadados do RPC. A função `StreamAccept()` no lado do servidor cria um fluxo de resposta para cada identificador declarado sem impor um limite. Como o tamanho do corpo da solicitação é limitado por `max body size` (padrão 64MB), ele pode acomodar milhões de identificadores. Cada fluxo aloca uma fila de execução bthread e recursos associados, levando ao esgotamento da memória.

Uma asserção exigível no recurso de streaming permite que um atacante remoto não autenticado cause a queda do processo do servidor, resultando em negação de serviço. Isso ocorre quando o servidor processa quadros `FRAME TYPE FEEDBACK` e chama a função `Stream::SetRemoteConsumed()`. O processo é abortado se um quadro de feedback contiver uma carga útil inesperada ou for recebido em um fluxo onde o controle de fluxo está desabilitado, disparando falhas nas asserções `CHECK( cur buf size > 0)` e `CHECK(buf.IsEmpty())`.

Uma autorização incorreta permite que atacantes remotos acessem serviços integrados através da porta pública. Embora o `ServerOptions.internal port` seja destinado a restringir serviços integrados e Tabbed à porta interna, os caminhos de despacho de protocolos baseados em protobuf (incluindo baidu std, hulu pbrpc, sofa pbrpc, public pbrpc, nshead mcpack, nova pbrpc e ubrpc2pb) calculam a flag `security mode`, mas não a aplicam entre a resolução do método e a invocação. Consequentemente, clientes que acessam a porta pública podem invocar serviços integrados, como `brpc.vars` ou `hotspots`, para revelar informações sensíveis de tempo de execução, incluindo métricas, flags e dados do profiler.

A interpretação inconsistente de solicitações HTTP no analisador HTTP/1.1 incluído permite que atacantes remotos realizem o smuggling de solicitações e injetem cabeçalhos quando o software é implantado atrás de um proxy ou balanceador de carga que analisa bytes de forma diferente. Isso ocorre porque o analisador aceita várias formas de cabeçalhos HTTP/1.1 que front-ends conformes podem rejeitar ou interpretar de maneira distinta, levando à dessincronização entre os dois analisadores. Detalhes técnicos incluem a aceitação de espaços antes de dois pontos em cabeçalhos de enquadramento, a omissão de espaços internos no valor `Content-Length` e a aceitação de dobramento de linha obsoleto (obs-fold) para os valores `Content-Length` e `Transfer-Encoding`. Além disso, campos de trailer chunked são mesclados no mapa de cabeçalhos, permitindo potencialmente o smuggling de campos como `Authorization` ou `X-Forwarded-For`. Adicionalmente, listas de `Transfer-Encoding` com espaços opcionais após a vírgula podem não ser reconhecidas como chunked, causando a dessincronização da resposta.

Um conflito de interpretação na implementação do protocolo HTTP permite que atacantes remotos ignorem as regras de controle de acesso impostas por um proxy frontal. A função `FindMethodPropertyByURI()` divide a rota da solicitação usando um divisor de strings que ignora campos vazios. Consequentemente, rotas com barras consecutivas (segmentos de rota vazios), como `//flags`, são tratadas como a forma colapsada `/flags`. Como um proxy frontal que impõe uma Lista de Controle de Acesso (ACL) pode corresponder apenas à forma colapsada, ele pode encaminhar o literal preenchido para o servidor bRPC, que então o despacha para o serviço restrito. Além disso, a implementação do HTTP/2 não valida o pseudo-cabeçalho `:path`, permitindo que solicitações que não começam com `/` ou que não sejam a forma de asterisco `*` sejam processadas, contrariando a RFC 9113.

Existe uma leitura fora dos limites (out-of-bounds read) no cliente RPC de streaming em todas as plataformas. Quando um cliente cria múltiplos fluxos em um único RPC, ele espera que a resposta do servidor contenha exatamente um `extra stream id` para cada fluxo adicional. O caminho de processamento da resposta na função `Controller::HandleStreamConnection()` indexa os identificadores retornados usando a contagem de fluxos criados localmente sem validar o tamanho da lista retornada. Um servidor malicioso ou comprometido, ou um invasor no caminho da rede, pode desencadear isso retornando uma resposta StreamSettings malformada com menos `extra stream ids` do que o esperado. Isso pode causar a falha do processo do cliente (negação de serviço) ou o vazamento de conteúdos de memória não pretendidos para o processamento de fluxos subsequentes.

Existe uma desreferenciação de ponteiro nulo na máquina de estados IKEv2, especificamente no código de manipulação de EAP para autenticação. Devido a uma inconsistência no código da máquina de estados, ocorre um fall-through onde o sistema desreferencia incorretamente a variável `ike->sa.st eap` enquanto ela está NULL. Este problema pode ser acionado por qualquer conexão IKEv2 através de um pacote IKE AUTH malicioso, independentemente de o EAP estar configurado ou não, e não requer que o peer seja autenticado. A exploração leva ao travamento e reinicialização do daemon pluto, o que pode resultar em uma negação de serviço. A execução remota de código não é possível.

Existe uma desreferenciação de ponteiro nulo no código de manipulação de PKCS#7 usado para autenticação de certificado IKE. O problema ocorre ao decodificar um payload IKE CERT do tipo `CERT PKCS7 WRAPPED X509`. O software utiliza `SEC PKCS7ContainsCertsOrCrls()` para validar o blob PKCS#7 e, posteriormente, utiliza `SEC PKCS7GetCertificateList()` para iterar a lista de certificados. Uma discrepância entre essas duas APIs do NSS permite que um objeto SignedData contendo uma CRL (Lista de Revogação de Certificados), mas sem certificados, passe na guarda inicial, enquanto a recuperação subsequente da lista retorna NULL. Isso leva a uma desreferenciação de ponteiro nulo, fazendo com que o sistema trave e reinicie. Um peer não autenticado pode disparar esse comportamento enviando um pacote `IKE AUTH` malicioso, resultando potencialmente em uma negação de serviço através de exploração contínua.

Um estouro de buffer baseado em heap (heap-based buffer overflow write) existe no carregador de dicionários de apenas leitura. A função `String::reserve()` em `common/string.hpp` realiza uma verificação de capacidade usando um inteiro assinado `((int)s + 1)`, o que permite que um tamanho solicitado de `0x7FFFFFFF` envolva para um valor negativo, impedindo o crescimento do buffer de suporte. A função `ReadOnlyDict::load()` em `modules/speller/default/readonly ws.cpp` passa campos de tamanho de 32 bits não validados de um cabeçalho de dicionário `.rws` para este caminho. Consequentemente, um arquivo `.rws` manipulado contendo um marcador endian válido e um campo de comprimento excessivo, como `lang name size` definido como `0x7FFFFFFF`, permite que dados controlados pelo invasor sejam gravados fora dos limites de uma alocação de heap subdimensionada. Isso pode levar à corrupção da memória heap, resultando em negação de serviço ou potencial execução de código se uma vítima for induzida a carregar um dicionário malicioso.

A complexidade algorítmica ineficiente na conversão de string de nome distinto X.509 nas funções `X509Name.ToString` e `IetfUtilities.ValueToString` permite que um atacante remoto não autenticado cause a negação de serviço através do esgotamento da CPU. Isso ocorre ao processar um certificado, CRL, solicitação de certificação ou outra estrutura que contenha um valor de atributo longo composto por espaços iniciais ou finais ou caracteres que exijam escape, como vírgulas. O problema surge porque cada barra invertida de escape é inserida no buffer que está sendo verificado, fazendo com que a carga de trabalho cresça quadraticamente em relação ao comprimento do valor. As aplicações ficam expostas ao converter tais nomes em strings, por exemplo, para registro ou exibição, ou ao compará-los usando a função `IetfUtilities.RdnAreEqual`, como ocorre na validação de caminho PKIX para restrições de nome `directoryName`.

Atacantes remotos não autenticados podem causar a negação de serviço através do esgotamento de memória ao fornecerem uma chave pública HSS e uma assinatura especialmente manipuladas. O problema ocorre porque a contagem de nível `L` lida durante a análise de uma chave pública HSS no código `HssPublicKeyParameters` e `HssSignature` não é validada em relação ao limite máximo de 8 do RFC 8554. Consequentemente, o processo de análise da assinatura aloca um array de `L - 1` entradas antes de processar mais dados, o que pode levar a que uma única verificação comprometa até 17 GB de memória ou desencadeie uma `OutOfMemoryException`.

No modo de fluxo do `IesEngine` (quando construído sem uma cifra de bloco), a chave de autenticação de mensagem é exposta através do keystream de criptografia. Um invasor remoto que tenha observado uma mensagem criptografada com texto simples conhecido pode forjar mensagens menores que o destinatário aceitará como autênticas, utilizando um texto cifrado e uma tag MAC manipulados. Isso ocorre porque a chave MAC é derivada da saída diretamente após um keystream com o mesmo comprimento da mensagem, enquanto a entrada de derivação depende apenas do par de chaves estáticas e parâmetros fixos. Consequentemente, o keystream revelado por uma única mensagem contém a chave MAC para todas as mensagens suficientemente menores.