redinpulse/cve-2026-84568CVE-2026-84568(fstype 경로 순회를 통한 루트 코드 실행) 및 CVE-2026-84570(Gatekeeper 우회)에 대한 재현 가능한 macOS automountd 실습 PoC와 소스 기반 분석입니다.
CVE-2026-84568 및 CVE-2026-84570에 대한 공개적이고 소스를 기반으로 한 분석으로, LDAP/OD 입력, NFS 전달, 헬퍼 디스패치, Gatekeeper 동작, 그리고 디바이스 노드 경계에 대한 재현 가능한 증명을 포함합니다.
게시 상태 — 2026년 10월. Apple은 2026년 9월 14일 macOS Sequoia 15.8, macOS Tahoe 26.7, macOS Golden Gate 27에서 두 취약점을 모두 수정했습니다. 이 저장소의 재현 프로그램은 의도적으로 패치되지 않은 Mac을 포함하는 격리된, 승인된 실험실에서만 사용하도록 의도되었습니다.
검증 상태. 포함된 호스트 내 검증기는 영향을 받는 macOS 26.4(빌드 25E246, arm64) 실험실 호스트에서 성공적으로 실행되었습니다. 헬퍼 디스패치 테스트, 전체 루프백 NFS 전달 체인, 경로명/자격 증명 프로브, Gatekeeper 차등 테스트, 그리고 nodev/디바이스 경계 테스트가 모두 PASS를 반환했습니다. Gatekeeper 테스트에서 평가가 활성화되었고, 앱은 구조적으로 유효했지만 Team ID 없이 ad-hoc 서명되었으며, 명시적 spctl 평가가 이를 거부했고, NFS 마운트에는 noexec도 격리도 없었으며, LaunchServices가 승인 단계 없이 이를 실행했습니다. 각 검증기는 또한 cleanup_result=PASS를 반환했으며, 독립적인 실행 후 점검을 통해 임시 디렉터리 레코드, 마운트, 파일, 그리고 /etc/exports 변경 사항이 제거되거나 복원되었음을 확인했습니다. Python 하네스는 실제 automount/Apple 속성 스키마를 갖춘 임시 OpenLDAP 서버에 대해 별도로 시험되었으며, automountKey와 apple-user-homeurl 경로 모두 생성/재판독/타임아웃/복원 점검을 통과했습니다. 이러한 관찰은 해당 영향을 받는 빌드와 포함된 하네스를 특징짓는 것이며, 패치된 릴리스에 대한 주장이 아닙니다.
연구 공로: Mr.Gedik (@h4ck2s3c); CVE-2026-84568은 Apple의 권고문에서 Mr.Gedik에게, CVE-2026-84570은 Mr.Gedik에게 공개적으로 공로가 인정되었습니다.
이것은 연구의 공개 버전입니다. Apple의 공개된 권고문, Apple의 오픈 소스 코드, 그리고 포함된 재현 가능한 실험실 자료에 의해 뒷받침되는 정보만을 포함합니다. 비공개 사례 식별자, 비공개 통신, 비공개 아티팩트, 그리고 무관한 연구는 의도적으로 제외되었습니다.
두 CVE는 공격 표면을 공유하지만 독립적인 근본 원인을 나타냅니다:
| CVE | Apple의 공개된 영향 | 클라이언트 측 경계 |
|---|---|---|
| CVE-2026-84568 | 네트워크 디렉터리 공격자가 root 권한으로 임의 코드를 실행할 수 있음 | 디렉터리가 제어하는 fstype이 automountd가 선택하는 실행 파일 경로에 영향을 미침 |
| CVE-2026-84570 | 앱이 Gatekeeper 검사를 우회할 수 있음 | 디렉터리가 제어하는 NFS automount가 애플리케이션 출처 및 디바이스 노드 정책 경계를 모두 넘음 |
Apple은 macOS Golden Gate 27, macOS Tahoe 26.7, macOS Sequoia 15.8의 보안 콘텐츠에서 두 문제를 모두 autofs 아래에 나열합니다.
macOS automount 맵은 실행 가능한 제어 데이터입니다. 맵 라인은 파일 시스템 유형을 선택하고, 마운트 옵션을 제공하며, 리소스를 식별하고, 궁극적으로 권한 있는 마운트 디스패치에 영향을 미칩니다. 2026년 9월 업데이트 이전에는 두 가지 검증 실패로 인해 디렉터리가 제공한 데이터가 클라이언트의 보안 경계를 넘을 수 있었습니다:
fstype이 의도된 /sbin/mount_<type> 헬퍼 네임스페이스를 벗어나 NFS를 통해 전달된 실행 파일로 해석될 수 있었습니다.nodev 정책을 무력화할 수 있었습니다. 결과적인 네트워크 마운트에는 noexec나 격리 정책도 없었으므로, 명시적 Gatekeeper 평가에 실패한 앱이 여전히 그곳에서 실행될 수 있었습니다.이것들은 관련된 관찰이며, 상호 교환 가능한 메커니즘이 아닙니다. nodev는 특수 디바이스 vnode가 해석되는지 여부를 제어하며, Gatekeeper를 구현하지 않습니다. noexec는 VFS 경계에서 실행을 제어합니다. Gatekeeper는 애플리케이션 신뢰와 출처를 별도로 평가합니다. CVE-2026-84570 검증기는 각 경계를 독립적으로 보고하므로, 누락된 nodev 플래그가 그 자체로 Gatekeeper 우회의 증거로 제시되는 일이 결코 없습니다.
디렉터리 쓰기 권한은 진입 전제 조건일 뿐, 그로 인해 발생하는 권한은 아닙니다. automount 또는 사용자 홈 속성을 변경하는 것은 이를 사용하는 모든 Mac에서 실행 가능한 경로명을 선택하거나 NFS 마운트의 커널 정책을 약화시키는 것과 동등하지 않습니다. 그러한 변환은 클라이언트에서 발생합니다.
stat()은 ENOTDIR을 반환했습니다. 따라서 비권한 realpath() 또는 stat() 결과는 여기서 automountd에 대한 유효한 대리 지표가 아닙니다.nodev 우회를 필요로 하지 않습니다. 전체 84568 체인은 전달 마운트가 nodev와 nosuid를 유지한 상태에서 성공했습니다.기본 automount 구성은 /home 아래에 디렉터리 기반 입력을 노출합니다:
/etc/auto_master: /home auto_home -nobrowse,hidefromfinder
/etc/auto_home: +auto_home
/etc/auto_home: +/usr/libexec/od_user_homes
첫 번째 포함은 automount 레코드를 해석합니다. 실행 파일 맵 포함은 od_user_homes를 호출하며, 이는 사용자 홈 정보를 해석하고 맵 라인을 출력합니다. 두 경로 모두 automount 파서로 수렴합니다.
공개 하네스는 두 디렉터리 형식을 명시적으로 유지합니다:
| 경로 | 디렉터리 입력 | 결과 autofs 키/값 |
|---|---|---|
automount | RDN이 automountMapName=auto_home 맵 아래의 automountKey=<key>인 RFC 2307 항목; 값은 automountInformation에 있음 | <key> → 원시 맵 라인 |
userhome | 기존 사용자 항목; 값은 apple-user-homeurl에 있음 | 사용자의 레코드 이름 키 → <home_dir><url>…</url></home_dir>로 감싼 맵 라인 |
이 구분은 운영상 중요하지만 취약한 싱크에서는 중요하지 않습니다: 두 값 모두 결국 Mac에서 파싱된 파일시스템 유형과 마운트 인수에 영향을 미칩니다.
flowchart LR
DS["LDAP / Open Directory"]
AM["AutomountInformation"]
UH["User home attribute"]
GM["getmapent_od()"]
OUH["od_user_homes"]
MAP["Automount map line"]
PARSE["parse_entry() / set_mapent_opts()"]
TYPE{"fstype"}
NFS["Dedicated NFS path"]
GENERIC["Generic helper path"]
EXEC["run_mount_cmd()"]
DS --> AM --> GM --> MAP
DS --> UH --> OUH --> MAP
MAP --> PARSE --> TYPE
TYPE -->|exactly nfs| NFS
TYPE -->|another value| GENERIC --> EXEC
관련 공개 소스 경로는 다음과 같습니다:
od_user_homes.c: 디렉터리 사용자 레코드를 확인하고 홈 URL을 출력합니다.ns_od.c: 디렉터리 automount 데이터를 가져옵니다.autod_parse.c: fstype과 마운트 옵션을 파싱합니다.autod_mount.c: 마운트 헬퍼를 선택하고 실행합니다.Apple이 공개한 autofs-322 트리는 수정 전 맥락을 파악하는 데 유용합니다. 영향을 받은 빌드에서의 런타임 동작이 여전히 결정적 증거입니다. 이 글은 공개 저장소에 2026년 9월 최종 패치 diff가 포함되어 있다고 주장하지 않습니다.
수정 전 기본 autofs.conf는 AUTOMOUNTD_MNTOPTS=nosuid,nodev를 제공합니다. 이는 Gatekeeper와 동의어가 아닌 VFS 마운트 정책입니다:
| 계층 | 의도된 결정 | 영향을 받은 빌드에서의 관찰 |
|---|---|---|
nosuid | 마운트로부터의 set-user-ID/set-group-ID 권한 상승을 무시 | 두 검증기 모두에서 유지됨 |
nodev | 마운트로부터의 문자/블록 특수 파일을 해석하지 않음 | 일반 84568 전달 마운트에는 존재했으나, 84570 테스트에서는 조작된 dev 옵션에 의해 제거됨 |
noexec | 마운트된 파일 시스템으로부터의 실행을 거부 | 테스트된 두 NFS automount 모두에 없음 |
| 파일별 격리 | com.apple.quarantine에 다운로드된 파일의 출처를 보존 | 마운트된 증명 앱과 바이너리에 없음 |
| 마운트 격리 | XNU의 MNT_QUARANTINE 정책 비트로 파일 시스템을 표시 | 테스트된 NFS automount에 없음 |
| Gatekeeper 평가 | 앱을 실행하도록 신뢰할지 결정 | 전역적으로 활성화됨. 명시적 평가는 증명 앱을 거부했지만, LaunchServices는 여전히 NFS에서 이를 실행함 |
Apple의 공개 XNU 헤더는 MNT_NOEXEC, MNT_NODEV, MNT_QUARANTINE을 별개의 플래그로 정의합니다. 이러한 계층을 분리해 두는 것이 중요합니다. 84570 증거는 정책 실패의 연쇄이며, 하나의 플래그가 다른 모든 플래그의 역할을 대신하는 것이 아닙니다.
fstype이 실행 가능한 경로명이 됨영향을 받은 헬퍼 디스패치 로직은 파싱된 파일 시스템 유형 토큰을 경로명의 일부로 취급했습니다. 단순화하면 다음과 같습니다:
path = "/sbin/mount_" + fstype;
stat(path);
posix_spawn(path, ...);
파일 시스템 식별자와 신뢰할 수 있는 헬퍼 기본 이름 사이의 경계가 누락되어 있었습니다. /와 ..를 포함하는 값은 의도된 헬퍼 네임스페이스를 벗어날 수 있었습니다.
이 저장소에서 사용하는 간결한 테스트 값은 다음과 같습니다:
fstype: nfs/../../../home/c8a/p
constructed: /sbin/mount_nfs/../../../home/c8a/p
target: /home/c8a/p
이 값은 의도적으로 정확히 nfs가 아니도록 설정되어 있어, 전용 NFS 분기가 아닌 일반 헬퍼 디스패치 경로에 도달합니다. 첫 번째 구성 요소는 순회 구성 요소가 처리되기 전에 여전히 실제 mount_nfs 헬퍼를 가리킵니다.
결정적인 연산은 권한 있는 헬퍼 디스패치 경로에서 수행되는 stat() 및 posix_spawn()입니다. 저장소의 path_resolution_probe.c는 실제 NFS 마운트된 프로브 바이너리에 대해 두 연산을 모두 반복합니다. /bin/echo나 다른 로컬 바이너리로 대체하지 않습니다. 이는 영향을 받은 호스트가 root와 일반 사용자에 대해 서로 다른 직접 조회 결과를 생성했기 때문에 중요합니다.
수정 전 파서는 fstype에 32바이트 버퍼를 사용하므로 최대 31개의 비-NUL 바이트만 남습니다. ASCII 맵 키의 경우 예산은 다음과 같습니다: