2026년 6월 25일, JFrog Security Research가 Linux 커널 취약점 패밀리인 DirtyFrag의 세 번째 변종을 공개했다. DirtyFrag는 네트워크 소켓 버퍼와 파일 시스템 페이지 캐시가 같은 물리 메모리를 공유하는 Linux 커널 설계에서 반복적으로 나오는 취약점 계열이다. — "DirtyClone" — 은 이 계열에서 네트워크 패킷 복제 함수 하나에서 시작해 비특권 사용자가 시스템 전체를 장악하는 경로를 열어둔다. 패치는 5월 24일에 이미 배포됐다. 그러나 작동하는 PoC가 공개된 지금, 패치를 적용하지 않은 Debian·Fedora 서버는 누구나 실행 가능한 공격에 노출됐다.
왜 DirtyClone인가
DirtyFrag 패밀리는 Linux 커널 네트워킹 스택의 단일 설계 결함에서 반복해서 나온다. 소켓 버퍼(skb)가 파일 시스템의 페이지 캐시와 같은 물리 메모리를 공유할 때, 공유 상태를 표시하는 안전 플래그(SKBFL_SHARED_FRAG)가 특정 경로에서 소실된다. 플래그가 없으면 커널이 읽기 전용 파일 데이터를 일반 네트워크 버퍼와 동일하게 취급해 덮어쓴다.
세 변종 모두 공격 결과는 동일하다. 공격자가 커널 권한으로 디스크 위의 파일을 메모리에서 직접 수정할 수 있다.
각 변종은 서로 다른 커널 경로를 타격하지만 공격 결과는 같다. JFrog는 이를 "읽기 전용 파일 캐시 메모리를 쓰기 가능한 네트워크 버퍼로 커널이 혼동하도록 유도한다"고 정의했다.
결함의 작동 방식
취약 함수는 net/core/skbuff.c의 __pskb_copy_fclone()다. 이 함수는 네트워크 패킷을 복제할 때 원본 버퍼의 SKBFL_SHARED_FRAG 플래그를 복제본에 전달하지 않는다. 이 플래그는 "이 버퍼의 물리 메모리는 파일 시스템과 공유된다"는 표시다. JFrog 분석에 따르면, 플래그 전달 누락은 예외 처리가 아닌 일반 복제 경로에서 발생하는 설계 실수로 추정된다.
플래그가 누락된 복제본은 IPsec 서브시스템으로 전달된다. IPsec은 암호화된 패킷을 처리하기 위해 소켓 버퍼의 데이터 영역에 직접 접근하는데, 플래그 없이 도착한 복제본을 일반 네트워크 버퍼로 판단해 AES-CBC 복호화 연산을 수행한다. 이 시점에 IPsec이 쓰는 물리 메모리는 파일 시스템의 페이지 캐시와 동일한 주소를 가리키고 있으므로, 파일 시스템의 페이지 캐시가 커널 권한으로 덮어쓰인다.
JFrog 분석에 따르면, 공격자는 이 과정을 통해 메모리 위의 /usr/bin/su를 수정한 뒤 root 셸을 획득한다.
공격 진입 요건은 두 가지다. CAP_NET_ADMIN 권한, 또는 비특권 사용자 네임스페이스(unprivileged_userns_clone=1 기본값)다. Debian과 Fedora는 기본 설정에서 사용자 네임스페이스를 허용하므로 로그인 계정만 있으면 즉시 취약하다. Ubuntu 22.04 LTS 이상은 패치가 배포됐고, Ubuntu 20.04 LTS 이하는 취약한 상태로 작업 중이다.
악용 전개 타임라인
패치 배포(5월 24일)와 PoC 공개(6월 25일) 사이에 약 한 달의 시간이 있었다. 이 기간 동안 배포판 패키지를 적용하지 않은 시스템이 우선 타격 대상이 된다.
탐지 관점
DirtyClone은 커널 로그에 흔적을 남기지 않는다. JFrog는 "페이지 캐시 오염은 메모리 위에서만 발생하며 파일 시스템은 수정되지 않는다"고 밝혔다. 파일 무결성 모니터링(FIM)이 /usr/bin/su 수정을 탐지하지 못하는 이유다. 감사 로그(/var/log/audit)나 dmesg에도 오류가 없다. 공격이 남길 수밖에 없는 흔적은 공격 준비 단계의 syscall 패턴이다.
ATT&CK 매핑
T1068 — Exploitation for Privilege Escalation: 커널 취약점 직접 악용
T1611 — Escape to Host: Kubernetes·컨테이너 환경에서 비특권 사용자 네임스페이스를 통해 호스트 커널에 접근하는 경로로 확장 가능 (추정). 컨테이너 내부 프로세스가 unshare(CLONE_NEWUSER)를 호출하면 호스트 커널의 동일한 취약 경로를 타격한다.
비특권 프로세스가 socket(AF_RXRPC) 또는 socket(AF_ALG) 호출 후 splice/vmsplice를 연속 실행하는 패턴이 핵심 지표다. 일반 사용자 워크로드에서 이 소켓 패밀리를 여는 경우는 거의 없다.
Sysdig는 DirtyFrag 패밀리 전체를 커버하는 Falco 런타임 정책("Dirty Frag xfrm-ESP Page Cache Poisoning LPE", "Dirty Frag RxRPC Page Cache Poisoning LPE")을 제공한다.
감사 로그에서는 프로세스 UID가 아닌 auid(감사 로그인 UID) >= 1000 조건이 유효하다. 공격자는 사용자 네임스페이스 안에서 uid=0으로 리매핑할 수 있는데, 이 경우 프로세스의 UID는 0으로 보이지만 auid는 원래 로그인 사용자의 값을 유지한다. UID 기반 필터만 사용하면 이 우회를 잡지 못한다.
공격이 남길 수밖에 없는 흔적:
비특권 프로세스의 AF_ALG 또는 AF_RXRPC 소켓 생성
unshare(CLONE_NEWUSER) 호출로 사용자 네임스페이스 생성 (auid >= 1000 조건)
vmsplice + splice 연속 호출 후 setuid 바이너리 실행 패턴
패치를 즉시 적용할 수 없는 환경에서는 kernel.unprivileged_userns_clone=0 설정으로 사용자 네임스페이스를 비활성화하거나, esp4·esp6·rxrpc 커널 모듈을 블랙리스트에 등록하면 공격 진입 경로가 차단된다.
한국 관점
KISA는 에 대한 별도 권고를 발행하지 않았다. 그러나 국내 클라우드·컨테이너 운영 환경에서 이 취약점의 파급은 직접적이다.
AWS·GCP·Azure·네이버 클라우드·KT Cloud 등 대부분의 클라우드 인프라는 Linux 커널 위에서 Kubernetes 클러스터를 운영한다. 다중 테넌트 환경에서 DirtyClone이 T1611 컨테이너 탈출로 이어질 경우, 단일 컨테이너 침해가 호스트 노드 전체 장악으로 확산될 수 있다. CI/CD 러너나 공유 개발 환경처럼 신뢰되지 않은 사용자가 워크로드를 실행할 수 있는 환경이 특히 주의가 필요하다. 이 환경들은 기본적으로 사용자 네임스페이스를 허용하고 동일한 커널을 신뢰되지 않은 프로세스와 공유하기 때문에, DirtyClone의 진입 요건을 구조적으로 충족하기 때문이다.