Show GN: Kubernetes에서 eBPF로 Copy Fail 이슈 회피하기 완벽 가이드

CVE-2026-31431 Copy Fail — Kubernetes eBPF 방어 솔루션

Show GN: Kubernetes에서 eBPF로 Copy Fail 이슈 회피하기 완벽 가이드

CVE-2026-31431 Copy Fail — 9년간 숨겨졌던 커널 취약점의 발견

2026년 4월, 리눅스 커널에서 9년 넘게 존재해 온 치명적 버그가 공개되었습니다. CVE-2026-31431,대호 "Copy Fail"은 2017년 이후 모든 리눅스 배포판에 영향을 미치는 로컬 권한 상승(Local Privilege Escalation) 취약점입니다.

이 취약점은 놀랍도록 단순합니다. 732바이트짜리 Python 스크립트 하나로 비특권 사용자가 root 권한을 획득할 수 있습니다. 복잡한 레이스 컨디션(Race Condition)이나 커널 버전별 오프셋 조정이 필요 없습니다. 시도일회 100% 성공률이라는 점에서, 과거의 Dirty Pipe나 Dirty Cow와 비교해도 훨씬 더 강력합니다.

---

##Copy Fail은 어떻게 작동하는가

Copy Fail의 핵심 원리는 다음과 같습니다:

1. AF_ALG 소켓 생성: 공격자가 AF_ALG 커널 암호화 소켓을 개방합니다

2. splice() 시스템콜 악용: splice()로 페이지 캐시(page cache)의 데이터를 암호화 모듈로 전달합니다

3. authencesn ESN Scratch 버그 활용: 커널의 authencesn 암호화 모듈에존재하는 로직 결함을 이용해, 암호화 연산 과정에서 페이지 캐시의 특정 4바이트를 덮어쓸 수 있습니다

4. setuid 바이너리 변조: /usr/bin/sudo 등 setuid 바이너리의 페이지 캐시 사본을 변조해, 다음 실행 시root 쉘을 획득합니다

가장 무서운 점은 디스크의 실제 파일은 변경되지 않는다는 것입니다. 재부팅하거나 메모리가 해제되면 페이지 캐시가 원본으로 돌아갑니다. 이 때문에 전통적인 파일 무결성 모니터링(FIM)으로는 사후 탐지가 사실상 불가능합니다.

Kubernetes 환경에서의 위협

Kubernetes에서는 이 취약점이 더욱 치명적입니다. 페이지 캐시는 호스트 전체에서 공유되기 때문에, 하나의 파드가 호스트 노드를 장악하면:

• 호스트 노드 전체 침투

• 다른 테넌트 컨테이너까지 침범 가능

• CI/CD 러너, 멀티테넌트 클라우드 환경에서는 테넌트 간 격리 무효화

2026년 5월 1일, CISA는 CVE-2026-31431을 Known Exploited Vulnerabilities(KEV) 카탈로그에 공식 등재했습니다. 수정 마감은 2026년 5월 15일입니다. Microsoft Security Blog에서도 "이미 실제 공격 시도가 관찰되고 있다"고 보고했습니다.

---

기존 대응조시적 한계

1. 커널 패치

가장 확실한 해결책입니다. 메인라인 커널 커밋 a664bf3d603d에서 페이지 캐시 페이지가 암호화 연산의 쓰기 대상에서 제외되도록 수정되었습니다. 그러나 현실에서는:

• 패치 적용까지 수주가 걸릴 수 있음

• Fedora, Oracle Linux 등 일부 배포판에서는 커널 모듈이 빌트인(builtin)으로 컴파일되어 있어 rmmod로 제거 불가

• 재부팅이 필요하므로 운영 환경에서는 즉각 적용이 어려움

2. algif_aead 모듈 비활성화

# 모듈 로드 차단echo "install algif_aead /bin/true" >> /etc/modprobe.d/disable-algif_aead.conf# 또는 즉시 언로드sudo modprobe -r algif_aead

그러나 위에서 설명했듯이, 빌트인 커널에서는 이 방법이 통하지 않습니다.

3. seccomp 프로파일로 AF_ALG 차단

securityContext:seccompProfile:type: RuntimeDefault

하지만, Juliet의 테스트 결과에 따르면 EKS(Amazon Linux 2023)와 Talos 모두에서 PSS Restricted + RuntimeDefault 환경에서도 AF_ALG 소켓 생성은 여전히 가능했습니다. seccompProfile: Localhost로 AF_ALG 소켓 생성을 명시적으로 거부해야만 경로를 차단할 수 있습니다.

---

eBPF 기반 신규 대응방안: copyfail-ebpf-k8s

GeekNews에 이 이슈가 올라온 직후, 개발자 iwanhae님이 실제 운영 환경에서 당장 적용 가능한 도구를 만들었습니다. 바로 copyfail-ebpf-k8s입니다.

핵심 특징

특징	설명
배포 방식	단 1개 kubectl 명령으로 전체 클러스터 즉시 보호
적용 범위	DaemonSet으로 모든 노드(마스터 포함) 자동 배포
커널 모듈 의존 없음	빌트인 커널에서도 동작
자동 선택	커널 capability에 따라 최적의 eBPF 프로그램 자동 선택
로깅 지원	BPF Ring Buffer를 통해 차단 이벤트 실시간 로깅

동작 원리

copyfail-ebpf-k8s는 두 가지 eBPF 프로그램을 번들로 제공합니다:

#### 프로그램 1: ebpf-alg-socket-filter (권장)

• Hook: lsm/socket_create

• Action: 소켓 생성 시 -EPERM 반환하여 차단

• 요구조건: BPF LSM이 활성화된 커널 (/sys/kernel/security/lsm에 bpf 포함)

#### 프로그램 2: ebpf-alg-socket-killer (대안)

• Hook: tracepoint/sys_enter_socket

• Action: AF_ALG 소켓 생성 감지 시 프로세스 즉시 종료(SIGKILL)

• 요구조건: tracepoint를 지원하는 모든 커널

두 프로그램 모두:

• 커널 내부 소켓은 스킵 — 시스템 핵심 기능에 영향 없음

• 모든 UID 차단 — root마저 AF_ALG 소켓 생성 불가

---

배포 방법

1단계: 1분 배포

kubectl apply -f https://raw.githubusercontent.com/iwanhae/copyfail-ebpf-k8s/main/k8s-daemonset.yaml

타ㅉ타고레다케데、 кла�스터의 모든 Linux 노드에 보호 기능이 즉시 적용됩니다.

2단계: 동작 확인

# DaemonSet 상태 확인kubectl get daemonset -n kube-system copyfail-ebpf# 로그 확인kubectl logs -n kube-system -l app=copyfail-ebpf

정상 동작 시 다음과 같은 로그가 출력됩니다:

[2026-05-02 14:30:15] BLOCKED AF_ALG socket: pid=1234 uid=1000 gid=1000 comm="python3"

3단계: 제거 (패치 완료 후)

kubectl delete -f https://raw.githubusercontent.com/iwanhae/copyfail-ebpf-k8s/main/k8s-daemonset.yaml

---

기술적 구현 자세히 보기

BPF LSMSocket Filter (선호 방법)

BPF LSM(Becurity Module) 훅을오리용하면, 소켓이 생성되기 직전에 개입할 수 있습니다:

// ebpf-alg-socket-filter.c (개념적 구조)SEC("lsm/socket_create")int socket_filter(struct socket *sock) {// AF_ALGFamily 체크if (sock->sk->family == AF_ALG) {// EPERM 반환 → 소켓 생성 실패return -EPERM;}return 0;}

Tracepoint Killer (대안)

BPF LSM을 지원하지 않는고이 커널에서는, tracepoint를 사용해 소켓 생성 시스템콜 진입을 감지합니다:

// ebpf-alg-socket-killer.c (개념적 구조)SEC("tracepoint/sys_enter_socket")int socket_killer(struct pt_regs regs) {int family = PT_REGS_PARM2(regs); // socket() 두 번째 인자if (family == AF_ALG) {// 프로세스 강제 종료struct task_struct task = current;send_sig(SIGKILL, task, 0);}return 0;}

---

왜 이 방법이 더 나은가

기존 접근법과의 비교

방법	빌트인 커널대응	클러스터 전체 적용	즉시생효	운영 영향
커널 패치	✅	❌ (수동 각 노드)	❌ (재부팅 필요)	높음
모듈 비활성화	❌	❌ (수동 각 노드)	✅	중간
seccomp 프로파일	✅	⚠️ (파드별 설정)	✅	낮음
copyfail-ebpf-k8s	✅	✅ (DaemonSet)	✅	낮음

특히 권장하는 환경

• 멀티테넌트 Kubernetes 클러스터: 다른 사용자의 코드가 공유 커널 위에서 실행되는 환경

• CI/CD 러너 (GitHub Actions 셀프호스팅, GitLab Runner 등)

• 커널 패치 적용이 지연되고 있는 환경: Fedora, Oracle Linux, RHEL 등

• 컨테이너 샌드박스가 필요한 환경: 서버리스 컨테이너, PaaS 등

---

현재 vendor 패치 상태 (2026-05-03 기준)

배포판	상태
AlmaLinux	✅ 패치 배포 완료
Debian (bookworm, bullseye, trixie)	✅ 패치 배포 완료
Ubuntu	진행 중 (24.04 LTS 기준 패치 제공)
Amazon Linux 2023	진행 중
RHEL	진행 중 (livepatch 옵션 있음)

여전히 패치가 나오지 않은 배포판이 있는 만큼,Kernel 패치가 완료될 때까지 copyfail-ebpf-k8s와 같은 런타임 방어 솔루션으로 버퍼를 두는 것을 권장합니다.

---

요약

CVE-2026-31431 Copy Fail은 단순하면서도 강력한 Linux 커널 취약점입니다. 9년간 공개되지 않았고, 현재 다양한 배포판에서 패치가 진행 중이지만, 빌트인 커널 모듈 환경에서는 기존 임시 방편이 통하지 않습니다.

copyfail-ebpf-k8s는 단 1줄의 kubectl 명령으로 이 문제를 근본적으로 차단하는 실용적인 도구입니다. 커널 내부 소켓까지 구분하면서 모든 AF_ALG 소켓 생성을 차단하므로, patched/unpatched 커널 상관없이 보호할 수 있습니다.

지금 당장 확인해야 할 것:

1. kubectl apply -f k8s-daemonset.yaml — 1분 만에 클러스터 보호

2. kubectl logs -n kube-system -l app=copyfail-ebpf — 차단 로그 확인

3. 커널 패치 일정 확인 — 장기적으로는 패치 적용이 최종 방안

---

📚 출처

• GeekNews: https://news.hada.io/topic?id=29096

• GeekNews (취약점 원문): https://news.hada.io/topic?id=29031

• GitHub: iwanhae/copyfail-ebpf-k8s (https://github.com/iwanhae/copyfail-ebpf-k8s)

• theori-io/copy-fail-CVE-2026-31431 (https://github.com/theori-io/copy-fail-CVE-2026-31431)

• Juliet — Copy Fail in Kubernetes: RuntimeDefault Did Not Block AF_ALG (https://juliet.sh/blog/we-tested-copy-fail-in-kubernetes-pss-restricted-runtime-default-af-alg)

• Microsoft Security Blog — CVE-2026-31431 (https://www.microsoft.com/en-us/security/blog/2026/05/01/cve-2026-31431-copy-fail-vulnerability-enables-linux-root-privilege-escalation/)