리눅스 커널에 또 권한 상승 취약점, 컨테이너 루트까지 뚫릴 수 있음

• 리눅스 커널에 ‘더티 프랙’이라는 권한 상승 취약점이 공개됐고, 낮은 권한 사용자도 루트 권한까지 갈 수 있다는 게 핵심임

  • 기사에 따르면 CVE-2026-43284와 CVE-2026-43500 두 취약점을 엮는 방식이고, 공개 직후 핵심 정보가 유출되며 사실상 제로데이처럼 다뤄졌음
  • 특히 공유 서버, 가상 머신, 보안이 느슨한 컨테이너 환경처럼 여러 사용자가 같은 머신 자원을 쓰는 곳에서 위험도가 커짐

• 찝찝한 건 이 익스플로잇이 ‘운 좋으면 터지는’ 타입이 아니라 꽤 안정적으로 동작한다는 설명이 붙었다는 점임

  • 실행할 때마다 여러 리눅스 배포판에서 거의 같은 방식으로 작동하는 결정론적 취약점이라고 설명됨
  • 시스템 충돌을 일으키지 않아 은밀하게 실행될 수 있다는 점도 운영팀 입장에선 골치 아픈 포인트임
  • 마이크로소프트는 실제 환경에서 해커들이 더티 프랙을 실험하는 징후를 봤다고 밝혔음

• 기술적으로는 페이지 캐시를 다루는 커널 버그 계열로 묶임

  • 더티 프랙과 카피 페일 모두 메모리에 저장된 페이지 캐시 처리 문제에서 비롯됐다고 설명됨
  • 2022년에 나왔던 Dirty Pipe도 공격자가 페이지 캐시를 덮어쓸 수 있게 했던 계열이라, 이번 건도 비슷한 냄새가 남
  • 다만 더티 프랙은 pipe_buffer가 아니라 커널의 sk_buff 구조체에 있는 frag 멤버를 노린다는 설명이 붙어 있음

• 공격 흐름은 꽤 교묘함. 읽기 권한만 있는 파일을 네트워크 버퍼 조각 처리 경로에 끼워 넣고, 커널이 그 조각을 제자리에서 암호화하거나 복호화하게 만드는 식임

  • 예시로 /etc/passwd나 /usr/bin/su 같은 읽기 전용 캐시 페이지 참조를 skb의 frag 슬롯에 넣는 방식이 언급됨
  • 이후 수신 측 커널 코드가 해당 조각에 제자리 암호화 작업을 수행하면서 RAM의 페이지 캐시가 수정될 수 있음
  • 공격자는 파일 쓰기 권한이 없어도 이후 파일을 읽을 때 손상된 버전을 보게 되는 구조임

• CVE-2026-43284는 IPsec ESP 수신 경로의 esp_input() 쪽 문제가 핵심으로 설명됨

  • skb 객체가 비선형이지만 조각 목록이 없는 경우 skb_cow_data()를 건너뛰고 심어진 조각에서 AEAD를 제자리 복호화할 수 있다고 함
  • 공격자는 파일 오프셋과 각 저장의 4바이트 값을 제어할 수 있다는 설명이 붙어 있음

• CVE-2026-43500은 rxrpc 쪽을 노리는 경로로 언급됨

  • 마이크로소프트 연구원들은 더티 프랙이 rxrpc와 esp/xfrm 네트워킹 구성요소를 이용한 여러 커널 공격 경로를 도입해 공격 신뢰성을 높인다고 봤음
  • 흔한 로컬 권한 상승처럼 좁은 타이밍 창이나 불안정한 메모리 손상에 기대는 방식이 아니라는 점이 더 위험하게 평가됨

• 그래도 모든 컨테이너 환경이 똑같이 뚫린다는 얘기는 아님

  • Wiz 연구원들은 기본 보안 설정이 적용된 쿠버네티스 같은 강화된 컨테이너 환경에서는 공격 성공 가능성이 낮다고 봤음
  • 반대로 가상 머신이나 보안 설정이 덜 단단한 환경에서는 여전히 상당한 위험이 있다고 짚었음

• 대응은 복잡하게 생각할 것 없이 커널 패치가 1순위임

  • 기사 기준으로 데비안, 알마리눅스, 페도라 등 여러 배포판에서 패치가 배포되고 있음
  • 커널 패치는 재부팅이 필요할 수 있으니, 서비스 중단 비용과 침해 위험을 비교해서 빠르게 점검해야 함
  • 바로 패치할 수 없다면 공개된 완화 조치를 적용해야 한다는 조언도 나옴

---

기술 맥락

• 이번 건에서 중요한 선택지는 ‘패치까지 기다릴지’가 아니라 ‘커널 업데이트와 재부팅을 언제 할지’예요. 로컬 권한 상승은 이미 내부 계정이나 컨테이너 셸을 얻은 공격자가 루트로 올라가는 단계라서, 침투 이후 피해 범위를 확 키우거든요.

• 더티 프랙이 무서운 이유는 페이지 캐시라는 공용 성능 최적화 레이어를 건드리기 때문이에요. 애플리케이션 권한 모델에서는 읽기 전용 파일처럼 보여도, 커널 내부 캐시가 오염되면 결과적으로 다른 경로에서 손상된 데이터를 보게 될 수 있어요.

• 컨테이너 환경에서는 커널을 호스트와 공유한다는 점이 핵심이에요. 컨테이너 안에서 루트처럼 보이는 권한과 호스트 커널의 실제 권한은 다르지만, 커널 취약점은 그 경계를 직접 흔들 수 있어서 런타임 보안 설정이 중요해져요.

• 운영팀 입장에서는 배포판 패치 여부, 커널 버전, 재부팅 가능 시간, 멀티테넌트 여부를 같이 봐야 해요. 특히 여러 고객이나 팀이 같은 호스트 자원을 쓰는 환경이면 단일 서버 취약점이 플랫폼 리스크로 번질 수 있거든요.