Stéphane Graber

A validação inadequada de certificados no listener HTTPS permite que um invasor remoto não autenticado se passe por um cliente confiável e obtenha acesso total ao cluster e às máquinas virtuais gerenciadas. O problema ocorre porque a API HTTPS valida incorretamente todos os certificados em uma cadeia fornecida em relação ao armazenamento de confiança, em vez de validar apenas o certificado folha que prova a posse da chave privada. Ao fornecer uma cadeia de certificados manipulada contendo o certificado público de um cliente confiável, um invasor pode se autenticar como esse cliente sem possuir a chave privada correspondente. Dependendo dos privilégios do cliente impersonado, isso pode resultar em acesso root à máquina hospedeira. Em ambientes MicroCloud, certificados públicos podem ser interceptados enquanto um membro ingressa no cluster.

The default configuration of systemd-cryptenroll, as used by IncusOS through mkosi, allows an attacker with physical access to the machine to access encrypted data without requiring interaction from the system owner or tampering with Secure Boot or the kernel image. This is due to the LUKS key being available from the TPM if the PCR7 value is expected and the PCR11 policy matches, allowing the key to be released to the booted system. An attacker can substitute the original encrypted root partition with one they control, prompting for a recovery key which they have defined. A systemd unit within the attacker's root partition can then retrieve the encryption key of the real root disk, enabling data theft or alteration before returning the system to its original state. The attack is possible even with Secure Boot enabled, as the initrd selects the root disk based on GPT partition identifiers. The issue impacts all IncusOS users, particularly those in unsecured physical environments. The attack involves altering the GPT partition table, creating a new LUKS encrypted partition, and using a systemd unit to extract the key.

Nome do software vulnerável e versões afetadas: Versões do kernel Linux anteriores à 6.11.0+ Descrição: O problema está relacionado a um erro de deslocamento de um (off-by-one) na função alloc flex gd() do sistema de arquivos ext4. Esse erro pode fazer com que flex gd->resize bg seja maior que flexbg size ao ajustar resize bg. O problema pode ser reproduzido com configurações específicas, como o group = flexbg size * 2 * n e o size = (o group + 1) * group size. Um exemplo do problema ocorre quando n=0 e flexbg size=16. O reprodutor correspondente envolve a criação de um sistema de arquivos ext4, sua montagem e, em seguida, o redimensionamento. O problema foi corrigido excluindo o “mais 1” problemático e adicionando um WARN ON ONCE() para impedir que isso aconteça novamente. Recomendações: Para resolver o problema, atualize o kernel do Linux para uma versão posterior à 6.11.0+. Como solução alternativa temporária, considere evitar o uso do comando resize2fs com configurações específicas que possam desencadear o erro off-by-one. Restrinja o acesso ao sistema de arquivos ext4 vulnerável para minimizar o risco de exploração. Evite usar o comando `resize2fs` com a opção `-s` para redimensionar o sistema de arquivos até que o problema seja resolvido.

Um problema de vazamento de memória foi identificado no módulo openvswitch do kernel Linux. O problema ocorre ao analisar ações fornecidas pelo usuário, pois o módulo pode alocar memória dinamicamente e armazenar ponteiros na cópia interna das ações sem liberá-los adequadamente. Isso pode levar a vazamentos de memória significativos, especialmente em condições com uma alta taxa de rotação de fluxos. A questão é difícil de mitigar devido à falta de controle direto do usuário sobre os fluxos do datapath gerados pelo OVS.

An issue in AppArmor allows an attacker to possibly have increased attack surfaces of processes that were intended to be confined by AppArmor. This is due to incorrect handling of unknown AppArmor profiles in AppArmor init scripts, upstart jobs, and/or systemd unit files. The common logic to handle 'restart' operations removes AppArmor profiles that aren't found in the typical filesystem locations, such as /etc/apparmor.d/. Userspace projects that manage their own AppArmor profiles in atypical directories are affected by this flaw.

The issue is related to insufficient access control to files in the Ubuntu operating system, specifically in the lxd package. It allows a local attacker to gain privileges through unspecified vectors due to world-readable permissions for /var/lib/lxd/unix.socket.

The issue allows local users to gain privileges via a crafted file in a namespace.

The issue is related to the regeneration of iTALC private keys after installation. Due to incorrect regeneration, each installation has the same fixed key, allowing remote attackers to gain privileges.