CVE-2026-43284, CVE-2026-43500

CVE-2026-43284 및 CVE-2026-43500 취약점 점검과 완화 절차

CVE-2026-43284(커널 IPsec ESP/XFRM 계열)와 CVE-2026-43500(커널 RxRPC 계열)은 함께 “Dirty Frag”로 묶여 언급되는 로컬 권한 상승(LPE) 이슈로 알려져 있습니다. 운영 환경에서는 “패치 적용”이 최종 해법이지만, 배포 지연이나 변경 동결이 있는 경우에는 모듈 차단 같은 완화가 현실적인 1차 대응이 됩니다.

핵심 요약
- 위협 모델: 로컬 계정(SSH 포함) 또는 컨테이너 워크로드가 “호스트 커널 기능”을 악용할 수 있는 상황에서 위험도 상승
- 대상 영역: ESP(IPsec) 모듈(예: esp4/esp6) 및 RxRPC 모듈(rxrpc) 관련 경로가 관여
- 우선순위: (1) 현재 커널/모듈 사용 여부 파악 → (2) 즉시 완화(차단/언로드) → (3) 벤더 커널 업데이트로 복구

개요

CVE-2026-43284는 Linux 커널 네트워킹/암호화 스택 중 IPsec ESP 처리 경로와 연관되어 언급되며, CVE-2026-43500은 RxRPC 서브시스템 경로와 연관되어 공개되었습니다. 두 이슈는 “로컬 권한 상승(LPE)” 관점에서 함께 다뤄지는 경우가 많고, 실무 기준으로 보면 “해당 모듈이 실제로 로드/사용 중인지”가 대응 우선순위를 가르는 기준이 됩니다.

영향 범위(운영 관점)

• 로컬 사용자 권한 상승: 일반 사용자 권한이 root 수준으로 상승할 수 있는 시나리오가 문제의 중심입니다.
• 컨테이너 환경: 호스트 커널 기능을 공유하므로, “임의의 3rd-party 워크로드 실행” 환경에서는 리스크가 커질 수 있습니다.
• 기능 영향: IPsec(예: VPN) 또는 AFS/RxRPC 사용 중이면, 모듈 차단 완화가 서비스에 직접 영향이 갈 수 있습니다.

환경

아래 항목은 특정 배포판에 종속되지 않도록 “공통 리눅스 운영 기준”으로 정리했습니다. 실제 사용 시에는 커널 패키지 공급자(배포판/벤더)의 보안 권고에 따라 “패치 포함 커널 버전”을 최종 기준으로 잡는 것이 안전합니다.

점검 전 확인할 것

• 호스트/노드의 커널 버전(uname -r)
• ESP(IPsec) 사용 여부: 사이트 간 터널/VPN, 커널 모듈(esp4/esp6) 로드 여부
• RxRPC 사용 여부: AFS 또는 RxRPC 기반 구성, 커널 모듈(rxrpc) 로드 여부
• 컨테이너 운영 여부 및 “비특권 사용자 네임스페이스” 정책

증상

이 유형의 취약점은 “침해 흔적이 명확하지 않은 상태로 권한이 올라가는” 형태가 많아, 증상 기반 탐지는 한계가 있습니다. 따라서 CVE-2026-43284, CVE-2026-43500은 “환경 노출 여부 점검”과 “완화/패치 적용 상태 관리”가 핵심입니다.

의심 신호(참고)

• 평소 사용하지 않던 로컬 계정에서의 root 권한 획득 시도(예: sudo 기록과 불일치)
• 갑작스러운 커널 모듈 로드/언로드 흔적(esp4/esp6/rxrpc 관련)
• 컨테이너 환경에서 비정상적인 호스트 권한 상승 시도(로그/감사 이벤트)

관리자 입장에서
“증상”만으로 결론을 내리지 말고,
(1) 모듈 로드 여부 + (2) 커널 패치 수준 + (3) 로컬 접근 경로(SSH/계정 정책/컨테이너 실행 정책)를 같이 보세요.

1차 점검

1차 점검의 목적은 “CVE-2026-43284 및 CVE-2026-43500이 성립할 수 있는 조건(특정 모듈/기능 사용)”이 현재 시스템에 존재하는지 빠르게 확인하는 것입니다.

1) 커널 버전 확인

uname -r
cat /etc/os-release 2>/dev/null || true

2) 관련 모듈 로드 여부 확인

lsmod | grep -E '^(esp4|esp6|rxrpc)\b' || echo "관련 모듈 미로드(표시 없음)"
grep -E '^(esp4|esp6|rxrpc) ' /proc/modules 2>/dev/null || true

3) 기능 사용 여부(간단 체크)

• IPsec(ESP): VPN/터널이 실제로 동작 중인지, 관련 서비스/설정이 있는지 확인
• RxRPC: AFS 사용 여부 또는 rxrpc 기반 서비스가 있는지 확인

판단 기준(빠른 결론)
- esp4/esp6가 로드되어 있고 IPsec을 실제 사용 중이라면: “완화 적용 시 서비스 영향”을 먼저 평가
- rxrpc가 로드되어 있지 않다면: rxrpc 관련 완화는 영향이 거의 없을 가능성이 큼
- 어떤 경우든 최종 목표는 “패치된 커널로 업데이트”

심화 분석

심화 분석은 “왜 이 시스템이 위험한지/덜 위험한지”를 운영 정책과 함께 확정하는 단계입니다. 특히 CVE-2026-43284, CVE-2026-43500은 로컬 접근이 전제되므로, 로컬 접근 경로를 최소화하는 하드닝도 함께 검토합니다.

1) 모듈 정보(로딩 경로/의존성) 확인

modinfo esp4 2>/dev/null || true
modinfo esp6 2>/dev/null || true
modinfo rxrpc 2>/dev/null || true

2) 로컬 접근 경로 점검(권한 상승 전제 조건 줄이기)

• SSH 접근 정책(허용 사용자/키 기반 인증/2FA/접근 제어)
• 불필요한 로컬 계정/서비스 계정 정리
• 컨테이너 런타임 정책(신뢰되지 않은 워크로드 실행 차단, 권한 최소화)

3) “비특권 사용자 네임스페이스” 정책 검토(환경별 선택)

일부 환경에서는 비특권 사용자 네임스페이스를 제한하는 방식이 완화 옵션으로 언급됩니다. 다만 rootless 컨테이너/샌드박스 기능에 영향이 갈 수 있어, 운영 요구사항에 맞게 선택해야 합니다.

# 현재 값 확인(배포판/커널 설정에 따라 파일 존재 여부는 다를 수 있음)
sysctl user.max_user_namespaces 2>/dev/null || true

복구

복구는 두 갈래로 나뉩니다.
(A) “즉시 완화(모듈 차단/언로드)”로 노출을 줄이고
(B) “커널 업데이트(패치 적용)”로 근본 해결을 합니다.

A) 즉시 완화: 모듈 차단(재부팅 전/후 적용 가능)

주의
- esp4/esp6 차단은 IPsec(ESP) 기능을 중단시킬 수 있습니다.
- rxrpc 차단은 AFS/RxRPC 기반 기능에 영향을 줄 수 있습니다.
- 운영 환경에서는 서비스 영향 평가 후 적용하세요.

# 1) 향후 로드를 차단(모듈 install을 false로 매핑)
# 배포판에 따라 경로/도구는 다를 수 있으나, modprobe.d 방식은 공통적으로 많이 사용됨
sudo sh -c 'printf "%s\n" \
  "install esp4 /bin/false" \
  "install esp6 /bin/false" \
  "install rxrpc /bin/false" \
  > /etc/modprobe.d/dirty-frag.conf'

# 2) 현재 로드된 경우 언로드(사용 중이면 실패할 수 있음)
sudo rmmod esp4 esp6 rxrpc 2>/dev/null || true

# 3) 로드 상태 확인
grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "아직 로드됨(재부팅 또는 사용 중 여부 확인 필요)" || echo "미로드 상태"

B) 근본 해결: 커널 업데이트

최종적으로는 “벤더에서 패치를 포함한 커널 패키지”로 업데이트해야 합니다. 변경 동결이 있는 조직이라면, 완화(모듈 차단)를 먼저 적용하고 정기 패치 윈도우에서 커널 업데이트를 진행하는 방식이 현실적입니다.

# 예시(배포판별 명령은 다름): 업데이트 후 재부팅이 필요할 수 있음
# - Debian/Ubuntu 계열: apt 기반
# - RHEL 계열: dnf/yum 기반
# - SUSE 계열: zypper 기반

uname -r
# (업데이트 수행)
# reboot
uname -r

완화 해제(패치 적용 후)

sudo rm -f /etc/modprobe.d/dirty-frag.conf
# initramfs를 사용하는 환경이라면 재생성 필요(배포판별 명령 상이)
# 예: Debian/Ubuntu 계열
sudo update-initramfs -u -k all 2>/dev/null || true

재발 방지

• 커널 업데이트 체계화: 커널 보안 패치가 누락되지 않도록, 정기 점검/배포 흐름을 고정합니다.
• 불필요 모듈 최소화: 실제 사용하지 않는 기능(IPsec/RxRPC 등)은 기본적으로 비활성화/차단을 검토합니다.
• 로컬 접근면 축소: SSH 접근 정책 강화, 계정 최소화, 권한 분리(운영 계정/배포 계정)를 적용합니다.
• 컨테이너 하드닝: 신뢰되지 않은 워크로드 실행을 줄이고, 런타임/노드 정책으로 권한을 제한합니다.
• 점검 자동화: uname -r, lsmod 결과를 주기적으로 수집해 “모듈 로드 상태 변화”를 감시합니다.

운영 환경에서는
취약점 공지가 뜰 때마다 “패치 전 완화 → 패치 적용 → 완화 해제”를 템플릿처럼 반복할 수 있어야 합니다.
CVE-2026-43284, CVE-2026-43500처럼 로컬 권한 상승 계열은 ‘로컬 접근면 관리’가 재발 방지의 핵심입니다.