Smaury

O OpenEXR fornece a especificação e a implementação de referência do formato de arquivo EXR, um formato de armazenamento de imagens para a indústria cinematográfica. Um estouro de buffer baseado em heap ocorre durante uma operação de escrita ao descomprimir arquivos EXR deep scan-line compactados com ZIPS que contenham um cabeçalho de chunk forjado maliciosamente.

MaterialX is an open standard for the exchange of rich material and look-development content across applications and renderers. Nested imports of MaterialX files can lead to a crash due to stack memory exhaustion. This occurs because the library lacks a limit on the depth of the "import chain" when parsing file imports, utilizing recursion without depth restrictions. Constructing a deeply nested chain of MaterialX files referencing each other can exhaust the stack memory, causing a process crash.

O MaterialX é um padrão aberto para a troca de conteúdo rico de materiais e desenvolvimento de aparência entre aplicativos e renderizadores. Ao analisar nós de shader em um arquivo MTLX, o código MaterialXCore acessa um ponteiro potencialmente nulo, o que pode levar a travamentos com arquivos criados maliciosamente. Um atacante poderia provocar intencionalmente o travamento de um programa alvo que utiliza OpenEXR ao enviar um arquivo MTLX malicioso.

MaterialX is an open standard for the exchange of rich material and look-development content across applications and renderers. When parsing shader nodes in a MTLX file, the MaterialXCore code accesses a potentially null pointer, which can lead to crashes with maliciously crafted files. An attacker could intentionally crash a target program that uses MaterialX by sending a malicious MTLX file.

O MaterialX é um padrão aberto para a troca de conteúdo rico de materiais e desenvolvimento de aparência entre aplicativos e renderizadores. A lógica de análise XML do MaterialX pode potencialmente travar devido ao esgotamento de pilha ao processar um arquivo MTLX com múltiplas implementações de grafos de nós aninhados. Um atacante poderia travar intencionalmente um programa alvo que utiliza OpenEXR enviando um arquivo MTLX malicioso.

O OpenEXR é um formato de armazenamento de imagens utilizado na indústria cinematográfica. Versões anteriores à 3.3.3 confiam em valores de tamanho do dataWindow não validados nos cabeçalhos de arquivo, o que pode levar a uma alocação excessiva de memória e degradação de desempenho ao processar arquivos maliciosos.

OpenEXR is an image storage format used in the motion picture industry. A NULL pointer dereference can occur in a write operation when reading a deep scanline image with a large sample count in reduceMemory mode in version 3.3.2, potentially causing a target application to crash.

O OpenEXR, um formato de armazenamento de imagens utilizado na indústria cinematográfica, contém uma falha. Um estouro de buffer baseado em heap pode ocorrer durante uma operação de leitura ao descomprimir arquivos EXR de scan-line compactados com DWAA que contenham um bloco forjado maliciosamente. O problema é devido a um cálculo incorreto de ponteiros.

O problema permite que um usuário edite todos os detalhes do namespace, incluindo nome, descrição, site, link de suporte e links de redes sociais, mesmo que o usuário não seja um Proprietário ou Contribuidor do namespace. Isso é possível através do endpoint da API `/user/namespace/{namespace}/details` e também afeta o endpoint `/user/namespace/{namespace}/details/logo`, permitindo que um usuário altere o logo.

Nome do Software Vulnerável e Versões Afetadas: SPID.AspNetCore.Authentication versões anteriores a 3.4.0 Descrição: O problema está relacionado à lógica de validação de asserções SAML na biblioteca SPID.AspNetCore.Authentication. Um atacante poderia criar uma resposta SAML arbitrária que seria aceita por Provedores de Serviço (SPs) utilizando SDKs vulneráveis, permitindo-lhes assumir a identidade de qualquer usuário SPID e/ou CIE. A vulnerabilidade baseia-se no fato de que não há garantia de que a primeira assinatura se refira ao objeto raiz e, se um atacante injetar um elemento assinado como o primeiro elemento, todas as outras assinaturas não serão verificadas. O único requisito é possuir um elemento XML legitimamente assinado pelo Provedor de Identidade (IdP), o que é facilmente conseguido utilizando os metadados públicos do IdP. Recomendações: Para versões anteriores a 3.4.0, atualize para a versão 3.4.0 ou superior para resolver o problema. Como solução temporária, considere verificar todas as assinaturas dentro da resposta SAML e não aceite elementos XML não assinados. Restrinja o acesso à função vulnerável `VerifySignature` até que uma correção esteja disponível. Evite utilizar o parâmetro `signedDocument` no endpoint da API afetado até que o problema seja resolvido.

Nome do Software Vulnerável e Versões Afetadas: CIE.AspNetCore.Authentication versões anteriores à 2.1.0 Descrição: A questão diz respeito à lógica de validação de asserções SAML dentro de respostas SAML no CIE.AspNetCore.Authentication. Nas versões afetadas, não há garantia de que a primeira assinatura se refere ao objeto raiz, o que permite a um atacante injetar um elemento assinado como o primeiro elemento, impedindo a verificação de outras assinaturas. Isso poderia permitir que um atacante criasse uma resposta SAML arbitrária que seria aceita por Provedores de Serviço (SPs) utilizando SDKs vulneráveis, permitindo-lhes se passar por qualquer usuário Spid e/ou CIE. O único requisito para um atacante é possuir um elemento XML legitimamente assinado pelo Provedor de Identidade (IdP), o qual pode ser facilmente obtido utilizando os metadados públicos do IdP. Recomendações: Para versões anteriores à 2.1.0, atualize para a versão 2.1.0 ou posterior para corrigir o problema. Como solução temporária, considere verificar todas as assinaturas dentro da resposta SAML e não aceitar elementos XML não assinados para minimizar o risco de exploração. Restrinja o acesso à função vulnerável `VerifySignature` até que uma correção esteja disponível. Evite utilizar o parâmetro `signedDocument` no endpoint de API afetado até que o problema seja resolvido.

O problema ocorre quando o Bref é utilizado com o ambiente de execução de funções orientadas a eventos (Event-Driven Function) e o manipulador é um `RequestHandlerInterface`. Durante a conversão de um evento Lambda em um objeto PSR7, se a solicitação for do tipo MultiPart, cada parte é analisada, e o cabeçalho `Content-Type` de cada parte é lido usando a biblioteca `Riverline/multipart-parser`. Essa biblioteca realiza operações lentas com strings multibyte no valor do cabeçalho, especificamente usando a função `mb convert encoding` com parâmetros lidos do valor do cabeçalho. Um invasor poderia enviar solicitações maliciosas para forçar o servidor a realizar operações demoradas, resultando em uma longa duração de cobrança. O ataque requer que o Lambda utilize o tempo de execução de Funções Orientadas a Eventos, implemente pelo menos um endpoint que aceite solicitações POST, e o invasor pode enviar solicitações de até 6 MB. Se o Lambda utilizar um tempo de execução PHP <= php-82, o impacto é maior.

O problema está relacionado a uma vulnerabilidade de traversal de caminho no código de gerenciamento de sessões do pgAdmin, o que pode levar à deserialização insegura e à execução remota de código. Essa vulnerabilidade pode ser explorada por um invasor não autenticado no Windows ou por um invasor autenticado em sistemas POSIX/Linux, permitindo que eles obtenham execução de código. A vulnerabilidade está associada à serialização incorreta do arquivo de cookie `pga4 session`.

Um aplicativo malicioso de terceiros instalado no mesmo telefone pode forçar o Element Android a compartilhar arquivos armazenados no diretório `files`, localizado no diretório de dados privados do aplicativo, com uma sala arbitrária. O impacto do ataque é reduzido pelo fato de que os bancos de dados armazenados nessa pasta são criptografados. No entanto, ela contém algumas outras informações potencialmente confidenciais, como o token FCM.

A vulnerabilidade permite que um aplicativo malicioso de terceiros inicie qualquer atividade interna passando alguns parâmetros extras, o que pode fazer com que o Element Android exiba uma página da web arbitrária, execute JavaScript arbitrário, contorne a proteção por código PIN e possibilite a invasão de contas ao gerar uma tela de login para enviar credenciais a um servidor doméstico arbitrário.

O problema ocorre quando o Bref é utilizado com o ambiente de execução de funções orientadas a eventos (Event-Driven Function) e o manipulador é um `RequestHandlerInterface`. Nesse cenário, o evento Lambda é convertido em um objeto PSR7. Durante o processo de conversão, se a solicitação for do tipo MultiPart, cada parte é analisada e, para cada parte que contenha um arquivo, este é extraído e salvo em `/tmp` com um nome de arquivo aleatório começando com `bref upload `. No entanto, os arquivos temporários não são excluídos após o processamento da solicitação, permitindo que um invasor encha o disco da instância Lambda realizando múltiplas solicitações MultiPart contendo arquivos.

A vulnerabilidade ocorre quando o Bref é utilizado com o ambiente de execução de funções orientadas a eventos (Event-Driven Function) e o manipulador é um `RequestHandlerInterface`. Nesse cenário, o evento Lambda é convertido em um objeto PSR7. Durante o processo de conversão, se a solicitação for um MultiPart, cada parte é analisada e seu conteúdo adicionado às matrizes `$files` ou `$parsedBody`. O processo de conversão produz uma saída diferente daquela do PHP simples quando são usadas chaves que terminam com um colchete aberto (`[`). Essa diferença na análise do corpo pode levar a vulnerabilidades e/ou comportamentos indefinidos, dependendo da lógica da aplicação.

O problema ocorre quando o Bref é usado em combinação com um API Gateway no formato v2, uma vez que ele não suporta cabeçalhos com valores múltiplos. Se o PHP gerar uma resposta com dois cabeçalhos que tenham a mesma chave, mas valores diferentes, apenas o mais recente será mantido. Isso pode comprometer a segurança da aplicação se ela depender da configuração de vários cabeçalhos com a mesma chave por motivos de segurança. Por exemplo, se uma aplicação definir vários cabeçalhos `Content-Security-Policy`, o Bref refletirá apenas o mais recente.

The issue is related to a lack of authorization, allowing a user with the Technician profile to view and generate a personal token for a Super-Admin. This can be exploited to negotiate a GLPI session and hijack the Super-Admin account, resulting in a privilege escalation.

A vulnerabilidade permite a injeção de dados via sed no arquivo diag routes.php. Usuários autenticados podem injetar código específico do sed e gravar um arquivo arbitrário em um local arbitrário. Os dados são recuperados pela execução do utilitário netstat e, em seguida, sua saída é analisada pelo utilitário sed. Embora sejam utilizados mecanismos comuns de proteção contra injeção de comandos, como a função escapeshellarg para os argumentos, a injeção de código específico do sed ainda é possível.