Skip to content
KitploitKITPLOIT
FerramentasBlog
Enviar
FerramentasBlog
Enviar

Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!

Kitploit é um diretório de ferramentas de hacking, cibersegurança e pentesting. Descubra as últimas atualizações de projetos para encontrar vulnerabilidades, analisar sistemas, automatizar testes e fortalecer sua segurança.

··Feeds·Contato·Privacidade·© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
LID — LID — Linux Integrity Drift: Bypassing AppArmor via eBPF pathname rewriting. Pre-LSM syscall argument manipulation with zero audit footprint. "Linux is Dying" | Kitploit
Ferramentas/GitHubGitHub/azqzazq1/lid
Privilege EscalationVulnerability AnalysisExploitationIDS/IPS EvasionPenetration TestingBinary AnalysisPapers & ResearchLearning & EducationRed Teaming
GitHubazqzazq1/lid

LID

LID — Linux Integrity Drift: Bypassing AppArmor via eBPF pathname rewriting. Pre-LSM syscall argument manipulation with zero audit footprint. "Linux is Dying"

201há 2 mesesAinda não revisado

Mais Populares

Ver todos →

Descubra as ferramentas mais usadas pela nossa comunidade.

Explore todas as ferramentas

Navegue pela nossa coleção de ferramentas

Ver todas as ferramentas →
Compartilhar
Ver Repositório


``` ██╗ ██╗██████╗ ██║ ██║██╔══██╗ ██║ ██║██║ ██║ ██║ ██║██║ ██║ ███████╗██║██████╔╝ ╚══════╝╚═╝╚═════╝ ```

Linux Integrity Drift

— "O Linux está Morrendo" —


Descoberta sistemática de caminhos no kernel que ignoram as garantias de segurança do LSM
O portão nunca foi arrombado. Foi contornado.



O que é LID?

O framework Linux Security Module tem uma garantia central que se mantém há mais de 20 anos:

Módulos de segurança só podem adicionar restrições. Eles nunca podem removê-las.

Esta garantia está correta. LID não a quebra.

LID encontra caminhos de código do kernel que ignoram completamente os hooks do LSM — subsistemas que realizam operações sensíveis à segurança sem consultar o framework LSM. A verificação de segurança está correta. O problema é que o kernel nunca pergunta.


Entendendo o que LID é (e não é)

Cada descoberta tem duas dimensões distintas que não devem ser confundidas:

A) Lacuna de Visibilidade da Política

O ponto cego arquitetônico. A pergunta não é "um atacante pode explorar isso?", mas sim:

  • O que AppArmor/SELinux realmente vê?
  • O que o log de auditoria registra?
  • O que seu SIEM/EDR observa?
  • O que o mecanismo de política pensa que aconteceu?

Se uma operação sensível à segurança ocorre e a camada de aplicação nunca a avalia, você tem uma lacuna de visibilidade — independentemente de um atacante poder abusar dela na prática hoje. Isso importa para conformidade, perícia forense e pressupostos de defesa em profundidade.

B) Caminho Prático de Escalonamento

A questão real de explorabilidade:

  • Isso cruza um limite de privilégio?
  • Um atacante precisa de root/CAP_BPF existente para acionar?
  • É necessária uma cadeia de exploração ou é independente?
  • Qual é o impacto real — acesso a dados, escalonamento de privilégio, evasão de política?

Essas duas coisas são diferentes. Uma descoberta pode ser uma lacuna de visibilidade crítica (seu monitoramento está cego) sem ser um escalonamento de privilégio prático (atacante já precisa de root). Por outro lado, uma descoberta pode ser um caminho direto de escalonamento com pré-requisitos mínimos.


Matriz de Reprodutibilidade

Cada descoberta tem requisitos específicos de kernel/config/ privilégio. Se seu ambiente não corresponder, a descoberta não será reproduzida.

LID-001: Reescrevendo Caminho via eBPF

LID-002: io_uring MSG_RING

LID-004: Cegueira do AppArmor para Token BPF

LID-003: Nova API de Montagem

LID-005: Bypass de tc Egress via AF_XDP

Referência Rápida: O que Bloqueia Cada Descoberta


Descobertas


O Padrão

Cada descoberta segue o mesmo padrão:``` ┌─────────────────────────────────────────────────────────────┐ │ THE LID PATTERN │ │ │ │ Kernel Subsystem A LSM Framework │ │ (eBPF / io_uring / mount API) (AppArmor / SELinux) │ │ │ │ ┌───────────────────┐ │ │ │ Performs operation │──── should call ──── security_*() │ │ │ or manipulates │ but │ │ │ security input │ DOESN'T ██ │ │ └───────────────────┘ │ │ │ │ The LSM framework is correct. │ │ The kernel just doesn't always use it. │ └─────────────────────────────────────────────────────────────┘

root@kitploit:~
Dois subsistemas do kernel. Premissas de confiança incompatíveis. Uma brecha.

<br>

---

## LID-001: Reescrita de Caminhos eBPF

**A descoberta principal.** Uma kprobe BPF em `do_sys_openat2` reescreve o nome do arquivo na memória do usuário antes que o kernel o copie. AppArmor verifica o caminho reescrito, concede acesso. Zero rastro de auditoria.```
  process: open("/tmp/secret.txt")
       │
       ▼
  do_sys_openat2()
       │
    ★ LID kprobe fires here
    │  bpf_probe_write_user()
    │  rewrites "/tmp/secret.txt" → "/tmp/.bypass_link"
       │
       ▼
  getname_flags()          ← kernel copies the (rewritten) path
       │
       ▼
  security_file_open()     ← LSM hooks check "/tmp/.bypass_link"
       │                      AppArmor: ALLOW ✓
       ▼
  VFS opens inode          ← same file content (hard link)
       │
       ▼
  return fd to process     ← success, zero audit trace

Início Rápido```bash

sudo ./scripts/check_prerequisites.sh sudo ./scripts/setup_env.sh make sudo ./scripts/setup_demo.sh sudo ./scripts/run_demo.sh

root@kitploit:~
### Saída de Demonstração```
╔══════════════════════════════════════════════════════════╗
║  Phase 1: AppArmor ENFORCING — access should be DENIED   ║
╚══════════════════════════════════════════════════════════╝

  $ /tmp/test_reader
  [-] DENIED: open() failed: Permission denied (errno=13)

╔══════════════════════════════════════════════════════════╗
║  Phase 2: Loading LID — BPF kprobe pathname rewrite       ║
╚══════════════════════════════════════════════════════════╝

  [*] BPF kprobe attached to do_sys_openat2

╔══════════════════════════════════════════════════════════╗
║  Phase 3: With LID active — access should be GRANTED      ║
╚══════════════════════════════════════════════════════════╝

  $ /tmp/test_reader
  [+] SUCCESS: Read 44 bytes: SECRET_DATA=this_is_protected_content_12345

╔══════════════════════════════════════════════════════════╗
║  Phase 4: Stealth check — audit log inspection             ║
╚══════════════════════════════════════════════════════════╝

  $ dmesg | grep apparmor | grep DENIED
  (empty — no denial was ever generated)


LID-002: io_uring MSG_RING Hook LSM Ausente

IORING_OP_MSG_RING com IORING_MSG_SEND_FD transfere descritores de arquivo entre anéis io_uring sem chamar security_file_receive(). Todos os outros mecanismos de transferência de fd o chamam:``` MSG_RING SEND_FD: __io_fixed_fd_install() ← NO security_file_receive() FIXED_FD_INSTALL: receive_fd() ← security_file_receive() ✓ SCM_RIGHTS: receive_fd() ← security_file_receive() ✓ binder: security_binder_transfer_file() ✓

root@kitploit:~
**Localização do bug:** `io_uring/msg_ring.c`, `io_msg_install_complete()` — chama `__io_fixed_fd_install()` diretamente, ignorando o hook do LSM.

**Verificado com ftrace:** `security_file_receive` é acionado para SCM_RIGHTS, mas não para MSG_RING.

**Afetado:** Linux 5.18+ até v7.1-rc3 (não corrigido em 2026-05-17).

**PoC:** [`findings/lid-002-iouring-msgring/msg_ring_bypass.c`](https://github.com/azqzazq1/lid/blob/HEAD/findings/lid-002-iouring-msgring/)

<br>

---

## LID-003: Nova API de Montagem Ignora AppArmor

A nova API de montagem (`fsopen` + `fsconfig` + `fsmount` + `move_mount`) **nunca chama `security_sb_mount()`** — o único hook de montagem que o AppArmor implementa.```
  OLD API:  mount("proc", "/mnt", "proc", 0, NULL)
            → security_sb_mount()  → AppArmor: DENY ✗

  NEW API:  fsopen("proc") → fsconfig(CMD_CREATE) → fsmount() → move_mount()
            → security_sb_kern_mount()  → AppArmor: (not implemented) → ALLOW ✓

O AppArmor registra 4 hooks de montagem. O SELinux registra 14. A nova API de montagem usa hooks que apenas o SELinux implementa.

Lacunas adicionais encontradas:

  • open_tree(OPEN_TREE_CLONE): Zero hooks de segurança — ignora a política de bind-mount
  • mount_setattr(): Nenhum hook LSM existe no kernel
  • move_mount() with detached mounts: O AppArmor vê caminho de origem NULL

Detalhes: findings/lid-003-mount-api/



LID-004: BPF Token — Cobertura Zero do AppArmor

O subsistema de token BPF (Linux 6.9+) delega capacidades BPF a processos não privilegiados em namespaces de usuário. O kernel define 9 hooks LSM BPF. O SELinux implementa todos os 9 com aplicação real avc_has_perm(). O AppArmor implementa zero.``` Kernel defines 9 BPF LSM hooks: ┌─────────────────────────────────────────────────────────────────┐ │ bpf, bpf_map, bpf_prog, bpf_map_create, bpf_prog_load, │ │ bpf_token_create, bpf_token_free, bpf_token_cmd, │ │ bpf_token_capable │ └─────────────────────────────────────────────────────────────────┘

SELinux: ████████████████████████████ 9/9 implemented AppArmor: 0/9 implemented Smack: 0/9 implemented

root@kitploit:~
No Ubuntu/Debian, um contêiner com delegação bpffs pode:
- Criar tokens BPF → AppArmor não vê nada
- Usar tokens para carregar programas de rastreamento → AppArmor não vê nada
- Delegar CAP_PERFMON → desativar mitigações Spectre → AppArmor não vê nada

**Detalhes:** [`findings/lid-004-bpf-token/`](https://github.com/azqzazq1/lid/blob/HEAD/findings/lid-004-bpf-token/)

<br>

---

## LID-005: Bypass de Egresso tc AF_XDP do Contêiner Docker Padrão

O caminho de transmissão em modo cópia do AF_XDP (`xsk_generic_xmit` → `__dev_direct_xmit`) **ignora os classificadores de egresso tc** na interface do contêiner. Verificado com tc u32 DROP-ALL — AF_PACKET bloqueado, AF_XDP passa.

**No entanto:** Testado com Cilium v1.19 (cluster kind, NetworkPolicy de egresso negar-tudo) — **Cilium NÃO foi contornado.** O Cilium aplica a política no ingresso do par veth do lado do nó (`cil_from_container` via tcx/ingress) + tem verificação de IP de origem. Pacotes AF_XDP foram descartados como "IP de origem inválido" em `bpf_lxc.c:1603`. O impacto é limitado a ambientes que dependem exclusivamente de classificadores de egresso tc para política de rede (Docker simples + regras tc, sem CNI).```
  Normal TX path:
  socket → dev_queue_xmit() → sch_handle_egress() → tc classifiers → driver
                                     ↑
                                  ENFORCED (Cilium eBPF, Calico, tc u32)

  AF_XDP copy-mode TX:
  xsk_sendmsg() → xsk_generic_xmit() → __dev_direct_xmit() → driver
                                              ↑
                                           SKIPPED (tc never runs)

Verificado dinamicamente no kernel 6.8.0 com contêineres padrão do Docker:``` tc egress DROP-ALL on container eth0:

AF_PACKET sendto → ENOBUFS (BLOCKED by tc) AF_XDP sendto → 0 (BYPASS — 3 spoofed packets reached docker0 bridge)

root@kitploit:~
Pacotes carregam cabeçalhos Ethernet controlados pelo atacante — MAC falsificado, IP falsificado — e alcançam a ponte Docker apesar da política DROP ativa.

**PoC + detalhes:** [`findings/lid-005-afxdp-tc-bypass/`](https://github.com/azqzazq1/lid/blob/HEAD/findings/lid-005-afxdp-tc-bypass/)

<br>

---

## Arquitetura: Por que o BPF LSM não pode corrigir isso```
  LSM Hook Chain: call_int_hook(file_open, ...)

  ┌─────────────┐   ┌─────────────┐   ┌─────────────┐   ┌─────────────┐
  │  Lockdown    │──>│  Capability  │──>│   AppArmor   │──>│  BPF LSM    │
  │  return 0    │   │  return 0    │   │  return -13  │   │  (never     │
  │  (allow)     │   │  (allow)     │   │  (DENY) ██   │   │   reached)  │
  └─────────────┘   └─────────────┘   └──────┬───────┘   └─────────────┘
                                              │
                                         loop breaks
                                         RC = -EACCES

  ★ The LSM framework is correct. No module can undo another's denial.
  ★ LID operates OUTSIDE the framework — before hooks run, or where hooks don't exist.

Companheiro: SunnyDayBPF```

root@kitploit:~
               ┌───────────────────────────────────────┐
               │          THE ATTACK TIMELINE           │
               │                                       │

Syscall Entry │ ★ LID ─── manipulates input │ │ │ (security check sees wrong data) │ ▼ │ │ LSM Check │ LSM allows (or never runs) ✓ │ │ │ │ ▼ │ │ Syscall Exit │ ★ SunnyDayBPF ─── rewrites telemetry │ │ │ (monitoring sees wrong data) │ ▼ │ │ Audit/Log │ SIEM sees nothing ✓ │ │ │ │ Combined: ghost access │ └───────────────────────────────────────┘

root@kitploit:~
<br>

## Estrutura do Projeto```
LID/
├── src/
│   ├── bpf/
│   │   └── lid.bpf.c              # BPF kprobe — pathname rewriter (LID-001)
│   └── loader/
│       └── lid_loader.c           # Userspace loader + event monitor
├── findings/
│   ├── lid-001-ebpf-pathname/     # eBPF pathname rewriting bypass
│   ├── lid-002-iouring-msgring/   # io_uring MSG_RING missing LSM hook
│   │   ├── msg_ring_bypass.c      # PoC with ftrace verification
│   │   └── ADVISORY.md            # Technical advisory
│   ├── lid-003-mount-api/         # New mount API AppArmor bypass
│   ├── lid-004-bpf-token/        # BPF token AppArmor/Smack zero coverage
│   └── lid-005-afxdp-tc-bypass/  # AF_XDP tc egress bypass from container
├── tests/
│   └── test_reader.c              # Victim binary for LID-001 demo
├── scripts/
│   ├── check_prerequisites.sh     # Verify system requirements
│   ├── setup_env.sh               # Install build dependencies
│   ├── setup_demo.sh              # Create demo environment
│   ├── run_demo.sh                # Run full LID-001 demonstration
│   └── teardown.sh                # Clean up everything
├── docs/
│   └── RESEARCH.md                # Full technical research paper
├── publish/                       # Articles for Medium, dev.to, etc.
├── Makefile
├── LICENSE
├── SECURITY.md
└── README.md

Perfil Furtivo (LID-001)


Mitigações

Para orientação detalhada de mitigação, veja docs/RESEARCH.md.


Requisitos

Veja a Matriz de Reprodutibilidade para detalhes completos por descoberta. Resumo:


Autor

Azizcan Daştan
Milenium Security

  • GitHub: @azqzazq1

Aviso Legal

Esta ferramenta é publicada para testes de segurança autorizados, pesquisa e fins educacionais apenas. Não use contra sistemas que você não possui ou para os quais não possui permissão explícita por escrito para testar.


LID — porque a integridade nunca foi bloqueada.

Baixar ferramenta
DescobertaLacuna de VisibilidadeEscalonamento Prático
LID-001Crítica — AppArmor não vê nada, log de auditoria vazio, zero vestígio forenseLimitado — requer root ou CAP_BPF+CAP_PERFMON (já privilegiado). Não é um escalonamento de privilégio. Impacto: evasão de política + cegueira de auditoria.
LID-002Alta — security_file_receive() nunca dispara, transferência de fd invisível para todos os LSMsAlta — funciona a partir de userspace não privilegiado via io_uring. Cruza o limite de aplicação do LSM sem qualquer privilégio.
LID-003Alta — security_sb_mount() ignorado, política de montagem do AppArmor é código mortoMédia — requer acesso ao namespace de montagem (CAP_SYS_ADMIN em user ns). Disponível em muitas configurações de contêiner.
LID-004Crítica — AppArmor não vê nada, zero hooks BPF (0/9), nenhum rastro de auditoria para qualquer operação de token BPFMédia — requer delegação de bpffs pelo host + CAP_BPF em user namespace. Disponível em runtimes de contêiner com delegação BPF (LXD/Incus).
LID-005Média — classificadores tc de egress em interface de contêiner nunca avaliam tráfego AF_XDPLimitado — ignora tc egress na eth0 do contêiner (verificado). Cilium NÃO é ignorado — aplica no ingresso veth do lado do nó + verificação de IP de origem (testado). Impacto limitado a configurações Docker simples com filtragem egress apenas tc.
CondiçãoObrigatórioObservações
Versão do kernel5.x+Testado em 5.15, 6.1, 6.6, 6.8
CONFIG_BPF_SYSCALL=yPadrão em todas as principais distros
CONFIG_BPF_KPROBE_OVERRIDE=yUbuntu/Debian habilitam, RHEL não
CONFIG_SECURITY_APPARMOR=yLSM alvo deve ser AppArmor
Perfil AppArmorEm enforcing, regra de negação no caminho alvoFunciona com qualquer regra de negação baseada em caminho
Privilégiosroot ou CAP_BPF + CAP_PERFMONNão pode ser executado sem privilégio
kernel.lockdownnone ou integrityModo confidentiality bloqueia anexação de kprobe
kernel.unprivileged_bpf_disabledIrrelevanteRequer CAP_BPF independentemente
fs.protected_hardlinks0 para links entre usuários1 (padrão) ainda permite hard links do mesmo usuário
SELinux em vez de AppArmorNão funcionaSELinux é baseado em inode, não em caminho
CondiçãoObrigatórioObservações
Versão do kernel6.0+IORING_MSG_SEND_FD adicionado em 6.0
CONFIG_IO_URING=yPadrão em todas as principais distros
PrivilégiosNenhumFunciona a partir de userspace não privilegiado
sysctl io_uring_disabled0 (padrão)2 bloqueia não privilegiado, 1 bloqueia todos
LSM alvoQualquer (SELinux, AppArmor, Smack)security_file_receive() é um hook LSM genérico
kernel.lockdownIrrelevanteNenhum BPF envolvido
CondiçãoObrigatórioObservações
Versão do kernel6.9+Token BPF introduzido em 6.9
CONFIG_BPF_SYSCALL=yPadrão em todas as principais distros
CONFIG_SECURITY_APPARMOR=yPadrão Ubuntu/Debian
bpffs com delegaçãoSimHost deve montar com opções delegate_*
PrivilégiosCAP_BPF em user namespaceTrivialmente disponível para root de userns
SELinux em vez de AppArmorNão afetadoSELinux implementa todos os 9 hooks BPF
CondiçãoObrigatórioObservações
Versão do kernel5.2+fsopen/fsmount introduzidos em 5.2
CONFIG_SECURITY_APPARMOR=yApenas AppArmor é afetado
PrivilégiosCAP_SYS_ADMIN em user namespaceDisponível com unshare -m
SELinux em vez de AppArmorNão funcionaSELinux implementa security_sb_kern_mount()
Runtime de contêinerDepende do filtro seccompSeccomp padrão do Docker bloqueia fsopen — Podman/LXC podem não bloquear
CondiçãoObrigatórioObservações
Versão do kernel4.18+AF_XDP introduzido em 4.18
CONFIG_XDP_SOCKETS=yPadrão em todas as principais distros
PrivilégiosApenas CAP_NET_RAWPadrão em Docker, pods Kubernetes
Runtime de contêinerDocker, K8s, LXCConjunto de capacidades padrão
Política de rede baseada em tcSimCilium eBPF, Calico, tc u32/flower
AmbienteLID-001LID-002LID-003LID-004LID-005
Ubuntu 22.04+ (AppArmor, padrão)FuncionaFuncionaFuncionaFunciona (6.9+)Funciona
Debian 12+ (AppArmor)FuncionaFuncionaFuncionaFunciona (6.9+)Funciona
RHEL/Fedora (SELinux)NãoFuncionaNãoNãoFunciona
lockdown=confidentialityNãoFuncionaFuncionaParcialmenteFunciona
Usuário não privilegiadoNãoFuncionaDepende de user nsDepende de delegação bpffsNão
Contêiner (sem CAP_BPF)NãoDepende de io_uringDepende de seccompNãoFunciona
Contêiner (CAP_NET_RAW removido)NãoDependeDependeNãoNão
IDVetorAlvoO que Acontece
LID-001Reescrita de caminho via eBPF kprobeAppArmorkprobe reescreve o nome do arquivo antes de copy_from_user → AppArmor verifica caminho errado
LID-002io_uring MSG_RING SEND_FDSELinux, AppArmor, SmackTransferência de fd ignora security_file_receive() — toda outra transferência de fd chama
LID-003Nova API de montagem (fsopen/fsmount)AppArmorsecurity_sb_mount() nunca é chamada — único hook de montagem do AppArmor ignorado
LID-004Delegação de token BPFAppArmor, SmackZero hooks BPF — criação de token, uso, delegação de capacidade completamente invisíveis
LID-005AF_XDP __dev_direct_xmittc egress, Cilium, CalicoTX em modo de cópia do Docker padrão ignora classificadores tc — pacotes falsificados alcançam a bridge
IndicadorVisibilidadeNotas
Registro de auditoria do AppArmorNadaNegação nunca ocorre
auditd / journaldNadaNenhum evento de segurança gerado
dmesgAviso únicoMensagem genérica bpf_probe_write_user
bpftool prog listVisívelMostra kprobe anexado (se verificado)
Link físico no discoDetectávelfind -samefile (lento, ruidoso)
MitigaçãoEficáciaCompensação
kernel.lockdown=confidentialityBloqueia BPF completamenteMata monitoramento legítimo
Desabilitar bpf_probe_write_userPrevine reescrita de caminho LID-001Requer reconstrução do kernel
fs.protected_hardlinks=1Limita criação de links físicosPadrão em kernels modernos
Monitorar bpftool prog listDetecta probes anexadasRequer polling ativo
Migrar para SELinuxBaseado em inode, derrota reescrita de caminhoMigração complexa
Restringir io_uringBloqueia LID-002Pode quebrar aplicações
DescobertaKernel MínimoPrivilégiosAlvo
LID-0015.x+root / CAP_BPF+CAP_PERFMONApenas AppArmor
LID-0026.0+NenhumQualquer (SELinux, AppArmor, Smack)
LID-0035.2+CAP_SYS_ADMIN (user ns ok)Apenas AppArmor
LID-0046.9+CAP_BPF (user ns ok)AppArmor, Smack
LID-0054.18+CAP_NET_RAW (Docker default)tc egress (Cilium, Calico, etc.)