autofs-cve-2026-84568

Notas de engenharia reversa e PoC funcional para CVE-2026-84568, uma violação de limite de confiança do automountd do macOS que permite montagens a partir de localhost ou do próprio hostname da vítima.

Por que este writeup existe

O aviso da Apple para CVE-2026-84568 documenta o impacto e a versão da correção. Ele não documenta o mecanismo técnico:

• Qual função foi corrigida
• O que a verificação realmente faz
• Por que o RCE descrito no aviso não é alcançável através dos caminhos testados aqui

Nenhum writeup técnico público foi encontrado no momento da escrita. Este repositório preenche essa lacuna com uma análise independente de engenharia reversa de automountd_26.6 e automountd_27, e um PoC funcional para a violação de fronteira de confiança subjacente.

Isto não é uma reivindicação de descoberta. O CVE foi reportado por Mr.Gedik e corrigido pela Apple. A contribuição aqui é a análise técnica e a reprodução.

Resumo da vulnerabilidade

O automountd busca mapas de automount de um serviço de diretório configurado (LDAP, NIS, OpenDirectory). Na versão vulnerável (26.6 e anteriores), o automountd não validava se o componente de host de uma entrada de mapa resolvia para a máquina local.

Um servidor de diretório malicioso poderia, portanto, servir uma entrada de mapa cuja origem de montagem era:

• a string literal localhost
• o próprio hostname da vítima (<hostname>.local)
• qualquer endereço IP local, incluindo 127.0.0.1

A vítima então montaria a partir de si mesma em um ponto de montagem controlado pelo atacante.

A versão corrigida (26.7 / 27) adiciona uma verificação de hostname em sym.func.100005bd8 que rejeita entradas que correspondam a qualquer um dos itens acima.

O que este repositório contém

Engenharia reversa

• Diff de desmontagem de sym.func.100005bd8 entre automountd_26.6 e automountd_27 — veja docs/PATCH_DIFF.md
• Identificação da verificação corrigida: strncasecmp contra "localhost", gethostname(), SCDynamicStoreCopyLocalHostName + ".local", e um loop getifaddrs / getipnodebyaddr enumerando todos os IPs locais
• Rastreamento do campo fstype através de parse_nfs → mapline_to_mapent → asprintf("%s/mount_%s", "/sbin", fstype) — o campo não é validado antes de construir o caminho do programa
• Análise do callback SAX do parser XML do webdavfs_agent — o callback characters usa __memcpy_chk com verificações explícitas de comprimento; sem overflow
• Análise de od_process_record_attributes — o parser de registros do OpenDirectory usa APIs CoreFoundation em todo o código; sem buffers de tamanho fixo
• Auditoria dos programas de montagem — mount_nfs, mount_smbfs, mount_url e todos os bundles NetFSPlugins/* verificados quanto a execução de shell; nenhum encontrado

Veja docs/ANALYSIS.md para o writeup completo e docs/ARTIFACTS.md para endereços e amostras de log.

Reprodução

• poc.sh — uma configuração do lado do atacante em arquivo único. Inicia um servidor LDAP com um mapa malicioso auto_master / auto_evil e uma exportação NFS com um marcador de prova de acesso. Quando o automountd da vítima busca o mapa, ele monta sua própria exportação NFS no caminho controlado pelo atacante.

O que este PoC demonstra

• Um servidor LDAP malicioso servindo um mapa auto_master / auto_evil elaborado
• O automountd da vítima buscando o mapa pela rede
• A vítima montando sua própria exportação NFS em um caminho controlado pelo atacante
• A origem da montagem na tabela de montagem do kernel é 127.0.0.1

O que este PoC NÃO demonstra

• Execução de código arbitrário
• Escalação de privilégios
• Um shell na vítima

O impacto de "execução de código arbitrário com privilégios de root" no aviso da Apple não é alcançável através dos caminhos testados nesta análise. Veja a seção "Caminhos testados e descartados" em docs/ANALYSIS.md para a lista completa.

O impacto demonstrado é a violação de fronteira de confiança em si: a vítima monta a partir de uma origem que deveria ter rejeitado.

Estrutura do repositório

Quatro arquivos, dois diretórios. Nada mais.

Requisitos

Host atacante (macOS)

• Homebrew
• OpenLDAP (brew install openldap)
• slapd.conf definindo: database mdb com suffix "dc=evil,dc=local"
• Servidor NFS (nfsd) — vem com o macOS
• Acesso root (para slapd, nfsd, /etc/exports)

Host vítima

• macOS 26.6 ou anterior (automountd vulnerável)
• Configurado para consultar o servidor LDAP do atacante em busca de mapas de automount
• +auto_master presente em /etc/auto_master
• nfsd em execução na vítima, exportando um diretório

A vítima precisa de um servidor NFS em execução para que a montagem seja bem-sucedida. O CVE é sobre a aceitação da entrada de host local, não sobre a entrega da exportação. Se a vítima não executar o nfsd, a montagem falha com NFS server 127.0.0.1 not responding — o que ainda demonstra que o automountd aceitou a entrada.

Uso

Atacante

Substitua <ATTACKER_IP> pelo IP do atacante conforme visto pela vítima.

Vítima

Resultado esperado

O arquivo proof.txt é legível através da montagem. A origem da montagem na saída de mount é 127.0.0.1:<export_dir>:

A presença de nodev e nosuid reflete os padrões de montagem NFS do kernel e o próprio tratamento de opções do mount_nfs — eles não vêm do automountd. Veja docs/ANALYSIS.md para a análise completa.

Verificação do patch

Em um sistema corrigido (26.7 / 27), a mesma entrada de mapa é rejeitada antes de qualquer tentativa de montagem. Veja docs/PATCH_DIFF.md para a comparação de desmontagem de sym.func.100005bd8.

Para confirmar em um host corrigido:

Esperado: o ponto de montagem não é criado, e nenhuma entrada aparece na saída de mount. A verificação sym.func.100005bd8 rejeita a entrada quando o host é 127.0.0.1, localhost ou o hostname local.

A injeção de fstype (achado separado)

Durante a análise, uma fraqueza separada de defesa em profundidade foi encontrada: sym.func.1000086f4 (run_mount_cmd) constrói um caminho de programa via asprintf("%s/mount_%s", "/sbin", fstype) sem validar o campo fstype da entrada de mapa.

Sequências de path traversal em fstype alcançam a chamada asprintf:

Em uma instalação padrão do macOS, o caminho resultante não resolve para um executável porque /sbin/mount_.. não existe. A injeção é real, mas bloqueada pela resolução de caminho. Ela se tornaria explorável apenas se existisse um caminho gravável sob /sbin, ou se um symlink de diretório mount_<X> fosse criado — nenhuma das duas condições se aplica ao macOS padrão.

Isto é documentado como uma observação separada, não como parte do CVE-2026-84568. Veja docs/ANALYSIS.md para detalhes.

Créditos

• Descoberta original: Mr.Gedik (@h4ck2s3c) da Turkish Technology, conforme o aviso de segurança da Apple para CVE-2026-84568.
• Análise independente e PoC: jvidhan
• Referência: O aviso da Apple e o binário corrigido serviram como base para comparação com a versão vulnerável.

Aviso legal

Este repositório é fornecido para pesquisa de segurança defensiva e educação apenas.

• Ele é destinado ao uso contra sistemas que você possui ou tem permissão escrita explícita para testar.
• Usar esta ferramenta contra sistemas que você não possui ou controla pode violar leis locais, nacionais ou internacionais.
• O(s) autor(es) não assumem nenhuma responsabilidade ou obrigação por qualquer uso indevido ou dano causado por este código.
• O PoC é limitado a demonstrar uma violação de confiança de montagem. Ele não alcança execução de código. Quaisquer alegações de RCE a partir deste PoC não são sustentadas pela análise incluída.
• Apple, macOS, autofs e automountd são marcas registradas da Apple Inc. Este projeto não é afiliado nem endossado pela Apple.

Licença

MIT. Veja LICENSE.