한국 보안 회사 티오리의 AI 코드 분석 솔루션 Xint Code가 9년 묵은 Linux 커널 LPE를 1시간 만에 발견. Copy Fail(CVE-2026-31431)과 Dirty Frag(CVE-2026-43284, CVE-2026-43500)의 작동 원리, 5단계 공격 흐름, 컨테이너 환경 위험, 행위 기반 Sigma 룰 2종 분석.
댓글은 익명으로 작성되며, 삭제 비밀번호를 설정하면 본인만 삭제할 수 있습니다. 비밀번호를 설정하지 않은 댓글은 누구나 삭제할 수 있습니다.
2017년 8월 Linux 커널에 들어간 단 한 줄짜리 in-place 최적화 가 9년 동안 모든 주요 배포판에 root 권한 상승 통로를 열어 두고 있었다. 세계 보안 전문가도, Linux 커널 메인테이너도, 어떤 정적 분석 도구도 잡지 못했던 그 결함을 2026년 4월, 한국 보안 회사 티오리(Theori) 가 자체 개발한 AI 코드 분석 솔루션 Xint Code(진트 코드) 가 단 1시간 만에 찾아냈다.
발견된 결함은 CVE-2026-31431 "Copy Fail" 이고, 같은 패턴이 Linux 커널의 다른 두 곳에도 박혀 있었다는 사실이 한 주 뒤 후속으로 드러난다. "Dirty Frag" 라는 이름으로 묶인 두 변종(, )이다. 모두 같은 발견자 Hyunwoo Kim(@v4bel) 의 보고고, 모두 권한 없는 로컬 사용자가 root로 올라갈 수 있는 결함이다.
이 글은 Copy Fail의 작동 원리부터 Dirty Frag로 확장된 패턴, 그리고 AI 코드 분석이 9년 묵은 결함을 어떻게 1시간 만에 찾을 수 있었는지를 정리한다.
Linux 커널의 사용자 공간 암호 API(AF_ALG)는 사용자 프로그램이 커널의 암호화·인증 루틴을 직접 호출할 수 있게 해주는 인터페이스다. 그중 algif_aead 모듈은 인증 암호화(AEAD: Authenticated Encryption with Associated Data) 작업을 처리한다.
문제는 2017년 8월에 들어간 in-place 최적화 였다. mainline commit 72548b093ee3이 들어가면서 페이지 캐시 페이지가 쓰기 가능 destination scatterlist에 직접 들어갈 수 있게 됐다. 입력 메모리를 출력 메모리로 재사용해 메모리 복사 한 번을 줄이는 성능 최적화였다.
| 최적화 전 | 최적화 후 (2017년 8월~) |
|---|---|
| 입력 페이지 → 임시 버퍼 복사 → 암호 처리 → 출력 페이지 | 입력 페이지 = 출력 페이지 (in-place) |
이 최적화 자체가 결함은 아니다. 결함은 "입력 페이지의 소유권을 검증하지 않고 in-place 처리 경로를 탔다" 는 점에 있다. 페이지 캐시(파일 시스템 캐시)에서 빌려온 페이지를 destination으로 받으면, 암호 처리 결과가 그대로 페이지 캐시에 쓰여 임의 파일의 캐시를 손상시킬 수 있는 통로 가 된다.
이 결함은 Linux 커널 보안 커뮤니티가 검토할 통상의 패턴에서 벗어나 있었다.
socket(AF_ALG) → bind("aead", "authencesn(...)") → splice() → recvmsg() 의 연쇄. 단일 syscall 검토로는 안 보인다티오리의 AI 코드 분석 솔루션 Xint Code는 커밋 시계열에서 "in-place 최적화 + 페이지 소유권 검증" 같은 의미적 패턴 짝(pattern pair) 을 가진 코드를 자동 매칭한다. 한 측은 도입됐는데 다른 측이 누락된 경우를 잠재 결함 후보로 띄운다.
2017년 8월 commit 72548b093ee3이 in-place 경로를 열어 줬는데, 같은 commit이나 후속 commit에서 페이지 소유권 검증을 추가한 흔적이 없었다. Xint Code는 이 비대칭을 즉시 잡았고, 사람 분석가가 1시간 안에 PoC로 검증했다.
이 발견 방식 자체가 9년 묵은 결함을 한 주 만에 추가로 두 건 더 찾는 결과로 이어졌다. 같은 in-place 최적화 패턴이 들어간 다른 영역을 자동 매칭하니, IPsec ESP의 esp4·esp6과 RxRPC 모듈에서 동일한 결함이 박혀 있었다. 이게 Dirty Frag로 묶인 와 이다.
Copy Fail을 이해하려면 세 개의 Linux 커널 구성 요소와 그들이 만나는 지점을 먼저 본다.
AF_ALG는 BSD 소켓 API를 그대로 사용해 커널의 crypto 서브시스템에 접근하는 인터페이스다. 사용자 프로그램이 OpenSSL 같은 라이브러리를 거치지 않고 커널이 가진 AES, SHA, AEAD 알고리즘을 직접 사용할 수 있다.
import socket
s = socket.socket(socket.AF_ALG, socket.SOCK_SEQPACKET, 0)
s.bind(("aead", "authencesn(hmac(sha256),cbc(aes))"))
이 인터페이스는 본래 IPsec 같은 커널 자체 사용자(예: vsyscall 가속)를 위한 것이지만, 권한 검사가 약하다. 비특권 사용자도 알고리즘 핸들을 만들 수 있다.
algif_aead는 AF_ALG 위에서 AEAD 모드를 노출하는 모듈이다. 그중 authencesn은 IPsec ESP 트래픽 처리를 위한 결합 알고리즘 템플릿으로, 인증과 암호화를 한 번에 묶는다. Copy Fail의 결함은 정확히 이 authencesn 템플릿의 in-place 처리 분기에 있다.
splice(2)는 파일 디스크립터 사이에서 데이터를 복사하지 않고 옮길 수 있게 해주는 시스템 콜이다. 파이프와 파일 사이, 또는 소켓과 파일 사이에서 페이지 단위로 참조만 옮긴다.
splice의 핵심은 zero-copy 다. 데이터를 사용자 공간으로 가져오지 않고 커널 안에서 페이지 참조만 이동시킨다. 그 결과, splice를 받은 측이 페이지 데이터를 직접 다루는 경로에서는 그 페이지가 어디에서 왔는지 가 결정적이다. 파이프 페이지일 수도, 페이지 캐시 페이지일 수도 있다.
페이지 캐시는 Linux 커널이 파일 시스템 입출력을 가속하기 위해 메모리에 보관하는 파일 데이터 사본이다. read()로 읽힌 파일은 일단 페이지 캐시에 저장되고, 같은 파일을 읽는 다른 프로세스는 디스크가 아니라 캐시에서 받는다.
여기서 결정적인 사실이 있다. 페이지 캐시는 모든 프로세스가 공유한다. root가 소유한 /usr/bin/su를 일반 사용자가 read()해도 그 데이터는 같은 페이지 캐시에 들어간다. 그 캐시 페이지의 메모리 내용을 누군가가 손상시키면, 다음으로 그 파일을 실행하는 모든 프로세스에 손상된 코드가 흘러들어 간다.
이게 2022년의 Dirty Pipe()가 활용한 통로였고, Copy Fail이 다시 활용한 통로다.
아래 5단계 흐름은 Theori 보고서와 Microsoft Security Blog의 게시물에 정리된 내용을 인용·요약한 것이다. 본 글은 운영 가능한 코드·페이로드·명령을 제공하지 않으며, 공격 표면을 이해해 탐지·완화 관점을 도출하기 위한 교육 목적의 분석이다.
공개 보고서에 따르면 Theori PoC는 단 732바이트짜리 Python 스크립트 로 보고됐다. 표준 커널 인터페이스만 쓰며, 권한 없는 컨테이너 안에서도 실행된다고 알려져 있다. 단계별 동작은 공개 보고서 기준으로 다음과 같다.
커널 버전과 영향 범위를 확인한다. 이 단계는 컨테이너 내부에서도 가능하므로, 공격자가 호스트에 직접 접근할 필요가 없다. 원격 서버에서 권한 없는 사용자 셸이나 미가공 컨테이너 RCE만 있으면 다음 단계로 넘어간다.
표준 라이브러리만으로 작동하는 Python 스크립트다. AF_ALG 소켓, splice 시스템 콜, 페이지 캐시 조작이 전부다. 외부 의존성도 없고, 컴파일러도 필요 없다. 컨테이너 환경의 최소 Python 런타임에서도 즉시 동작한다.
target은 보통 /usr/bin/su 또는 /usr/bin/sudo 같은 setuid 바이너리다. 일반 사용자가 read()로 한 번 열기만 하면 페이지 캐시에 그 바이너리의 코드가 올라온다. 그 페이지를 splice로 AF_ALG 소켓에 보낸다.
공개 보고서에 따르면, recvmsg()를 통해 in-place 복호화 fast-path가 발동되면 authencesn은 외부 소유 페이지(즉, 페이지 캐시 페이지)에 쓰기를 수행한다. 보고서는 race condition이 없어 동일 입력에 대해 결정적인 결과가 나온다고 정리한다. 손상 위치·바이트 값·패턴 같은 운영 가능한 세부 사항은 본 글에서 다루지 않는다.
공개 분석에 따르면, 손상된 /usr/bin/su 실행 시 변형된 바이트가 인증·권한 검사 분기에서 의도된 흐름을 벗어나게 만들고 그 결과 root 권한이 부여된다고 보고됐다. 구체적인 우회 메커니즘과 손상 위치는 본 글에서 다루지 않으며, 자세한 내용은 Theori 분석 보고서를 참조하면 된다.
전체 공정에 race condition이 없고 PoC 1회 실행으로 root가 나온다. 9년간 모든 Linux 배포판에 박혀 있었던 결함이고, AI가 1시간 만에 찾았다는 사실 이 가장 위험한 부분이다 — Theori 외에도 같은 코드를 분석할 수 있는 주체가 더 있다.
Copy Fail 패치(2026-04-01 mainline commit a664bf3d603d, 2017 최적화 revert) 이후, Hyunwoo Kim은 같은 in-place 최적화 패턴이 다른 곳에도 있다는 점을 추가 보고했다.
| CVE | 영향 영역 (도입 시점) | 패치 상태 (2026-05-10) |
|---|---|---|
| xfrm-ESP / esp4·esp6 (2017-01) | mainline 패치 f4c50a4034e6 | |
| RxRPC / rxrpc 모듈 (2023-06) | 미패치 |
xfrm-ESP는 IPsec 터널의 ESP 패킷 복호화 fast-path에 같은 결함이 박혀 있었다. RxRPC는 AFS 파일 시스템이 사용하는 원격 RPC 프로토콜의 복호화 경로다. 둘 다 외부 소유 페이지에 in-place 복호화 하는 동일한 안티패턴이다.
Dirty Frag가 Copy Fail보다 도달이 약간 어렵다. xfrm-ESP는 사용자 네임스페이스 생성 권한 이 필요하고, RxRPC는 rxrpc.ko 모듈이 적재돼 있어야 한다. 그러나 두 조건 모두 통상의 컨테이너·CI/CD 환경에서 충족된다.
Linux LPE 결함은 매년 여러 건 보고되지만, Copy Fail/Dirty Frag가 특별히 위험한 이유는 컨테이너 격리 가정을 무너뜨리기 때문 이다.
컨테이너 런타임(Docker, containerd, CRI-O)은 동일한 호스트 커널을 공유한다. 컨테이너 안의 root는 namespace로 격리되지만, 커널 LPE 결함이 있으면 그 격리가 무의미하다.
페이지 캐시는 더 심각하다. 호스트의 페이지 캐시와 컨테이너의 페이지 캐시는 같은 캐시 다. 컨테이너 안에서 비특권 사용자가 호스트 파일의 페이지 캐시를 손상시키면, 호스트 시스템 전체에 영향이 간다.
Microsoft Security Blog의 권고가 이 점을 직접 짚었다.
Treat any container RCE as potential host compromise and enforce rapid node recycling.
| 결함 | 트리거 조건 | PoC 크기 |
|---|---|---|
| Dirty Cow (2016) | race condition 필요, 비특권 | KB 단위 C 코드 |
| Dirty Pipe (2022) | race condition 필요, 비특권 | KB 단위 C 코드 |
| Copy Fail (2026) | race 불필요·결정적, 비특권 | 732 B Python |
| Dirty Frag (2026) | race 불필요·결정적, userns 또는 모듈 | 공개 PoC |
Copy Fail/Dirty Frag는 race condition이 없다는 점에서 공격 신뢰도 가 가장 높다. 한 번에 root가 나오지 않으면 탐지 시스템이 의심을 시작하지만, 100% 첫 시도에 root가 나오면 단일 syscall 트레이스에서 발견하기가 매우 어렵다.
Cloudflare는 결함 공개 직후 자기 인프라에서 수 분 내 에 취약점 트리거를 탐지·차단했다. 시그니처 업데이트나 룰 변경 없이, 기존 행위 기반 탐지 플랫폼이 비정상 syscall 시퀀스를 잡았다.
단기 완화책 두 가지가 운영팀에서 즉시 적용 가능하다.
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aead 2>/dev/null || true
이건 algif_aead 모듈이 로드되지 못하게 막는 설정이다. AF_ALG 인터페이스 자체는 다른 알고리즘에서 사용될 수 있으므로 모듈 단위로 차단한다. Dirty Frag 임시 완화는 esp4, esp6, rxrpc 세 모듈을 같은 방식으로 블랙리스트한다.
IOC가 회전해도 살아남는 룰. 핵심은 "비특권 프로세스가 AF_ALG 소켓을 만들고 곧바로 splice로 페이지 캐시 페이지를 보내는 시퀀스"다.
title: Copy Fail-style AF_ALG Page Cache Manipulation
status: experimental
description: 비특권 프로세스가 AF_ALG/algif_aead 소켓 생성 직후 splice로 페이지 캐시 페이지를 전달하는 시퀀스
date: 2026-05-10
logsource:
product: linux
category: process_creation
detection:
selection_socket:
syscall: socket
a0: 38
a1: 5
selection_bind:
syscall: bind
sockaddr_alg.salg_type|contains: 'aead'
sockaddr_alg.salg_name|contains:
- 'authencesn'
- 'authenc'
selection_splice_from_pagecache:
syscall: splice
fd_in_type: 'regular_file'
condition: selection_socket and selection_bind and selection_splice_from_pagecache
level: high
falsepositives:
- IPsec 정상 사용 (커널 자체 호출은 비특권 경로 아님)
- 연구·테스트 환경의 의도적 PoC 검증
title: Dirty Frag xfrm-ESP / RxRPC In-Place Decryption Trigger
status: experimental
description: 비특권 프로세스가 외부 소유 페이지 참조를 ESP·RxRPC 복호화 경로에 전달하는 패턴
date: 2026-05-10
logsource:
product: linux
category: kernel
detection:
selection_userns:
event: 'unshare'
flags|contains: 'CLONE_NEWUSER'
selection_xfrm:
syscall: sendmsg
sock_proto: 'AF_NETLINK'
netlink_family: 'XFRM'
selection_rxrpc:
module_load: 'rxrpc'
process_uid: '!=0'
condition: selection_userns and (selection_xfrm or selection_rxrpc)
level: medium
falsepositives:
- 정상 IPsec 정책 변경 (보통 root가 수행)
- AFS 파일 시스템 정상 사용
지표가 회전하면 IOC 룰은 의미가 없다. 우선순위는 행위 룰이다.
/usr/bin/su, /usr/bin/sudo 등 핵심 setuid 바이너리의 메모리 해시를 주기적으로 검증하는 인티그리티 모니터링Copy Fail과 Dirty Frag 시리즈에서 본 것은 다음 세 가지다.
첫째, 9년 묵은 커널 결함도 한 패턴이 발견되면 같은 패턴이 다른 곳에 박혀 있을 가능성이 높다. 한 주 만에 같은 발견자가 in-place 최적화 안티패턴을 가진 두 곳을 추가로 보고했다. 한 군데가 뚫리면 시리즈 전체를 의심해야 한다.
둘째, race condition이 없는 결정적 LPE는 탐지가 가장 어렵다. 한 번에 root가 나오므로 반복 시도 신호가 없다. IOC가 아닌 syscall 시퀀스 기반 행위 룰이 유일한 신뢰 가능한 신호다.
셋째, AI 코드 분석이 9년 묵은 논리 버그를 1시간 만에 찾았다는 사실 자체가 위협 모델 변경 신호다. 같은 도구를 가진 다른 주체가 같은 분석을 비공개로 수행하고 있다고 가정해야 한다. 패치 가용성과 무관하게, 모든 외부 페이지 소유권 검증 을 정적·동적 분석 룰셋에 추가하는 것이 다음 보고를 막는 가장 직접적인 조치다.
한국 환경 점검 시 살펴볼 포인트는 컨테이너 호스트 커널의 패치 상태(특히 RxRPC는 미패치 상태일 가능성), 운영 환경의 algif_aead·esp4·esp6·rxrpc 모듈 로딩 여부, 그리고 컨테이너 워크로드가 AF_ALG 소켓을 생성하는지 행위 룰로 모니터링되는지다.
72548b093ee3 (2017 도입), a664bf3d603d (Copy Fail 패치), f4c50a4034e6 (xfrm-ESP 패치)AI 활용 안내 이 글은 AI(Claude)의 도움을 받아 작성되었습니다. 인용된 통계와 사례는 참고 자료에 명시된 출처에 근거하며, 설명을 위한 일부 표현은 각색되었습니다.
면책 조항 본 글은 보안 인식 제고를 위한 교육 목적으로 작성되었습니다. 언급된 공격 기법을 실제로 시도하는 행위는 「정보통신망법」, 「형법」 등에 따라 처벌받을 수 있으며, 본 블로그는 이에 대한 법적 책임을 지지 않습니다.