Fragnesia와 관련 취약점들: 반복되는 페이지 캐시 취약점

몇 주 전에 저는 Copy-Fail(CVE-2026-31431)에 대해 소개하며 Red Hat OpenShift의 심층 방어 접근 방식이 취약한 커널에서도 어떻게 컨테이너 이스케이프를 방지했는지 설명했습니다. 직접 OpenShift 컨테이너를 돌파하기 위해 시도했고, 거의 즉시 포드 내부의 root 권한을 획득했지만 호스트로는 이스케이프할 수 없었습니다. 커널 취약점은 실제 상황이었습니다. 익스플로잇 경로 또한 실제였습니다. 하지만 방어 체계는 여전히 유효했습니다. 

이 글을 마무리하던 중, 또 다른 관련 변종인 DirtyDecrypt(CVE-2026-31635)가 익스플로잇 논의 및 기술 검증(PoC) 사례와 함께 공개적으로 알려지기 시작했습니다. 당시 약 14일 동안 4개의 주요 Linux 권한 상승 취약점을 확인했는데, 모두 동일하고 광범위한 패턴의 변형을 악용하고 있었습니다.

이 부분이 제게는 가장 중요하게 다가옵니다.

어느 시점부터는 이를 개별적인 CVE로 보는 대신 시스템적인 문제로 인식하게 됩니다. 하위 시스템은 서로 다릅니다. 익스플로잇 경로도 제각각입니다. 하지만 기본 개념은 동일합니다. 커널 페이지 캐시 내의 copy-on-write 동작을 조작하고, 변경 불가능해야 할 파일을 손상시켜 권한을 상승시키는 방식입니다.

현재 프로덕션 인프라를 운영하고 있다면, 이러한 사실을 깨닫는 순간 논의의 방향이 급격히 바뀝니다. 개별 CVE를 하나씩 쫓는 것은 보안 전략이라기보다 눈사태 속에서 혀로 눈송이를 받아내려는 시도처럼 느껴지기 시작합니다. 그 결과는 결코 좋지 않습니다. 

중요한 것은 다음 변종이 필연적으로 나타날 때 아키텍처가 복원력을 유지할 수 있는지입니다.

지금 상황에서는 아마도 그렇게 될 것이기 때문입니다.

서로 다른 CVE, 동일한 패턴

지난 2주 동안 연구원들은 여러 관련 취약점을 공개했습니다. 일반 페이지 캐시 조작을 대상으로 하는 Copy-Fail, ESP/XFRM 및 RxRPC 경로를 노리는 Dirty Frag, ESP-in-TCP를 대상으로 하는 Fragnesia, 그리고 rxgk를 중심으로 공개된 DirtyDecrypt 등이 그 예입니다. 구현 세부 사항은 다르지만, 전반적인 익스플로잇 철학은 놀라울 정도로 일관적입니다. 연구원들은 커널 네트워킹 코드의 한 영역에서 개념적 취약점을 발견한 후, 유사한 가정이 적용되었거나 보호 장치가 누락된 인접 하위 시스템을 추적하기 시작합니다. 그리고 실제로 점점 더 많은 사례를 찾아내고 있습니다.

이러한 반복적인 패턴은 개별 CVE 번호보다 더 큰 우려를 자아냅니다.

저는 ROSA 클러스터를 생성하고 OpenShift를 대상으로 직접 Fragnesia를 테스트해 보기로 했습니다. 해당 클러스터는 Red Hat Enterprise Linux(RHEL) CoreOS 9.6 환경에서 OpenShift 4.21.15를 실행 중이었으며, 취약점이 있는 5.14.0-570.113.1.el9_6.x86_64 커널을 사용하고 있었습니다. 취약한 하위 시스템이 포함되어 있었습니다. 이론적으로는 해당 환경에서 익스플로잇이 가능해야 했습니다.

단순히 커널이 취약한지 여부만을 파악하고자 했던 것은 아니었습니다. 그 사실은 이미 알고 있었기 때문입니다. 다양한 보안 구성 환경에서 익스플로잇 체인이 실제로 어느 지점에서 차단되는지 확인하고 싶었습니다.

먼저 기본 OpenShift 보호 기능이 적용된 표준 포드를 배포했습니다. 특별한 설정은 추가하지 않았습니다. 상승된 권한도 부여하지 않았습니다. 완화된 SCC도 적용하지 않았습니다. 단순히 sleep infinity를 실행하는 일반 Fedora 컨테이너였습니다.

익스플로잇 체인은 거의 즉시 실패했습니다.

공격이 의미 있는 단계로 진행되기 전에 사용자 네임스페이스 생성이 차단되었습니다. 취약한 하위 시스템은 여전히 존재했지만, 컨테이너가 위험한 코드 경로에 도달하는 데 필요한 권한을 처음부터 확보하지 못했기 때문입니다. OpenShift의 기본 SCC(보안 컨텍스트 제약 조건)가 SELinux 적용과 결합되어 익스플로잇이 실제로 시작되기도 전에 차단되었습니다.

이 점은 놀랍지 않았습니다.

제가 더 관심을 가졌던 부분은 많은 조직이 실제로 사용하고 있는 환경과 유사한 다음 시나리오였습니다.

anyuid SCC를 사용하여 워크로드를 생성하고, 컨테이너를 사용자 ID(UID) 0으로 실행하도록 명시적으로 설정했습니다. 이는 브라운필드(brownfield) 환경에서 흔히 볼 수 있는 사례로, 기존 환경의 레거시 애플리케이션은 최소 권한 원칙을 고려하여 설계되지 않은 경우가 많으며 조직에서는 "애플리케이션 구동에 필요하다"는 이유로 보안과 타협하곤 합니다.

포드 내부에서 root 권한을 획득했습니다.

하지만 익스플로잇 체인은 여전히 실패했습니다.

anyuid를 사용하더라도 SELinux가 container_t 도메인 제한을 계속 적용하여, 권한 상승에 필요한 네임스페이스 작업을 차단했기 때문입니다. OpenShift 모델에 대해 사람들이 흔히 간과하는 점은 바로 보안 계층이 의도적으로 중첩되어 있다는 사실입니다. 제어 항목 하나를 완화한다고 해서 나머지 보안 경계가 자동으로 무너지지는 않습니다.

그래서 저는 좀 더 극단적인 설정을 시도해 보기로 했습니다.

privileged SCC, root 사용자, unconfined seccomp를 사용하여 의도적으로 위험한 구성을 구축했습니다. 이는 호스트 권한을 직접 넘겨주는 것을 제외하고 OpenShift 워크로드에 설정할 수 있는 가장 높은 수준의 허용 범위입니다.

마침내 상황이 전개되기 시작했습니다.

사용자 네임스페이스가 작동하며 unshare -U 명령이 성공했습니다. 익스플로잇 체인이 이전 시나리오에서는 불가능했던 방식으로 진행되기 시작했습니다. 많은 쿠버네티스 배포판의 경우, 이 단계는 대략 '보안 연구' 수준을 넘어 '침해 사고 대응' 단계로 전환되는 지점입니다.

그럼에도 익스플로잇은 여전히 실패했습니다.

Fragnesia는 단순히 네임스페이스 생성 기능만 활용하는 것이 아니기 때문입니다. 공격자가 취약한 네트워킹 경로에 액세스하는 데 필요한 권한을 얻으려면 네임스페이스 내에서 UID/GID 매핑이 성공적으로 이루어져야 합니다.

그 마지막 단계가 차단되었습니다.

권한 있는 SCC, root, unconfined seccomp를 사용하더라도 SELinux는 /proc/self/uid_map에 대한 쓰기 시도를 거부했습니다. UID 매핑이 성공하지 못하면서 에스컬레이션 체인이 무너졌습니다. namespace-root 권한이 없으면 XFRM/ESP에 액세스할 수 없습니다. 하위 시스템에 액세스할 수 없으므로 페이지 캐시 손상도 발생하지 않았습니다.

커널은 내내 취약한 상태를 유지했지만 익스플로잇 시도는 실패했습니다. 이러한 차이는 매우 중요합니다.

이번 테스트를 통해 제가 오랫동안 믿어온 사실을 다시 한번 확인할 수 있었습니다. 바로 문제가 발생했을 때 우수한 심층 방어가 특히 그 가치를 발휘한다는 점입니다. 모든 것이 완벽하게 구성되어 있을 때만 가치가 있는 것이 아닙니다. 모든 워크로드가 깨끗하고 최소 권한으로 설정되어 있으며, 보안 팀이 원하는 모든 요구사항이 충족되는 상황에서만 유효한 것도 아닙니다. 실제 환경은 복잡합니다. 통제 설정이 완화되기도 합니다. 레거시 워크로드가 여전히 존재합니다. 운영상의 타협이 끊임없이 발생합니다.

핵심은 이러한 보안 타협이 발생한 후에도 아키텍처가 견고하게 유지되는지 여부입니다.

이번 사례에서는 아키텍처가 견고하게 유지되었습니다.

동시에 여러 보안 계층을 약화시켰음에도 불구하고 SELinux는 컨테이너를 근본적으로 신뢰할 수 없는 대상으로 간주했으며, 악용을 완료하는 데 필요한 최종 권한 상승 단계를 차단했습니다.

이것이 바로 '보안 기능'과 일관된 '보안 아키텍처'의 차이입니다. 저에게는 개별 Fragnesia CVE 자체보다 이러한 광범위한 아키텍처 관련 논의가 더 중요합니다. 지난 몇 주 동안 확인했듯이, 이 취약점 제품군은 아마도 아직 진화가 끝나지 않았을 것이기 때문입니다.

조직이 스스로에게 던져야 할 운영상의 질문은 더 이상 "CVE-2026-46300 패치를 완료했는가?"가 아닙니다. 진짜 질문은 "아무도 지켜보지 않던 다른 하위 시스템을 노린 CVE-2026-XXXXX가 다음 주 화요일에 발표된다면 운영 측면에서 어떤 일이 벌어질 것인가?"입니다.

익스플로잇은 진화합니다. 하지만 신호는 변하지 않습니다.

솔직히 말씀드리면, 현시점에서 이는 더 이상 가상의 시나리오가 아닙니다.

바로 이 지점에서 Red Hat Advanced Cluster Security for Kubernetes가 단순한 CVE 중심의 사고방식보다 훨씬 더 큰 가치를 제공한다고 생각합니다. 이러한 맥락에서 Red Hat Advanced Cluster Security의 흥미로운 점은 Fragnesia에 대해 구체적으로 알고 있다는 사실이 아니라, 정확한 취약점이 바뀌더라도 이러한 익스플로잇 체인을 둘러싼 행동 패턴을 식별할 수 있는 경우가 많다는 점입니다.

웹 애플리케이션 컨테이너가 갑자기 사용자 네임스페이스를 생성하는 것은 이례적인 일입니다. 애플리케이션 워크로드가 /bin/su를 실행하는 것 또한 일반적이지 않습니다. 이러한 신호는 익스플로잇 명칭이 Copy Fail, Dirty Frag, Fragnesia, DirtyDecrypt이든, 혹은 다음 주에 연구원들이 새로 붙일 이름이 무엇이든 관계없이 여전히 유의미합니다.

CVE는 계속 변하지만, 이러한 경우의 행동 양식은 변하지 않습니다.

이는 많은 조직이 운영상의 불안정성을 초래하지 않고 대규모 시스템에 패치를 적용할 수 있는 속도보다 보안 취약점 공개 주기가 더 빠르게 진행되고 있기 때문에 매우 중요합니다. 아키텍처와 행동에 대한 가시성은 대응할 시간을 벌어줍니다. 때로는 그 시간 덕분에 계획에 따라 제어된 조치를 실행할 수도 있고, 반대로 18시간 동안 인시던트 브리지에 갇혀 어떤 클러스터가 노출되었는지 파악하느라 고군분투하게 될 수도 있습니다.

동일한 원칙이 대규모 시스템 운영에도 적용됩니다.

실험실에서 3개의 포드를 테스트하는 것은 간단합니다. 하지만 프로덕션 워크로드가 온라인 상태를 유지하는 동안 수십 또는 수백 개의 클러스터 전반에서 정책 변경을 조정하는 것은 완전히 다른 차원의 문제입니다. 이러한 상황에서 Red Hat Advanced Cluster Management for Kubernetes는 사후 대응적인 혼란을 통제된 롤아웃으로 전환하여 대응 방식을 근본적으로 바꿔줍니다. 클러스터를 하나씩 수동으로 감사하고 위험한 설정을 식별하며 팀 간에 보안 태세 변경을 조정하는 대신, 중앙에서 일관된 정책을 수립하여 모든 곳에 동시에 배포할 수 있습니다.

며칠 간격으로 새로운 변종이 등장하는 상황에서는 이러한 차이가 매우 중요해집니다.

Red Hat OpenShift on AWS(ROSA) 클러스터의 경우, 테스트 내내 커널이 취약한 상태였습니다. 취약한 하위 시스템도 그대로 존재했습니다. 기술적으로는 익스플로잇 전제 조건이 충족된 상태였습니다.

하지만 계층화된 제어 체계가 여러 지점에서 권한 상승을 차단했기 때문에 익스플로잇 체인은 계속 무력화되었습니다.

그러던 중 이 기사를 작성하는 동안 DirtyDecrypt가 공개적으로 유포되기 시작했습니다.

더 광범위한 익스플로잇 철학은 동일했습니다. 다만 하위 시스템이 달랐을 뿐입니다. 기존의 방어 체계는 이미 효과적으로 작동하고 있었습니다.

이는 단순히 운이 좋았던 것이 아닙니다. 이것이 바로 아키텍처의 힘입니다. 이것이 바로 심층 방어입니다.

자세히 알아보기

• AI가 버그를 발견할 때: 심층 방어가 항상 해답인 이유
• OpenShift 무료 체험하기
• OpenShift Platform Plus에 대해 자세히 알아보기