Dirty Frag: 범용 Linux LPE(로컬 권한 상승) 취약점

(openwall.com)

2P by GN⁺ 3시간전 | ★ favorite | 댓글 2개

Dirty Frag는 주요 Linux 배포판 전반에서 root 권한 획득을 가능하게 하는 범용 로컬 권한 상승 취약점으로, 책임 있는 공개 일정과 엠바고가 깨져 패치와 CVE가 아직 없음
Dirty Pipe, Copy Fail과 같은 버그 클래스의 확장으로, 결정론적 로직 버그이기 때문에 레이스 컨디션이 불필요하고 성공률이 매우 높음
취약점의 유효 수명은 약 9년이며, Ubuntu, RHEL, Fedora, openSUSE 등 주요 배포판에서 테스트 완료
기존 Copy Fail 완화 조치(algif_aead 블랙리스트)를 적용한 시스템에서도 여전히 Dirty Frag에 취약함
임시 완화책으로 배포판 패치가 나오기 전까지 취약점이 발생하는 esp4, esp6, rxrpc 모듈 제거 권고

개요

sk_buff 구조체의 frag 멤버를 오염시키는 버그 클래스로, Dirty Pipe와 Copy Fail이 속한 동일 버그 클래스의 확장
xfrm-ESP Page-Cache Write 취약점과 RxRPC Page-Cache Write 취약점을 체이닝하여 주요 리눅스 배포판에서 루트 권한 획득 가능
결정론적 로직 버그로 타이밍 윈도우에 의존하지 않으며, 레이스 컨디션 불필요
익스플로잇 실패 시에도 커널 패닉이 발생하지 않고, 성공률이 매우 높음

두 취약점을 체이닝한 이유

xfrm-ESP Page-Cache Write는 Copy Fail과 유사한 강력한 임의 4바이트 STORE 프리미티브를 제공하며 대부분의 배포판에 포함되어 있지만, 네임스페이스 생성 권한이 필요
Ubuntu는 AppArmor 정책으로 비특권 유저 네임스페이스 생성을 차단하는 경우가 있어, 이 환경에서는 xfrm-ESP Page-Cache Write를 트리거할 수 없음
RxRPC Page-Cache Write는 네임스페이스 생성 권한이 불필요하지만, rxrpc.ko 모듈 자체가 대부분의 배포판에 포함되어 있지 않음
- 다만 Ubuntu에서는 rxrpc.ko 모듈이 기본으로 로드됨
두 취약점을 체이닝하면 각각의 맹점을 상호 보완하여, 모든 주요 배포판에서 루트 권한 획득 가능

Copy Fail과의 관계

Copy Fail이 이 연구를 시작한 동기
xfrm-ESP Page-Cache Write는 Copy Fail과 동일한 싱크(sink) 를 공유하지만, algif_aead 모듈의 가용 여부와 무관하게 트리거 가능
공개된 Copy Fail 완화 조치(algif_aead 블랙리스트)를 적용한 시스템에서도 Dirty Frag에 여전히 취약

영향 범위

xfrm-ESP Page-Cache Write: 커밋 cac2661c53f3 (2017-01-17)부터 upstream까지
RxRPC Page-Cache Write: 커밋 2dc334f1a63a (2023-06)부터 upstream까지
취약점의 유효 수명은 약 9년
테스트 완료된 배포판 버전:
- Ubuntu 24.04.4: 6.17.0-23-generic
- RHEL 10.1: 6.12.0-124.49.1.el10_1.x86_64
- openSUSE Tumbleweed: 7.0.2-1-default
- CentOS Stream 10: 6.12.0-224.el10.x86_64
- AlmaLinux 10: 6.12.0-124.52.3.el10_1.x86_64
- Fedora 44: 6.19.14-300.fc44.x86_64

완화 조치

책임 있는 공개 일정과 엠바고가 깨져 어떤 배포판에도 패치가 존재하지 않음
임시 완화 조치로, 취약점이 발생하는 모듈을 제거하는 명령어 제공:
```
sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"  
```
- esp4, esp6, rxrpc 모듈을 /etc/modprobe.d/dirtyfrag.conf에 블랙리스트로 등록하고 언로드
각 배포판이 패치를 백포트한 후 해당 업데이트 적용 필요

공개 경위

linux-distros@vs.openwall.org 메인테이너들과 협의 후, 그들의 요청에 따라 Dirty Frag 문서 공개
엠바고가 외부 요인으로 깨진 상태이며, 현재 패치나 CVE가 존재하지 않음
PoC는 linux-distros와의 협의를 거쳐 정확한 정보 제공 목적으로 공개되었으며, 허가되지 않은 시스템에서의 사용 금지

▲

GN⁺ 1시간전 [-]

Hacker News 의견들

이건 근본 원인과 악용 방식이 Copy Fail과 매우 비슷함
LLM에 작업을 많이 맡기면 잃기 쉬운 것, 즉 탐색을 잘 보여주는 사례라고 봄. AI로 취약점 연구를 하면 창의성이 꽤 막히는 느낌이 듦. 질문하면 바로 답이 나오는 흐름에서는 주변에 무엇이 있는지 보지 못함. 지니처럼 정확히 요청한 것만 주고 그 이상은 없음
Copy Fail을 발견한 연구자는 수상한 점을 본 뒤 AI에 크게 의존했는데, 직접 많은 코드를 뒤졌다면 이런 쌍둥이 버그를 발견할 기회가 더 많았을 것임. 동시에 프롬프트를 조금 덜 지시적으로 넣었다면 최신 LLM도 이 버그들을 찾아줬을 것 같음. 함께 일했는데 성능이 떨어진, 꽤 특이한 부정적 시너지 사례임
- 내가 잘못 읽은 게 아니라면 비슷한 게 아니라 같은 근본 원인임. IPsec의 Extended ESN 상위 32비트 == authencesn 모듈/암호 모드 문제임
  copy.fail에서는 엉뚱한 것이 고쳐졌고, 사람들이 AF_ALG 탓으로 성급히 돌렸음
  [편집: 맞음, 같은 authencesn 문제임. https://github.com/V4bel/dirtyfrag/blob/892d9a31d391b7f0fccb... 코드에는 authencesn이 주석에만 나오지만 그래도 같은 문제임]
  [편집2: RxRPC 문제는 별개고, 여기서는 ESP 쪽을 말하는 것임]
- 후속 프롬프트로 “비슷한 종류의 버그를 찾아줘”라고 할 수도 있음. 실제 사례가 정리된 뒤에는 비슷한 버그를 찾는 게 그리 어렵지 않음
  창의성 얘기는 이해됨. 어떤 도구든 AI는 시야를 좁힐 수 있음. 워크플로를 완전히 넘기지 않고 보조로만 쓰는 건 어렵다
- 이해가 안 됨. 애초에 이 버그들을 발견한 게 LLM들임. 그런데 그 발견을 두고 취약점 발견에 LLM이 나쁘다는 신호라고 말하는 것처럼 보임
- 근거가 있는 얘기인지, 아니면 그냥 즉흥적으로 풀어낸 건지 궁금함
- AI가 발견한 것과 비슷하지만 완전히 같지는 않은 근본 취약점을 두고, AI가 탐색하지 못한다는 교훈으로 보기는 매우 어려움
  두 취약점이 하나로 같이 공개되는 경우 말고, 어떤 반사실적 상황이면 “충분히 잘 탐색했다”고 볼 수 있는지 궁금함
“엠바고가 깨졌기 때문에 이 취약점들에 대한 패치나 CVE가 없다”
링크: https://github.com/V4bel/dirtyfrag
자세한 분석: https://github.com/V4bel/dirtyfrag/blob/master/assets/write-...
중요한 부분은 이거임: “Copy Fail은 이 연구를 시작한 동기였다. 특히 Dirty Frag 취약점 체인의 xfrm-ESP Page-Cache Write는 Copy Fail과 같은 sink를 공유한다. 하지만 algif_aead 모듈 사용 가능 여부와 무관하게 트리거된다. 다시 말해 공개된 Copy Fail 완화책인 algif_aead 블랙리스트가 적용된 시스템에서도 Linux는 여전히 Dirty Frag에 취약하다”
완화책은 다음과 같지만, 직접 테스트하거나 검증하지는 않았음: “책임 있는 공개 일정과 엠바고가 깨졌기 때문에 어떤 배포판에도 패치가 없다. 아래 명령으로 취약점이 발생하는 모듈을 제거하라”
sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"
완화책 관련 대화에서는 재부팅이 필요하거나, 이미 악용된 머신에서는 위 명령 뒤에 다음을 실행해야 한다고 함: sudo echo 3 > /prox/sys/vm/drop_caches
- sudo echo 3 > /prox/sys/vm/drop_caches에서 sudo는 효과가 없음. sudo가 echo만 실행하고 실제 쓰기는 하지 않기 때문임
  그리고 머신이 이미 악용됐다면 그 정도로는 너무 늦음. 디스크 안의 무엇이든 손상됐을 수 있으니 전체 디스크 이미지를 다시 만들어야 함
- 비-sudo 셸에서 sudo echo와 리다이렉션을 저렇게 쓸 수는 없음
  echo 3 | sudo tee /proc/sys/vm/drop_caches
  또는
  sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
  그리고 /proc 오타도 고쳤음
- 참고로 echo 1 > ...로도 완화 가능함. 전부 비울 필요는 없고, 1로 페이지 캐시만 지우면 충분함
  Ubuntu 26.04에서 로컬 테스트함: 익스플로잇을 실행해 root를 얻었고, 완화책을 설정했으며, 인자 없이 su를 다시 실행하자 즉시 비밀번호 없이 root가 됐음. 이후 페이지 캐시를 비우자 su가 비밀번호를 요구함
화이트리스트에 있는 커널 모듈만 로드되게 보장하는 쉬운 방법이 필요함. 필요도 없는 모듈을 계속 블랙리스트에 넣는 데 지쳤음
다시 묻겠는데, 왜 copy.fail에서 algif_aead가 욕을 다 먹는 거임? 멍청한 건 authencesn임
authencesn은 고쳐지지 않았고, 이제 그 결과가 나온 것임. 평범한 네트워크 소켓을 통해 같은, 아마도 같은 범위 밖 쓰기에 접근할 수 있는 것으로 드러남
이걸 떠올렸으면 좋았겠지만 그러지 못했음
[편집: ESP를 통한 문제를 말하는 것임. RxRPC 문제는 내가 이해하기로는 완전히 별개임]
이게 정말 주요 배포판 전부에서 동작한다면, 메인테이너들이 얼마나 무책임한지 계속 놀라게 됨. 사용자 중 아마 0.1% 미만에게나 유용할 선택적 커널 기능이 기본으로 활성화되어 있다니, 왜 그런가?
1999년 Linux 배포판들이 기본 설치에 인터넷으로 노출된 네트워크 서비스를 수십 개씩 넣어 배포하던 관행처럼 느껴짐. 그런데 지금은 1999년이 아님
- 배포판 메인테이너가 “너에겐 필요 없을 것(YAGNI)”이라고 판단해 특정 기능을 블랙리스트에 넣는 건 꽤 큰 요구임. 누가 무엇을 쓰는지 알 수 없기 때문임. 사용자가 돌아가서 실제 원하는 것에 맞춰 빌드를 조정하는 건 언제든 가능함
  예전 Linux 초창기에 make menuconfig를 돌려 커널에 원하는 기능만 정확히 선택하던 시절이 기억남. 솔직히 그 시절로 돌아가고 싶지는 않음
  다만 여기서 쉽게 개선할 수 있는 대상은 RHEL임. RHEL은 많은 모듈을 로드 가능한 모듈로 두지 않고 커널에 직접 컴파일해 넣어서, copy fail 같은 완화책이 불가능했음. 그런 것들을 조금 줄일 수는 있지 않을까 싶음
- 사용자가 안 쓸 것 같은 구성 요소를 비활성화하면서도 시스템 사용을 엄청 어렵게 만들지 않는 방법은 없음. 이 멍청한 OS를 25년 써온 나도 뭘 하려면 무엇을 켜고 꺼야 하는지 알 방법이 없음
  Linux 배포판 메인테이너들은 지구상에서 가장 책임감 있는 소프트웨어 메인테이너들임. 보안 관행은 멍청한 프로그래밍 언어 패키지 관리자들보다 훨씬 낫고, 선별된 패키지 목록을 유지하고, 변경을 검토하고, 버그를 패치하고, 복잡한 패키징 문제를 해결하고, 수정사항을 백포트하고, 단계적 릴리스를 쓰고, 전 세계 미러로 파일을 배포하며, 모든 파일을 암호학적으로 검증함. 게다가 이 모든 걸 무료로 한다는 점도 잊으면 안 됨
- 기본으로 활성화된 게 아님. 필요할 때 로드되는 선택적 모듈임. 커널의 전체 구조가 사용자에게 필요한 핵심 기능은 컴파일해 넣고, 그 외 거의 모든 것은 필요 시 로드되는 모듈로 제공하도록 되어 있음
- 여러 면에서 모바일이 아닌 컴퓨터들은 여전히 1999년에 머물러 있음. Android는 훨씬 더 젊고 전체 스택에 강제 접근 제어를 통합할 기회가 있었기 때문에 다른 Linux 시스템보다 훨씬 안전함
- 이걸 악용하려면 컴퓨터에 직접 접근할 수 있어야 함. 악성 USB 장치이거나, 공급망 공격 또는 사용자가 기꺼이 혹은 자동으로 설치할 알려진 소프트웨어를 악용하는 식이어야 함. 더 나아가 사실상 임의의 터미널 명령을 실행할 수 있어야 하는데, 그 소프트웨어의 격리에서는 이미 엄청난 침해임
  공격자가 그걸 다 해냈다면 이미 상황은 나쁨. 이걸로 root로 권한 상승하는 건 그 시점에서 걱정거리 중 작은 축임
  아래 다른 사람이 올린 것처럼 https://xkcd.com/1200/
  사람들이 겁먹기 전에 이 취약점이 실제로 무엇인지 이해해야 함
오랜 세월 끝에 드디어 “눈이 충분히 많으면 모든 버그는 얕다”는 상태가 됐는데, 좀 별로임. 이제부터 일주일에 몇 번씩 커널 업데이트를 해야 하는 걸까?
- 누군가 집에 침입해서 어떻게든 기본 인증 정보를 찾아내고 root 접근까지 얻을 거라고 보는 건가?
엠바고가 어떻게 깨졌는지 궁금함. 유출된 건지, 아니면 제3자가 독립적으로 찾은 건지?
- 애초에 엠바고는 존재하지 않고, 존재할 수도 없음
  Linux는 오픈소스라서 보안 버그를 고치는 모든 패치가 즉시 모두에게 보임. 커널 개발 방식상 이를 우회할 방법은 없음. 사람들이 말하는 “엠바고”는, 패치 설명에 “THIS IS A LPE”라고 대놓고 쓰지 않고 입을 다물고 있으면 메일링 리스트에 “공식” 메시지가 나갈 때까지 취약점이 유출되지 않은 척할 수 있다는 꽤 멍청한 발상임
  예전에는 이 접근이 어느 정도 변호 가능했을지 몰라도, LLM 시대에는 메일링 리스트의 diff를 자동 파이프라인으로 최신 모델에 넣고 보안 이슈를 고친 패치인지 식별하게 만들 수 있으므로 멍청할 뿐 아니라 위험함
- 패치 링크가 누군가의 X 계정에 올라왔고, 다른 사람이 그걸 보고 한 시간도 안 돼 동작하는 익스플로잇을 게시했음. LLM으로 악용했을 가능성이 있지만, 빠른 전환 시간 외에는 입증된 주장은 아님
  https://x.com/encrypted_past/status/2052409822998392962
- 관계없는 제3자가 공개적으로 게시했음
Debian이 취약한지 아는 사람 있나? Debian 12와 Debian 13 머신에서 익스플로잇을 시도했지만 직접 재현하지는 못했음
- Debian 13, 즉 Trixie의 6.12.57+deb13-amd64 커널에서는 재현했지만, Debian 12 Bookworm의 6.1.0-42-amd64 커널에서는 재현하지 못했음
  Bookworm에서 Debian 패키지 보안 스트림을 쓰지 않는 사람에게는 6.1.0-42-amd64 커널이 실제로 copy.fail에 면역임. dirtyfrag에도 면역처럼 보이는 건 놀라움. 보안 스트림에서 아직 패치하지 않았다면 commit 2b8bbc64b5c2를 유지한 커널 버전을 고를 수 있음. 같은 커밋이 일부 Debian 12 커널 버전을 dirtyfrag로부터 우연히 안전하게 만들고 있을지도 모른다고 생각함
- DigitalOcean의 새 Debian 13 droplet에서 익스플로잇을 막 시도했는데 동작했음
- 완전히 최신 상태의 Debian 13에서 테스트했고 익스플로잇이 동작함. 완화책도 동작하는 것을 확인했음
ubuntu:latest 컨테이너에서 새 기본 사용자로 실행함
git clone https://github.com/V4bel/dirtyfrag.git && cd dirtyfrag && gcc -O0 -Wall -o exp exp.c -lutil && ./exp
결과: dirtyfrag: failed (rc=3)
좋은 소식임!
- 컨테이너 안에서 실행했을 때는 같은 결과가 나왔지만, 호스트에서 직접 실행하니 셸을 얻었음. 이건 익스플로잇이 컨테이너 안에서는 동작하지 않는다는 것만 보여줌. 따라서 컨테이너가 취약하지 않거나, 스크립트가 컨테이너에서 동작하려면 조정이 필요함
  copy fail은 컨테이너 탈출에 쓸 수 있으므로(https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kuber...), 익스플로잇에 약간의 변경만 필요할 것으로 추측함
- 컨테이너를 이 테스트의 신뢰할 만한 플랫폼으로 보기는 어려움. 정상적인 것이든 아니든, 컨테이너에서는 실패하는 것들이 많음

답변달기

▲

GN⁺ 3시간전 [-]

Lobste.rs 의견들

공유 Linux 서버를 관리하기엔 참 대단한 한 주였음. 그래도 이번 공개는 핵심을 바로 말해줘서 좋음
그런데 왜 완화 지침에서 다들 stderr를 숨기는지 모르겠음
수정: 이건 copy.fail에서 “영감”을 받아 4월 30일에 보고됐다니, 하루도 안 돼 발견된 건가? 인상적임
꽤 큰 공유 서버에서 sudo 권한을 가진 입장이라, 가능한 한 적은 모듈만 포함해 커널을 직접 컴파일하는 게 좋은 생각인지도 궁금함. 장단점을 깊게 따져보진 않았지만, 이번 주의 두 로컬 권한 상승 취약점 모두를 피할 수 있었을 것 같기도 함
수정2:
```
 * 2. rxrpc path  (Ubuntu fallback): if AF_ALG is sandboxed and the ESP
 *    path can't reach the page cache, fall back to the rxrpc/rxkad
 *    nullok primitive that patches /etc/passwd's root entry empty.
 *    PAM nullok then accepts the empty password during `su -`.  
```
오, 이건 setuid가 필요 없네. 포함해줘서 좋음
- 내가 유지하는 다중 사용자 시스템에서 그렇게 하고 있는데, 이번 주 로컬 root 익스플로잇 두 개를 실제로 피할 수 있었음
실행 중인 시스템에서 로드된 커널 모듈 목록을 가져와 그 시스템의 modprobe 허용 목록으로 설정하는 게 가능하고 합리적일까?
CopyFail과 DirtyFrag 모두 내가 확인한 어떤 시스템에서도 로드되지 않은 커널 모듈을 악용하는 것처럼 보였음. 그렇다면 명백히 필요 없어 보이는 모듈을 막아두면 일부 공격을 사전에 완화할 수 있지 않을까?
2026-05-07: Detailed information and the exploit for this vulnerability were published publicly by an unrelated third party, breaking the embargo.
이런 일이 어떻게 허용되는지 모르겠음. 이 정도 규모의 정보가 그렇게 신뢰하기 어려운 환경에 들어 있다는 게 정말 말도 안 되게 느껴짐
- 여기서 말한 “무관한 제3자가 공개했다”가 이 경우인지는 확실하지 않지만, 참고로 Brad Spengler가 수정 커밋이 먼저 올라온 걸 보고 커밋 메시지가 암시하는 보안 취약점을 알아챘고, 답글에서 누군가가 바이브 코딩으로 익스플로잇을 만들었음
  Linux 커밋을 지켜보던 제3자라면 누구든 같은 단서를 잡고 익스플로잇을 만들어냈을 가능성이 있음
- “무관한 제3자”라는 표현은 그 버그가 엠바고 중이라는 걸 몰랐다는 뜻처럼 들림
  여기서 “신뢰하기 어려운 환경”은 인터넷 전체이고, 사실상 격리라고 할 만한 건 별로 없음. 원래도 그랬지만 지금은 더 분명해졌을 뿐임. Apache httpd 버그가 수정되기 전에 두 번이나 재발견됐다는 Stefan Eissing의 최근 글도 참고할 만함
영향을 받는 모듈이 정말 로드될 수 없는지 테스트하는 방법이 있을까?
CopyFail 때는 처음 완화 조치를 적용하면서 실수했음. /etc/modprobe.d/ 안의 파일명이 .conf로 끝나지 않았는데, https://news.ycombinator.com/item?id=47954159 의 테스트 명령을 실행하기 전까지 알아채지 못했음. esp4/esp6/rxrpc 모듈에도 비슷한 명령이 있을까?
- 세 모듈 모두 modprobe로 로드해봤고 지난번과 같은 오류가 났음
  첨부된 개념 증명 코드도 있긴 한데, 아직 시도해보지는 않았음

답변달기

Dirty Frag: 범용 Linux LPE(로컬 권한 상승) 취약점

개요

두 취약점을 체이닝한 이유

Copy Fail과의 관계

영향 범위

완화 조치

공개 경위

함께 보면 좋은 글 β

Hacker News 의견들

Lobste.rs 의견들