dirtyfrag-arm64

arm64/aarch64 포트 버전: V4bel/dirtyfrag (CVE-2026-43284, CVE-2026-43500).

AWS Graviton에서 linux-aws 6.17.0-1013-aws 커널을 사용하는 Ubuntu 24.04.4 LTS에서 테스트했습니다(이 글을 작성하는 시점의 최신 버전).

AppArmor 우회 분석, 강화 방법, 탐지 방법을 포함한 전체 분석: linnemanlabs.com/posts/porting-dirtyfrag-arm64

⚠️ Ubuntu AppArmor userns 제한은 이 익스플로잇을 확실하게 차단하지 못합니다

Ubuntu에는 두 가지 AppArmor sysctl이 있습니다:

• kernel.apparmor_restrict_unprivileged_userns
• kernel.apparmor_restrict_unprivileged_unconfined

둘 다 제가 테스트한 표준 Ubuntu 클라우드 및 설치 프로그램 이미지에 있는 프로필을 사용해 aa-exec를 자기 자신과 연결하면 우회할 수 있습니다:

aa-exec -p crun -- aa-exec -p crun -- ./dirtyfrag_arm64 --force-esp

자세한 내용은 Ubuntu AppArmor 우회에 대한 전체 분석인 Two Hops and a Shell을 참조하세요.

arm64에서 달라진 점

업스트림 x86_64 PoC는 두 가지 익스플로잇 경로를 사용합니다. /usr/bin/su를 손상시키는 ESP/xfrm 경로와 /etc/passwd를 손상시키는 rxrpc/rxkad 폴백입니다. arm64에서는 rxrpc 경로가 커널 oops를 일으켜 사용할 수 없으며, ESP 경로는 문제없이 작동합니다.

rxrpc 크래시: flush_dcache_page

x86_64에서 flush_dcache_page()는 no-op입니다. x86은 하드웨어 일관성 있는 데이터/명령어 캐시를 갖고 있습니다. arm64에서는 실제 dcache 유지보수를 수행하고 struct page* 메타데이터를 역참조합니다. rxrpc 암호화 경로(rxkad_secure_packet -> crypto_pcbc_encrypt -> skcipher_walk_done)가 splice/vmsplice 체인을 통해 참조가 조작된 페이지에서 flush_dcache_page를 호출하면, x86_64는 조용히 건너뛰지만 arm64는 변환 오류(translation fault)를 일으키며 oops가 발생합니다:

pc : flush_dcache_page+0x18/0x58
lr : skcipher_walk_done+0xbc/0x260
     crypto_pcbc_encrypt+0xe8/0x1c8 [pcbc]
     crypto_skcipher_encrypt+0x48/0xb8
     rxkad_secure_packet+0x108/0x270 [rxrpc]
     rxrpc_send_data+0x264/0x550 [rxrpc]

제가 테스트한 arm64 시스템에서는 uid_map 쓰기를 거부하면 작동하던 ESP 경로가 사라졌습니다. 네임스페이스 자체는 여전히 생성될 수 있지만, 프로세스는 그 안에서 자신을 root로 매핑하거나 XFRM 설정에 필요한 네임스페이스 권한(namespaced capabilities)을 얻을 수 없습니다. rxrpc 폴백은 arm64에서 네임스페이스 없이 작동하는 권한 상승 경로를 제공하지 못했고, 대신 커널 oops를 일으켰습니다.

ESP 전용 동작

arm64에서는 제 테스트에서 ESP 경로만 사용할 수 있었습니다. 이 경로는 사용자 및 네트워크 네임스페이스를 생성한 다음 해당 네임스페이스 안에서 호출 사용자를 root로 성공적으로 매핑해야 합니다. 배포판 강화 조치는 다양한 방식으로 이 경로를 차단할 수 있습니다. Ubuntu는 AppArmor userns 제한을 통해 uid_map 쓰기를 거부할 수 있으며, Debian/RHEL에서는 테스트하지 않았습니다.

AppArmor: 기본적으로 차단되지만 Ubuntu에서는 우회 가능

제가 테스트한 Ubuntu 24.04 AWS 이미지에서 apparmor_restrict_unprivileged_userns=1은 새 네임스페이스 내부의 uid_map 쓰기를 거부하여 일반 SSH 셸에서의 직접적인 익스플로잇을 차단했습니다.

그러나 기본값인 apparmor_restrict_unprivileged_unconfined=0에서는 unconfined 사용자가 aa-exec를 통해 기존 complain-mode 프로필(예: runc)로 전환하여 이 제한을 우회할 수 있습니다:

aa-exec -p runc -- ./dirtyfrag_arm64 --force-esp

kernel.apparmor_restrict_unprivileged_unconfined=1을 설정하면 이 경로가 차단되며, 현재 모든 경로를 차단하는 해결책으로 널리 권장됩니다. 그러나 aa-exec를 하나 더 추가하면 그것도 우회할 수 있습니다:

aa-exec -p crun -- aa-exec -p crun -- ./dirtyfrag_arm64 --force-esp

자세한 내용은 앞서 링크한 게시물을 참조하세요.

아키텍처별 페이로드

이 익스플로잇은 페이지 캐시의 /usr/bin/su를 최소 정적 ELF로 덮어씁니다. 업스트림 PoC는 x86_64 셸코드가 포함된 x86_64 ELF를 내장하고 있습니다. 이 포트는 이를 동등한 aarch64 ELF로 교체합니다:

• ELF e_machine: EM_X86_64(62) 대신 EM_AARCH64(183)
• 셸코드: syscall 대신 svc #0을 사용하는 aarch64 명령어
• 시스콜 번호: setgid=144, setuid=146, setgroups=159, execve=221 (x86_64에서는 각각 106, 105, 116, 59)
• 고정 4바이트 명령어 폭(x86_64의 가변 길이와 대조), 결과적으로 페이로드가 약간 더 큼(~216바이트 vs 192)

빌드 및 실행

# Clone
git clone https://github.com/linnemanlabs/dirtyfrag-arm64.git

# Build
cd dirtyfrag-arm64
gcc -O0 -Wall -o dirtyfrag_arm64 dirtyfrag_arm64.c -lutil

# Run
./dirtyfrag_arm64 --force-esp

--force-esp 플래그는 rxrpc 경로를 완전히 건너뛰어 arm64 커널 oops를 피합니다.

테스트 환경

2026-05-09 기준, 사용 가능한 최신 Ubuntu 24.04 AWS 커널(6.17.0-1013-aws, 4월 24일 빌드)은 Copy Fail(CVE-2026-31431, 4월 29일 공개)과 Dirty Frag(CVE-2026-43284/43500, 5월 7일 공개) 모두에 대한 패치 없이 배포됩니다.

즉시 완화 조치

취약한 모듈을 블랙리스트에 등록하고 배포판에 맞는 시스템 강화 조치를 적용하세요.

취약한 모듈 블랙리스트 등록

IPsec 전송 모드나 AFS를 적극적으로 사용하지 않는 시스템에서는 안전합니다. 모듈이 로드되지 않도록 하려면 다음 내용을 /etc/modprobe.d/dirtyfrag.conf에 넣으세요:

install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false

initramfs 업데이트

Ubuntu는 또한 초기 부팅 중에 블랙리스트가 적용되도록 initramfs를 재생성할 것을 권장합니다:

update-initramfs -u -k all
``

### SUID 바이너리에서 읽기 권한 제거

SUID 바이너리 대상을 겨냥한 splice 기반 페이지 캐시 공격 유형을 차단합니다. 이 익스플로잇은 `splice()`를 위해 대상 파일에 대한 읽기 권한이 필요합니다. 사용자는 여전히 바이너리를 실행할 수 있습니다.

**자신의 환경과 모든 도구에서 테스트하지 않은 채 이 조치를 적용하지 마십시오.**

```bash
chmod o-r /usr/bin/su

이것은 수정 사항이 아니라 완화 조치일 뿐입니다. 권한 상승으로 이어지는 경로는 훨씬 더 많습니다.

모듈 언로드

실행 중인 시스템에서 모듈을 언로드하려면:

rmmod esp4 esp6 ipcomp4 ipcomp6 rxrpc 2>/dev/null

모듈이 언로드되었는지 확인합니다:

grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules \
  && echo "Affected modules are loaded" \
  || echo "Affected modules are NOT loaded"

페이지 캐시 비우기

페이지 캐시를 비우면 악성 콘텐츠가 제거되고 파일이 디스크에서 다시 읽히게 됩니다.

echo 3 > /proc/sys/vm/drop_caches

참고: 이 방법으로 일관되지 않은 결과를 얻은 적도 있지만, 재현을 시도할수록 예상대로 작동하고 있습니다. 이 PoC의 경우 /usr/bin/su의 md5sum을 확인하고, 일치하지 않으면 재부팅하세요.

테스트 후 정리

페이지 캐시 비우기 단계를 실행한 후, 다음으로 확인하세요:

sha256sum /usr/bin/su

# Or from package manager:

dpkg -V util-linux    # Debian/Ubuntu
rpm -V util-linux     # RHEL/Amazon Linux

사전 예방 조치

특정 CVE뿐만 아니라 이 전체 취약점 유형을 다루는 더 적극적인 자세를 원한다면, AppArmor userns 제한, 모듈 사전 로드 방지, Tetragon 기반 런타임 탐지 및 YARA 규칙에 대한 전체 분석을 참조하세요.

크레딧

• Hyunwoo Kim (@v4bel) - 원본 취약점 연구, 공개, x86_64 PoC
• SiCk - Ubuntu AppArmor 우회에 대한 bypass-pwn 연구
• Keith Linneman / LinnemanLabs - arm64 포트, flush_dcache_page 크래시 분석, AppArmor 연구, 탐지 노트

법적 고지

이 도구는 승인된 보안 테스트 및 연구 목적으로만 사용해야 합니다.

소유하지 않았거나 테스트에 대한 명시적 허가를 받지 않은 시스템에 대한 무단 사용은 불법적이고 비윤리적입니다.

라이선스

MIT. 복사하고, 가져다 쓰고, 수정하고, 배우고, 개선 사항을 저와 공유하세요. 아니면 그러지 않아도 됩니다. 코드니까 원하는 대로 사용하세요.