Copy Fail / Dirty Frag 완화 조치 for Yandex Managed Kubernetes

Yandex Managed Kubernetes 클러스터의 모든 worker 노드에서 Linux kernel 취약점 CVE-2026-31431, CVE-2026-43284 및 CVE-2026-43500에 대한 완화 조치를 자동으로 적용합니다.

취약점 설명

CVE ID: CVE-2026-43284, CVE-2026-43500

CVE 링크: https://nvd.nist.gov/vuln/detail/CVE-2026-43284

원본 보고서:

Dirty Frag (PoC 및 write-up): https://github.com/V4bel/dirtyfrag
Copy Fail 2: Electric Boogaloo (PoC xfrm-ESP): https://github.com/0xdeadbeefnetwork/Copy_Fail2-Electric_Boogaloo
oss-security 메일링 리스트: https://www.openwall.com/lists/oss-security/2026/05/07/8

간단한 설명:

Dirty Frag는 Linux 커널의 논리적 취약점 클래스로, 권한이 없는 로컬 사용자가 슈퍼유저(root) 권한을 얻을 수 있게 합니다. 이 취약점은 xfrm-ESP 및 RxRPC 서브시스템의 두 가지 독립적인 page-cache write 프리미티브를 결합하며, 각각은 권한 상승에 단독으로 충분합니다.

Copy Fail 2: Electric Boogaloo는 xfrm-ESP 프리미티브(CVE-2026-43284)를 악용하는 독립적인 PoC입니다. 취약점 클래스 측면에서 원래 Copy Fail(CVE-2026-31431)과 유사하므로, 이 DaemonSet은 원래 AF_ALG 시나리오와 새로운 Dirty Frag 변종 모두에 대한 완화 조치를 유지합니다.

공격 방식:

원격 접근이 필요 없음 - 권한이 없는 로컬 계정만 있으면 됨
race condition이 없는 결정적 논리 버그 - 첫 시도에 성공
실패한 악용 시 kernel panic이 발생하지 않음
page cache가 노드 전체에 공유되므로 컨테이너에서 호스트로의 탈출 프리미티브로 사용될 수 있음

두 변종의 근본 원인은 동일합니다: splice() / MSG_SPLICE_PAGES 사용 시 커널이 page cache 페이지를 소켓 버퍼(skb)의 프래그먼트에 직접 배치합니다. xfrm-ESP 및 RxRPC 서브시스템은 이러한 프래그먼트가 프라이빗인지 확인하지 않고 in-place 복호화를 수행합니다. 결과적으로 공격자는 읽을 수 있는 모든 파일의 page cache에 대한 제어된 쓰기를 얻을 수 있습니다.

영향을 받는 기술:

Linux 커널, net/ipv4/esp4.c / net/ipv6/esp6.c 서브시스템 (xfrm-ESP)
Linux 커널, net/rxrpc/rxkad.c 서브시스템 (RxRPC / RxKAD)
UDP 소켓(ESP-in-UDP) 및 AF_RXRPC와 함께 사용되는 splice() / vmsplice() 시스템 콜
AF_ALG(algif_aead) 차단을 통한 원래 Copy Fail(CVE-2026-31431) 완화 조치는 별도로 유지됨

이 취약점은 Dirty Frag의 일부로서 AF_ALG(algif_aead)에 직접 영향을 미치지 않습니다 - 이는 별도의 Copy Fail(CVE-2026-31431) 취약점입니다. 또한 dm-crypt / LUKS, kTLS, in-kernel TLS 및 UDP 캡슐화가 없는 tunnel 모드의 IPsec에도 직접 영향을 미치지 않습니다.

CVSS v.3.1에 따른 공격 벡터 및 위험 수준:

기본 점수: 게시 시점에 할당되지 않음.

취약점의 특성상 Copy Fail(CVE-2026-31431, 7.8 HIGH, CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)과 유사합니다 - race condition이 없는 로컬 권한 상승입니다.

이 수정이 수행하는 작업

DaemonSet은 클러스터의 각 worker 노드에서 자동으로 다음을 수행합니다:

AF_ALG 가용성 확인 - 원래 Copy Fail 시나리오에 대한 빠른 테스트 수행
취약한 모듈 차단 - algif_aead, esp4, esp6 및 rxrpc에 대한 규칙으로 /etc/modprobe.d/blacklist-lpe.conf 생성
모듈 언로드 - 로드된 경우 algif_aead, esp4, esp6 및 rxrpc에 대해 rmmod 실행
page cache 플러시 및 구성 검증 - 캐시를 정리하고 구성 파일 존재 여부 확인
상태 모니터링 - 매시간 구성 존재 여부를 확인하고 필요 시 모듈을 다시 언로드

빠른 시작

1. DaemonSet 다운로드

wget https://raw.githubusercontent.com/yandex-cloud-examples/yc-mk8s-copy-fail-mitigation/main/copy-fail-mitigation-daemonset.yaml

또는 리포지토리 클론:

git clone https://github.com/yandex-cloud-examples/yc-mk8s-copy-fail-mitigation.git
cd yc-mk8s-copy-fail-mitigation

2. 수정 적용

kubectl apply -f copy-fail-mitigation-daemonset.yaml

3. 적용 상태 확인

# DaemonSet 상태 확인
kubectl get daemonset -n kube-system cve-2026-31431-fix

# 수정이 적용된 노드 수 확인
kubectl get pods -n kube-system -l app=cve-2026-31431-fix -o wide

4. 수정 적용 로그 보기

# initContainer 로그 (수정 적용)
kubectl logs -n kube-system -l app=cve-2026-31431-fix -c apply-fix

# 기본 컨테이너 로그 (모니터링)
kubectl logs -n kube-system -l app=cve-2026-31431-fix -c monitor

성공적인 적용 예시

=========================================
Copy Fail / Dirty Frag mitigation for Yandex Managed K8s
Node: demo-ru-central1-a-1
Date: Thu May 08 14:00:00 UTC 2026
=========================================

Step 1: Checking vulnerability before fix...
❌ System is VULNERABLE - AF_ALG AEAD interface is accessible

Step 2: Creating modprobe configuration...
✓ Created /etc/modprobe.d/blacklist-lpe.conf

Step 3: Unloading vulnerable modules...
  ✓ algif_aead unloaded
  ✓ esp4 not loaded
  ✓ esp6 not loaded
  ✓ rxrpc not loaded

Step 3.5: Dropping system caches...
✓ System caches cleared

Step 4: Verifying the fix...
✓ Configuration file exists:
install algif_aead /bin/false
install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false

Step 5: Testing if vulnerability is fixed...
✓ AF_ALG AEAD interface is properly blocked

=========================================
✓ Mitigation applied successfully
=========================================

수동 취약점 확인

노드에서 취약점 존재 여부를 수동으로 확인할 수 있습니다. SSH로 노드에 연결한 후 다음을 실행하세요:

# AF_ALG를 통한 원래 Copy Fail 시나리오 가용성 확인
python3 -c 'import socket; s = socket.socket(socket.AF_ALG, socket.SOCK_SEQPACKET, 0); s.bind(("aead","authencesn(hmac(sha256),cbc(aes))")); print("AF_ALG AEAD available - VULNERABLE")'

# "AF_ALG AEAD available - VULNERABLE"이 출력되면 시스템이 취약한 것
# 오류가 발생하면 시스템이 보호된 것

구성 확인:

# 차단 구성 존재 여부 확인
cat /etc/modprobe.d/blacklist-lpe.conf

# 예상 출력:
# install algif_aead /bin/false
# install esp4 /bin/false
# install esp6 /bin/false
# install rxrpc /bin/false

취약한 모듈이 로드되지 않았는지 확인:

lsmod | egrep 'algif_aead|esp4|esp6|rxrpc'

수정 제거

DaemonSet을 제거해야 하는 경우:

kubectl delete -f copy-fail-mitigation-daemonset.yaml

중요: DaemonSet을 제거해도 노드의 구성 파일은 삭제되지 않습니다. /etc/modprobe.d/blacklist-lpe.conf 파일은 그대로 남아 시스템을 계속 보호합니다.

노드에서 수정을 완전히 제거하려면 각 노드에 SSH로 연결하여 파일을 수동으로 삭제해야 합니다:

rm /etc/modprobe.d/blacklist-lpe.conf

기술적 세부 사항

사용 권한:

hostPID: true - nsenter를 통한 호스트 프로세스 접근용
privileged: true - /etc 쓰기 및 커널 모듈 언로드용
Volume mount / - 호스트 파일 시스템 접근용

이미지: ubuntu:22.04

리소스:

Init container: 10m CPU / 64Mi RAM (requests), 200m CPU / 128Mi RAM (limits)
Monitor container: 5m CPU / 32Mi RAM (requests), 50m CPU / 64Mi RAM (limits)

Namespace: kube-system

호환성

✓ Yandex Managed Kubernetes
✓ Ubuntu 20.04
✓ Ubuntu 22.04
✓ Kubernetes 1.20+

라이선스

Apache License 2.0

자세한 내용은 LICENSE를 참조하세요.

지원

문제가 발생하면 리포지토리에 issue를 생성하세요.

yc-mk8s-copy-fail-mitigation

인기