Copy Fail – CVE-2026-31431

 (copy.fail)
9P by GN⁺ | ★ favorite | 댓글 5개
  • 2017년 이후 모든 리눅스 배포판에서 root 권한을 획득할 수 있는 컨테이너 탈출 권한 상승 취약점
  • 리눅스 커널의 암호화 모듈(authencesn)에 존재하는 단순한 로직 결함을 이용하며, 복잡한 타이밍 맞추기(레이스 컨디션)나 커널 버전별 조정 없이 732바이트짜리 Python 스크립트 하나로 실행 가능
  • 핵심 원리는 리눅스가 파일을 실행할 때 참조하는 메모리 내 캐시(페이지 캐시)를 변조하는 것으로, AF_ALG(커널 암호화 소켓)과 splice()(데이터 복사 시스템콜)를 연결해 setuid 바이너리의 캐시 사본에 4바이트를 덮어씀
    • 실제 디스크의 파일은 변경되지 않아 포렌식 디스크 이미지에 흔적이 남지 않는 스텔스 공격
    • 재부팅하거나 메모리가 해제되면 캐시가 원본으로 돌아가므로, 전통적인 파일 무결성 검사로는 사후 탐지가 어려움
  • 페이지 캐시는 호스트 전체에서 공유되기 때문에, Kubernetes 환경에서 하나의 파드가 이 취약점을 이용하면 호스트 노드를 장악하고 다른 테넌트의 컨테이너까지 침범하는 컨테이너 탈출이 가능
  • Ubuntu 24.04, Amazon Linux 2023, RHEL 10.1, SUSE 16에서 직접 검증되었고, 비특권 로컬 사용자 계정만 있으면 네트워크 접근이나 커널 디버깅 기능 없이 즉시 동작
  • 기존 리눅스 권한 상승(LPE) 취약점들은 시도당 30~80% 성공률에 특정 커널 범위에서만 동작하지만, Copy Fail은 단일 시도 100% 성공률로 9년간(2017~2026) 전 배포판이 대상
  • 같은 페이지 캐시 변조 계열인 Dirty Pipe(파이프 버퍼 플래그 악용)·Dirty Cow(타이밍 경쟁 필요)와 달리, 레이스 컨디션 없음·배포판별 오프셋 없음·재컴파일 불필요라는 점에서 훨씬 단순하고 강력
  • 가장 시급한 대상: 멀티테넌트 리눅스 호스트, Kubernetes/컨테이너 클러스터, CI 러너(GitHub Actions 셀프호스팅, GitLab 러너 등), 사용자 코드를 실행하는 클라우드 SaaS — 신뢰할 수 없는 코드가 공유 커널 위에서 실행되는 모든 환경
  • 최우선 조치는 커널 패치(메인라인 커밋 a664bf3d603d) — 2017년에 도입된 암호화 모듈의 인플레이스 최적화를 되돌려, 페이지 캐시 페이지가 암호화 연산의 쓰기 대상에 포함되지 않도록 수정
  • 패치 전 임시 조치로 algif_aead 모듈 비활성화 가능하며, dm-crypt/LUKS·kTLS·IPsec·SSH 등 일반적인 암호화 기능에는 영향 없음
  • 컨테이너·샌드박스·CI 러너 등 신뢰할 수 없는 워크로드 환경에서는 패치 여부와 무관하게 seccomp으로 AF_ALG 소켓 생성을 차단하는 것을 권장
  • Xint의 Taeyang Lee가 "splice()가 페이지 캐시 페이지를 암호화 서브시스템에 넘기는 구조가 미개척 버그 클래스"라는 초기 통찰을 도출하고, Xint Code가 커널 crypto/ 서브시스템을 약 1시간 만에 자동 스캔하여 발견한 AI 보조 취약점 탐지 사례
GeekNews Weekly에 포함된 글입니다. 에디터 코멘트 보기

함께 보면 좋은 글 β

popopo   [-]

Rocky Linux 는 아직 패치 안 나온듯 하네요

RHEL

Almalinux

Rocky Linux

Rock Linux 사용 중인데 리부팅 못한다면 https://github.com/wgnet/wg.copyfail.patch 의 bpftool 로 차단이 유효합니다.

답변달기
popopo   [-]

https://kb.ciq.com/article/rocky-linux/rl-cve-2026-31431-mitigation

패치가 있긴 한데... 구독 서비스 저장소만 제공 되고 있습니다. CE 버전은 패치 안 됨. (9.7, 10.1 확인)

답변달기
popopo   [-]

2026-05-05 패치 나왔습니다.

2026-05-10 새로운 보안 옵션이 있습니다.
https://forums.rockylinux.org/t/…

sudo dnf --enablerepo=security update

보안 저장소를 추가하면, RHEL 소스 반영과는 별도로 보안 조치가 가능한 모양입니다.

답변달기
sukso96100   [-]

우분투 사용하시는 분들은 조치 방법 가이드가 나와서 참고하시면 될듯 합니다.

https://discourse.ubuntu.com/t/…

답변달기
GN⁺   [-]
Hacker News 의견들

  • Linux 커널 crypto 코드를 다루는 입장에서, 주기적으로 터지는 AF_ALG 익스플로잇은 정말 답답함
    AF_ALG는 충분한 리뷰 없이 오래전에 커널에 들어갔고, 구조가 너무 복잡한 데다 비특권 userspace 프로그램에 거대한 공격 표면을 열어줌
    게다가 거의 불필요함. userspace에는 이미 자체 암호화 코드가 있고, 커널 crypto 코드는 원래 dm-crypt 같은 커널 내부 사용처를 위한 것임
    이번 익스플로잇의 authencesn도 사실상 IPsec 내부 구현 디테일인데, 이걸 범용 userspace 암복호화 API로 노출한 건 애초에 잘못됐다고 봄
    Linux 커널 설정을 관리한다면 모든 CONFIG_CRYPTO_USER_API_* 옵션을 끄는 걸 강하게 권장함
    그렇게만 했어도 이번 버그뿐 아니라 과거와 미래의 AF_ALG 버그 상당수는 악용 불가능했을 것임
    혹시 userspace 프로그램이 깨진다면 userspace crypto 코드로 옮기도록 돕는 편이 맞고, 실제로 이미 그렇게 바뀐 것도 있음
    애초에 AF_ALG는 익스플로잇 말고는 쓰임새가 많지 않았음
    예전엔 이런 userspace API가 그럭저럭 용납됐을지 몰라도, syzbot이나 LLM 보조 버그 탐지가 있는 지금은 더는 버티기 어려움

    • AF_ALG가 뭔지 몰라서 찾아보니 https://www.chronox.de/libkcapi/html/ch01s02.html이 나오고, 거기엔 나름의 존재 이유가 적혀 있었음
      커널 모드에서만 접근 가능한 하드웨어 가속기를 userspace에서 쓰게 해준다는 점, 키를 애플리케이션 메모리에 오래 남기지 않고 커널에 넘길 수 있다는 점, 임베디드처럼 메모리가 빠듯한 환경에서 userspace crypto 라이브러리보다 footprint를 줄일 수 있다는 점이 근거로 제시됨
      이게 충분히 좋은 정당화인지는 판단 못 하겠지만, 최소한 이유 자체는 있긴 함
    • 이게 대체 어떻게 커널에 들어갔는지 궁금함
      Linus가 커널에 뭐 넣을지 꽤 까다로운 편으로 알려져 있어서, 이런 API가 들어간 배경은 흥미로운 이야기일 듯함
    • AF_ALG는 커널 crypto API를 파일 디스크립터로 노출하는 Linux 소켓 인터페이스임
      해시와 암호화를 일반적인 read(2)/write(2) 호출로 다루게 해줌
    • 이 커널 옵션을 끄면 어떤 소프트웨어가 깨지는지가 가장 궁금함

  • 공개 과정에서 뭔가 혼선이 있었던 듯함
    벤더들이 이 취약점을 심각하게 다루지 않고 있고, 그래서 여러 배포판에서 아직 패치가 안 된 상태로 남아 있음
    https://access.redhat.com/security/cve/cve-2026-31431에는 "Moderate severity", "Fix deferred"로 적혀 있었고, Debian, Ubuntu, SUSE 추적 페이지도 비슷하게 보였음

    • 패치가 커널에 들어간 시점부터 이미 몇 주 전부터 공격자나 관찰자에게는 사실상 알려진 상태였음
      그런데 upstream이 이걸 취약점으로 명확히 커뮤니케이션하지 않았고, Linus와 Greg는 커널에서 그런 분류 자체를 개념적으로 크게 중시하지 않는 편임
    • 배포판들이 중간 위험도로 보는 이유는 원격 코드 실행이 아니라 로컬 접근이 필요하기 때문인 듯함
      그래도 로컬에서 root 권한 상승이 가능하니 일반적으론 높은 우선순위로 보는 게 맞아 보임
      https://ubuntu.com/security/cves/about#priority
    • RedHat은 지금은 Important severity와 Affected로 바꿔 둔 상태임
    • Ubuntu 자체 가이드라인을 보면 이건 high priority로 가야 맞아 보이는데, 실제 표기는 medium이라 일관성이 없어 보임

  • 어느 커널 버전이 취약하고 어느 버전에서 패치됐는지가 본문에 바로 안 적혀 있는 건 아쉬움
    특히 이건 builtin 모듈이라 rmmod로 쉽게 뺄 수도 없어서 더 그럼
    Fedora 44의 kernel 6.19.14가 취약한지 확인하려고 찾아보다가 linux-cve-announce 메일링리스트 글 https://lore.kernel.org/linux-cve-announce/2026042214-CVE-2026-31431-3d65@gregkh/T/#u를 찾았음
    거기엔 6.18.22, 6.19.12, 7.0에서 각각 해당 커밋으로 수정됐다고 적혀 있어서 참고가 됨

  • 권장된 완화책대로 커널 모듈 algif_aead 를 modprobe 설정으로 막았는지 확인하고 싶다면, 난독화된 셸 코드를 통째로 돌릴 필요는 없음
    아래처럼 Python 몇 줄로 모듈이 실제 로드되는지만 읽기 좋게 확인할 수 있음
    python3 -c 'import socket; s = socket.socket(socket.AF_ALG, socket.SOCK_SEQPACKET, 0); s.bind(("aead","authencesn(hmac(sha256),cbc(aes))")); print("algif_aead probably successfully loaded, mitigation not effective; remove again with: rmmod algif_aead")'
    완화가 제대로 적용됐다면 modprobe algif_aead도 에러로 실패해야 함

  • 영향을 받는 운영체제에서 완전 자율 AI 에이전트를 일반 사용자 권한으로 돌리는 사람은 아무도 없겠지
    제로데이 프롬프트 인젝션과 결합되면 꽤 재앙적일 수 있음

    • 내 에이전트는 이미 root로 실행 중이라 문제를 못 보겠음
    • 다행히 우리가 curl | sh로 설치하는 걸 업계 표준처럼 만들진 않았지

  • LPE는 local privilege escalation 뜻임
    보안 쪽 약어가 너무 많고, 문맥으로 유추는 가능했지만 그래도 처음엔 풀어서 써줬으면 좋겠음

    • LPE는 보안 커뮤니티 안에서는 꽤 널리 알려진 약어라서, 안 풀어 썼다고 아주 심하다고 보긴 어려움
      다만 더 넓은 독자를 상대로 쓴 글이라면 명시적으로 정의해 주는 편이 좋다는 데는 동의함
      게다가 이 글 전체가 AI 생성물처럼 보이기도 함
    • 넓은 독자를 위한 글쓰기라면 약어를 먼저 풀어 쓰는 게 기본인데, LLM들은 이런 가이드를 잘 따르지 않는 편임

  • 이건 좀 웃김
    페이지엔 RHEL 14.3에서 동작한다고 적혀 있는데, 그런 버전은 존재하지 않음
    현재 RHEL은 10.x라서 무슨 TARDIS라도 탄 줄 알았음

  • RHEL 9/10에서는 algif_aead가 모듈이 아니라 builtin이라 unload할 수 없었음
    그래서 차선책으로 systemd를 통해 AF_ALG를 막는 방법을 찾았고, 노출된 서비스마다 drop-in이 필요함
    보통 핵심인 sshd와 user@를 다루는 Ansible 플레이북도 있음
    https://gist.github.com/m3nu/c19269ef4fd6fa53b03eb388f77464da

    • RHEL 9/10에서는 initcall_blacklist=algif_aead_init 를 커널 부트 옵션에 넣고 재부팅하는 방법도 가능했음
      그렇게 하니 익스플로잇이 더는 동작하지 않았음
    • 나도 비슷한 방향을 떠올렸지만, 서비스마다 막는 건 두더지 잡기처럼 느껴짐
      cronjob, slurmjob 같은 다른 실행 경로는 어쩔지 걱정되고, 개별 서비스마다 넣는 대신 systemd 차원에서 전체 프로세스가 상속받게 만드는 방법이 있으면 좋겠음

  • 이 익스플로잇은 SUID 바이너리를 바꿔치기해서 PID 0으로 실행되게 만드는 방식 같음
    그런데 사이트는 Kubernetes / container clusters, CI runners & build farms 탈출까지 된다고 주장하면서도, 실제로 컨테이너나 특히 user namespace 탈출을 뒷받침하는 설명은 안 보임
    rootless Podman에서 돌려보니 예상대로 컨테이너를 빠져나오지 못했음
    또 "2017년 이후 출시된 모든 Linux 배포판을 root로 만든다"는 주장도 했지만, 실제 테스트는 네 개뿐이고 Alpine에서는 동작하지 않았음

    • 사이트 쪽에서도 자세한 설명은 곧 올라올 거라고 했으니, 아마 추가 단계나 수정사항이 part 2에서 나올 듯함
      "Next: "From Pod to Host," how Copy Fail escapes every major cloud Kubernetes platform."라고 예고해 둠
    • 이 취약점은 읽을 수 있는 파일의 메모리 바이트를 덮어쓸 수 있으니, 여러 환경을 탈출할 여지는 충분히 상상 가능함
    • 2017 이후 전 배포판이라는 주장은 이 취약점이 2017년 하반기 커밋에서 들어왔다는 사실에 기반한 것 같음
      https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=72548b093ee3
      다만 실제 악용 가능성은 최신 메이저 릴리스인지, 오래된 브랜치의 유지보수 커널인지에 따라 달라질 것임
    • 이 글은 스스로 신뢰도를 꽤 깎아먹었음
      그래도 PoC를 24.04 인스턴스에서 직접 돌려보니 취약점 자체는 진짜 같고, 충분히 큰 이슈처럼 보임
      다만 영향받는 배포판 수는 주장보다 훨씬 적어 보이고, 2017년 이후 모든 배포판이라는 표현과는 거리가 큼
      예를 들어 Ubuntu는 내 해석이 맞다면 16.04 EOL에도 약간 영향이 있고, 실제 주요 영향은 최근 배포하기 시작한 vendor 커널인 linux-gcp, linux-oracle-6.7 같은 6.17 계열 쪽으로 보임
    • rootless 컨테이너 안에서라도 실제 UID 0까지 올라갈 수 있으면 그다음 탈출은 가능함
      다만 추가 단계가 필요하고, Alpine도 근본 취약점은 있을 수 있지만 스크립트 조정이 필요한 것뿐일 수 있음
      결국 이건 완성형 범용 익스플로잇이 아니라 PoC임

  • 페이지 자체는 좀 vibecoded 같고 광고 티도 나지만, 취약점은 실제고 위험도도 높아 보임
    오늘 큰 보안 업데이트가 왜 왔는지 설명이 되니, 업데이트 우선순위를 높여야겠음

    • 이건 꽤 노골적인 광고이긴 한데, 개인적으론 나쁘지 않은 광고라고 봄
      실제 버그를 찾아내고 패치하는 식으로 OSS 생태계에 의미 있는 기여를 하면서, 동시에 자기네 보안 도구를 파는 구조임
    • 이 사람들은 굳이 광고가 없어도 이미 일감이 넘칠 것 같음
      다만 누가 요즘 웹페이지를 손으로 일일이 만드나 싶고, 특히 커널 개발자라면 더 그럴 듯함
답변달기