DirtyClone과 끊임없이 재발하는 Shared-Frag 마커 버그

요약

전체 버전으로 이동 ↓

내용: DirtyClone, 추적 대상: 43503,는 네트워킹 스택에서 발생하는 리눅스 커널의 로컬 권한 상승 취약점입니다. 일부 skb 조각 전송 경로에서 SKBFL_SHARED_FRAG 인플레이스 쓰기를 차단하여 ESP(IPsec) 입력 데이터가 파일 기반 페이지 캐시 페이지를 통해 직접 복호화되도록 하는 마커입니다. 이는 루트 권한을 가진 읽기 전용 파일에 대한 임의 쓰기이며, 기존 방식 대신 네트워크 스택을 통해 이루어지는 Dirty COW 공격입니다. /proc/self/mem.

영향: 로컬 비특권 사용자가 마커 손실을 다음과 같은 바이너리에 대한 페이지 캐시 쓰기 작업으로 전환합니다. /usr/bin/su, 그런 다음 악성 이미지를 이용해 루트 권한을 획득합니다. JFrog는 6월 25일에 이 취약점에 대한 익스플로잇 단계별 가이드를 공개했으며, 공개된 PoC(rafaeldtinoco/security/exploits/dirtyclone, 김현우의 DirtyFrag 프라이미티브를 기반으로 함)는 구형 커널에서도 재현됩니다. 디스크 파일은 절대 변경되지 않기 때문에 파일 무결성 검사 도구는 이를 탐지하지 못합니다.

상태: DirtyClone은 DirtyFrag/Fragnesia 계열에 속합니다. 파일 기반 메모리가 고속 네트워킹 경로를 통과할 때 안전 마커가 손실되고, 이후의 제자리 쓰기 작업이 복사되었어야 할 위치에 기록되는 현상입니다. JFrog은 5월 19일에 이 문제를 보고했으며, 수정 패치는 5월 24일 v7.1-rc5에 포함되었습니다. 따라서 이는 수정 체인의 일부가 누락된 RHEL 환경에서는 N-day 취약점으로 간주되며, 새로운 0-day 취약점은 아닙니다.

중요도: 레드햇(Red Hat)은 이를 ‘중요(Important)’ 등급으로 평가했으며, CVSS 7.0 기준입니다. kernel.org는 공격 복잡도 등급이 낮고, 영향 범위 평가가 ‘변경됨(Changed)’(‘변경 없음(Unchanged)’ 대비)으로 판정된 점을 반영해 8.8점을 부여했으나, 어느 경우든 결과적으로 루트 권한을 획득하게 됩니다. 버그 유형: 공유 프래그먼트 마커 전파 오류로 인해 페이지 캐시로 뒷받침되는 메모리에 안전하지 않은 인플레이스 쓰기가 발생하는 문제입니다.

이것이 중요한 이유: 노출된 시스템이란 격리 자체가 결과물인 시스템들을 말합니다. 다중 테넌트 호스트, CI 러너, 컨테이너 및 쿠버네티스 노드, 그리고 다음을 통해 접근 가능한 개발용 샌드박스 등이 이에 해당합니다. CAP_NET_ADMIN, 많은 배포판에서는 기본적으로 네임스페이스 내의 비특권 사용자에게 이 권한을 부여합니다. 여기서 “로컬”이라고 해서 “위험도가 낮다”는 뜻은 아닙니다.

지금 바로 이렇게 하세요: 이 수정 사항은 이미 EL9 및 EL10 피드에 반영되었으므로, 업데이트 후 재부팅하시기 바랍니다. 아직 패치를 적용할 수 없는 경우, 비특권 사용자 네임스페이스를 비활성화하거나 차단하십시오. esp4/esp6 IPsec이 사용되지 않는 경우 자동 로드. KernelCare 사용자들은 이미 해당 EL9/EL10 커널에 대한 재부팅 없이 적용 가능한 패치를 보유하고 있습니다. 자세한 내용은 아래와 같습니다.

가장 심각한 리눅스 커널 버그 중 일부는 처음부터 명백한 “루트 파일에 쓰기” 취약점으로 나타나는 것은 아닙니다. 이들은 단순한 관리상의 실수에서 비롯됩니다. DirtyClone도 그중 하나입니다. 소켓 버퍼 조각에 소유권 마커가 누락되어 있는데, 이후의 네트워크 작업이 이를 신뢰하게 되고, 그 결과 해당 영역에 직접 쓰기가 이루어집니다.

리눅스 네트워킹 스택은 패킷 데이터를 소켓 버퍼(skb)를 통해 전송합니다. 이 데이터 중 일부는 바이트 단위로 전용 메모리에 복사되는 대신 페이지 조각의 형태로 존재합니다. 이는 성능 면에서는 유리하지만, 소유권 측면에서는 매우 까다롭습니다. 왜냐하면 페이지 조각이 공유 페이지, 외부 소유 페이지, 또는 페이지 캐시에 의해 뒷받침되는 페이지를 가리킬 수 있기 때문입니다. 어떤 코드든 이러한 페이지에 데이터를 쓰기 전에, 해당 페이지를 그대로 수정하는 것이 안전하지 않다는 사실을 미리 파악해야 합니다.

그것이 바로 SKBFL_SHARED_FRAG. 이 마커는 후속 패킷 처리 코드에게 해당 SKB가 공유 프래그먼트를 포함하고 있으며, 커널이 먼저 데이터를 전용 메모리로 복사하지 않는 한 해당 위치에서 직접 수정하는 것은 허용되지 않음을 알려줍니다. 더티클론(DirtyClone)은 프래그먼트가 한 SKB에서 다른 SKB로 이동하는 과정에서 이 마커가 사라질 때 발생합니다. NVD 명칭 __pskb_copy_fclone() 그리고 skb_shift() 마커를 넘기지 않고 프래그 디스크립터를 이동시킬 수 있는 헬퍼들 중에는, 대상 SKB에 페이지 캐시로 뒷받침되는 참조를 남기면서 skb_has_shared_frag() false를 반환합니다.

그 잘못된 응답이 바로 취약점입니다. 이후에 실행되는 인플레이스 라이터는 skb를 확인하고, 조각들이 공유되는지 묻고, ‘아니오’라는 응답을 받으면 기본 페이지에 직접 기록합니다. ESP 입력은 esp4.c 바로 그런 작가이며, 대중의 착취가 바로 그 구렁텅이로 몰아넣는 것이다.

DirtyClone은 봄 내내 발생했던, 각각 동일한 오류 양상을 보이는 일련의 버그들을 마무리 짓는 사례입니다. 파일로 백업된 페이지 캐시 메모리가 일반 패킷 데이터로 처리된 후, 인플레이스 네트워크 작업이 복사해야 할 위치에 직접 쓰기를 수행합니다. 4월 말에는 ‘Copy Fail’이 처음 발견되었고, 5월 7일에는 ‘DirtyFrag’가 뒤를 이었습니다. 5월 13일에는 ‘Fragnesia’가 ‘DirtyFrag’ 패치를 우회했습니다. ‘DirtyClone’은 네 번째로 발견된 결함으로, 동일한 1비트 마커를 제거하는 또 다른 패킷 복제 경로를 통해 발생합니다.

이 부분이 이 문제를 어떻게 우선순위를 매겨야 할지 결정하는 기준이 될 것입니다. DirtyClone은 완전히 패치된 시스템 군을 뚫고 들어가는 새로운 제로데이 취약점이 아닙니다. JFrog이 6월 25일에 공개한 내용은 부분적인 패치로 인해 남아 있는 잔여 코드 경로에 여전히 접근할 수 있음을 보여주는 시연입니다. 핵심 단어는 ‘완전’입니다. 커널은 DirtyFrag 및 Fragnesia 체인을 모두 포함해야만 비로소 보호됩니다. 원래 DirtyFrag 수정 패치는 적용했으나 후속 패치를 놓친 커널의 경우, 여전히 동일한 ESP 싱크로 연결되는 경로가 열려 있습니다. Red Hat의 현재 EL9 및 EL10 커널은 이미 전체 백포트를 포함하고 있으므로, 위험은 최신 버전이 아닌 몇 번의 업데이트가 밀린 커널에 있습니다.

DirtyClone의 작동 원리

이 퍼블릭 체인은 비특권 소켓 구성에서 시작하여 특권 페이지 캐시에 임의로 쓰기까지 진행됩니다.

[Unprivileged user + network namespace]
│  attacker obtains CAP_NET_ADMIN inside the namespace
▼
[netfilter TEE rule clones ESP-in-UDP packets]
│  clone routed through __pskb_copy_fclone(), marker dropped
▼
[Mislabelled skb: references page-cache pages,
reports skb_has_shared_frag() == false]
▼
[XFRM ESP transport SA decrypts in place]
│  esp_input() AES-CBC writes over the target file's page cache
▼
[Arbitrary content in root-owned page cache]
│  overwrite /usr/bin/su (or /etc/sudoers.d/* via an NSS load)
▼
[uid=0 root shell]

표지판. 커널은 자신이 소유하지 않은 페이지 참조를 포함하는 모든 SKB에 다음 태그를 부여합니다. SKBFL_SHARED_FRAG, 그리고 skb_has_shared_frag() 해당 태그를 읽어 페이로드를 그 자리에서 변형할 수 있는지 여부를 결정합니다. 프래그 전송 헬퍼가 마커를 전달하지 않고 SKB 간에 페이지 단위의 프래그먼트를 이동할 때, 대상 SKB는 외부에서 소유하거나 페이지 캐시에 의해 뒷받침되는 페이지에 대한 참조를 유지하면서, 공유되는 항목이 없다고 보고합니다.

싱크대. 나중에 실행되는 인플레이스 라이터는 해당 보고서를 신뢰합니다. DirtyClone의 경우, 라이터는 esp_input() AES-CBC 복호화는 루트 권한을 가진 읽기 전용 파일의 페이지 캐시를 포함하여 해당 페이지들을 직접 복호화합니다. 공격자는 ESP 키와 보안 연결을 제어하고, 여기에 삽입된 소스 페이지를 활용하여 이를 특권 페이지 캐시에 임의의 콘텐츠를 기록하는 공격으로 전환합니다.

경로. 레드햇은 EL9 및 EL10의 노출 원인을 다음과 같이 설명합니다. skb_try_coalesce() 마커가 사라지는 문제(Bugzilla 2480902)를 다루며, 다음을 포함한 헬퍼 계열 전반에서 동일한 현상이 발생할 수 있음을 언급합니다. __pskb_copy_fclone(), skb_shift(), skb_gro_receive(), 그리고 skb_segment(). 공개 PoC는 다른 경로를 통해 동일한 ESP 싱크에 도달합니다. 이 PoC는 권한이 없는 사용자 및 네트워크 네임스페이스 내에서 실행되며, UDP를 통해 전송되는 ESP 패킷을 복제하는 netfilter TEE 규칙을 설치합니다. __pskb_copy_fclone(), 이 과정에서 마커가 제거된 후 XFRM ESP 전송 SA가 설치되어, 복제되고 라벨이 잘못 지정된 패킷이 대상 파일의 페이지 캐시에서 바로 복호화됩니다.

중요한 점은 이것이 편집이 아니라는 것입니다 /usr/bin/su 일반적인 의미에서 디스크에 있는 파일이 아닙니다. 이는 커널이 나중에 특권 실행 경로에 제공하는 메모리 내 페이지 캐시 사본을 손상시킵니다. 바로 이 때문에 기존의 파일 무결성 모니터링은 이 경우 효과적인 통제 수단이 되지 못합니다. 디스크상의 파일은 손대지 않은 채로 남아 있고, 변경 사항은 커널의 메모리 내 사본에만 존재하며, 재부팅을 통해 원래의 바이너리가 복원되지만, 대개 이때는 공격자가 이미 루트 권한을 획득한 지 한참 지난 후입니다.

적용 범위를 파악하는 데 있어 한 가지 세부 사항이 중요합니다. PoC의 README에는 메인라인 v7.1-rc1부터 rc4까지의 좁은 범위가 명시되어 있지만, 내부 테스트 결과 EL9 및 EL10 백포트 커널에서도 수정 없이 동일한 현상이 재현되었습니다. 따라서 해당 업스트림 범위가 RHEL 계열 배포판에 미치는 영향을 제한하지는 않습니다. README에 명시된 버전 범위를 보고 EL 시스템이 적용 범위에서 제외된다고 단정하지 마십시오.

‘Upstream Fix’의 변경 사항

수정 사항은 사소하지만, 바로 그 때문에 해당 패밀리는 계속해서 변종을 만들어내고 있습니다. 이 수정으로 인해 프래그먼트 전송 헬퍼가 공유 프래그먼트 마커를 전파하게 되므로, 여전히 페이지 캐시에 기반한 페이지나 외부 소유 페이지를 참조하는 대상 SKB는 다음과 같이 보고합니다. skb_has_shared_frag() 로 처리합니다. 이후의 인플레이스 라이터는 해당 페이지를 변경하지 않고 안전한 복사본으로 대체합니다. 이 수정 사항은 5월 21일에 업스트림에 반영되었으며, 이전 DirtyFrag 버그를 해결한 동일한 시리즈의 일환으로 5월 24일 Linux v7.1-rc5에 포함되었습니다. 안정판 및 백포트 커밋 ID는 브랜치에 따라 다르므로, 특정 업스트림 해시 대신 사용 중인 배포판의 공지 사항을 참고하시기 바랍니다.

누가 영향을 받나요?

일반 리눅스 사용자의 경우, 실행 중인 커널에 DirtyFrag, Fragnesia, DirtyClone에 대한 완전한 수정 체인이 적용되지 않았고, 시스템이 신뢰할 수 없는 로컬 코드가 익스플로잇에 필요한 네트워킹 기능에 접근할 수 있도록 허용한다면 위험을 감수해야 합니다. 공개된 보고서에 따르면, 일반적인 구성 환경에서 권한이 없는 사용자 네임스페이스로 인해 익스플로잇이 더 쉽게 발생할 수 있는 배포판으로는 데비안(Debian), 페도라(Fedora), 우분투(Ubuntu) 등이 확인되었습니다. 우분투 24.04 및 이후 버전에서는 기본 익스플로잇 경로를 차단할 수 있는 AppArmor 제한 사항이 추가되었으나, 이는 특정 경로에 대한 보안 강화일 뿐, 기본 커널이 수정되었다는 증거는 아닙니다.

RHEL 계열 시스템의 경우 상황은 더 단순하며, 두 가지 질문으로 귀결됩니다. 해당 커널이 DirtyFrag 및 Fragnesia 에라타와 관련된 것인지, 그리고 호스트에서 재부팅 없이 적용 가능한 패치를 실행 중인지 여부입니다.

악용 가능하며, 전체 체인이 누락된 커널에서 내부적으로 재현됨:

• EL9 켜짐 5.14.0-611.49.2.el9_7, 덮어씁니다 /usr/bin/su 그리고 산출량은 uid=0.
• EL10 켜짐 6.12.0-55.27.1.el10_0, 결과는 똑같다.

취약하지 않은:

• DirtyFrag 및 Fragnesia 수정 사항이 모두 포함된 현재 사용 가능한 커널, 예를 들어 EL10 6.12.0-211.16.1.el10_2, 여기서 PoC가 재현되지 않습니다.
• 다음에 있는 재부팅 없이 적용 가능한 패치로 보호되는 모든 호스트는 esp4 모듈.

CVE-2026-43503의 영향을 받지 않음:

• RHEL 6, 7 및 8. 레드햇은 이 특정 CVE와 관련하여 해당 버전이 영향을 받지 않는다고 명시하고 있습니다. 이 내용을 엄격하게 해석해야 합니다. DirtyFrag 계열에 따라 영향을 받는 스트림 목록이 다르기 때문에, CVE-2026-43503에 대해 문제가 없는 스트림이라고 해서 모든 관련 CVE에 대해서도 반드시 문제가 없는 것은 아닙니다.

레드햇은 CVE-2026-43503의 영향을 받는 코드 스트림으로 RHEL 9, RHEL 10 및 OpenShift RHCOS를 명시하고 있습니다. 이는 영향을 받는 코드 스트림을 나타내는 것이지, 완전히 업데이트된 호스트를 의미하는 것은 아닙니다. 여기서 ‘영향을 받음’은 “해당 코드가 여기에 포함되어 있다”는 의미로 해석해야 하며, “현재 모든 RHEL 9 또는 10 시스템이 당장 악용될 수 있다”는 뜻은 아닙니다.

업데이트 제공 시기도 배포판과 커널 계열에 따라 다릅니다. 특히 CloudLinux(CL8 및 CL9)의 경우 이 계열에 대한 EL 피드보다 업데이트가 늦어질 수 있으므로, CL 사용자는 두 버전이 동일하다고 가정하지 말고 자신의 정확한 버전을 확인해야 합니다.

온 가족에게 해당되는 주의 사항이 하나 있습니다. 단순히 PoC의 가정을 충족하지 못하는 호스트가 수정된 호스트와 같은 것은 아닙니다. 익스플로잇 실행에 실패했다고 해서 안전하다고 가정하지 말고, 커널에 오류 수정 사항이 완전히 반영되었는지 확인하십시오.

지금 바로 위험을 줄이세요

근본적인 해결책은 커널 패치나 재부팅 없이 적용되는 패치입니다. 이러한 해결책이 모든 환경에 적용되기 전까지는, 해당 취약점을 악용하기 위한 전제 조건을 제거하는 조치들이 유용합니다.

1. 먼저 패치를 적용하거나 재부팅 없이 적용되는 패치를 적용하십시오.

사용 중인 배포판의 수정된 커널을 설치하고 재부팅하여 해당 커널로 부팅하거나, 재부팅이 불가능한 경우에는 재부팅 없이 적용할 수 있는 패치를 적용하십시오. 이 수정 사항은 이미 EL9 및 EL10 피드에 포함되어 있으므로, 대부분의 호스트에서는 기다릴 필요 없이 바로 업데이트만 하면 됩니다.

2. 권한이 없는 사용자 네임스페이스 제한

이 체인에는 다음이 필요합니다. CAP_NET_ADMIN 권한이 없는 사용자가 TEE 규칙과 XFRM SA를 설치할 수 있게 합니다. 이를 제거하면 공용 경로가 작동하지 않게 됩니다.

# EL family:
sudo sysctl -w user.max_user_namespaces=0
echo 'user.max_user_namespaces = 0' | sudo tee /etc/sysctl.d/99-dirtyclone.conf

# Debian / Ubuntu:
sudo sysctl -w kernel.unprivileged_userns_clone=0
echo 'kernel.unprivileged_userns_clone = 0' | sudo tee /etc/sysctl.d/99-dirtyclone.conf

폭발 반경. 이로 인해 루트 권한이 없는 Podman과 루트 권한이 없는 Docker가 작동하지 않게 되며, unshare(1), 크로미움의 샌드박스, 일부 CI 샌드박스, bwrap Flatpak 등. 보안이 강화된 대부분의 서버 클러스터에서는 사용이 가능하지만, 컨테이너 및 개발자 호스트에서는 시스템 운영에 지장을 줄 수 있습니다. 광범위하게 배포하기 전에 테스트하십시오.

3. IPsec이 사용되지 않는 경우 ESP 모듈의 자동 로딩 차단

아니요 esp4 또는 esp6, DirtyClone 경로에 대한 인플레이스 복호화 싱크가 없습니다.

echo -e 'install esp4 /bin/false\ninstall esp6 /bin/false' | sudo tee /etc/modprobe.d/dirtyclone-esp.conf

IPsec이나 XFRM을 사용하는 호스트에는 이 설정을 적용하지 마십시오. ESP 전송을 비활성화하여 터널 연결이 끊어질 수 있습니다. 관련 가족 전체를 위한 참고 사항 하나: 이전의 DirtyFrag 연구에서도 다음과 같은 문제가 제기된 바 있습니다. rxrpc 인플레이스 쓰기 싱크로서, 해당 계열 전체에 대한 보안 강화는 차단으로 이어질 수 있습니다 rxrpc 또한, 이 설정은 AFS 및 기타 RxRPC에 의존하는 워크로드를 중단시키므로, 적용 범위를 신중하게 결정하고 해당 기능이 사용되지 않는 곳에서만 적용해야 합니다. 드롭인 파일을 제거하고 다시 로드하여 적용된 수정 사항을 원상복구하십시오.

sudo rm -f /etc/modprobe.d/dirtyclone-esp.conf /etc/sysctl.d/99-dirtyclone.conf
sudo sysctl --system

결정적인 순간입니다. 호스트에서 IPsec도, 루트리스 컨테이너도 실행하지 않는다면 두 방법 모두 유효하며, ESP 모듈 차단이 더 제한적인 변경 사항입니다. IPsec은 필요하지만 루트리스 컨테이너는 필요하지 않은 경우, 권한이 없는 사용자 계정을 비활성화하십시오. IPsec과 루트리스 컨테이너가 모두 필요한 경우, 워크로드를 중단시키지 않는 유일한 해결책은 재부팅 없이 적용 가능한 패치나 수정된 커널을 사용하는 것이며, 해당 조치가 적용될 때까지는 신뢰할 수 없는 로컬 실행을 격리해야 합니다.

재부팅 없는 패치 적용

바로 이런 종류의 버그를 해결하기 위해 KernelCare와 같은 재부팅 없이 패치를 적용하는 솔루션이 존재합니다. 전체 서버 군을 재부팅하여 수정된 커널로 전환하는 것은 말로는 쉽지만 실제로 일정을 잡기는 어렵습니다. 반면, 서비스 중단 없는 패치 적용 방식은 가동 시간을 훼손하지 않으면서도 동일한 문제를 해결해 줍니다.

해당 문제가 발생한 EL9 및 EL10 커널에서는 다음 위치에 적용됩니다. esp4 모듈을 통해, 안전하지 않은 쓰기 작업이 발생할 정확한 시점에서 ESP 입력 복호화 싱크를 차단합니다. 전파 버그로 인해 공유 프래그먼트 마커가 누락된 경우, 페이지 캐시로 뒷받침되는 프래그먼트에 대한 인플레이스 복호화는 수행되지 않고 거부됩니다. 이는 업스트림 마커 수정 사항과 동일한 보장을 제공하지만, 유지보수 기간을 거치지 않고 구현되었습니다.

DirtyClone과 CVE-2026-46300은 동일한 근본 버그와 수정 사항을 공유하기 때문에, 재부팅이 필요 없는 단일 패치로 두 가지 문제를 모두 해결할 수 있습니다. 적용 범위를 확인할 때 알아두면 좋은 점은, 일부 도구에서는 CVE 라벨이 실제 수정 시점보다 늦게 반영될 수 있기 때문에, 보호 상태가 CVE-2026-43503이 아닌 동일한 계열의 CVE-2026-46300 항목 아래에 표시될 수 있다는 것입니다.

이 경우의 이점은 미미하지만 실재하며, 이는 바로 재부팅 없이 패치를 적용하는 방식이 빛을 발하는 부분입니다. 가장 큰 위험에 노출된 호스트는 커널 업데이트가 뒤처진 호스트들인데, 바로 이러한 호스트들일수록 애초에 긴급 재부팅을 계획하기가 가장 어렵습니다. 재부팅 없이도 해당 호스트에서 DirtyClone을 종료할 수 있다는 점은, 문제를 오늘 해결하는 것과 다음 유지보수 시간대에 해결하는 것의 차이를 의미하며, 많은 시스템 군의 경우 바로 그 간극에 진정한 위험이 도사리고 있습니다.

탐지

DirtyClone에 대해 디스크 상에서 확인할 수 있는 신뢰할 만한 특징은 없으며, 이것이 바로 이 공격의 핵심적인 위험 요소입니다. 데이터 손상은 페이지 캐시에만 발생하며, 디스크에 저장된 바이너리 파일은 그대로 유지되고, 캐시 제거나 재부팅을 통해 원래의 바이트 데이터가 복원됩니다. 하지만 이는 공격자가 루트 권한을 획득한 후 발생한 모든 지속적 활동, 계정 변경 사항 또는 후속 활동을 되돌리지는 못합니다. 이 경우 파일 해싱은 취약한 보안 수단일 뿐입니다.

명백한 파일 무결성 증거를 남기지 않을 수는 있지만, 완전히 감지되지 않는 것은 아닙니다. 탐지는 주로 행동 기반 원격 측정 데이터를 통해 이루어지며, 다음의 각 항목은 확실한 증거라기보다는 단서에 가깝습니다:

• 예상치 못한 esp4 또는 esp6 IPsec을 실행하지 않는 호스트에서도 모듈이 로드됩니다.
• 권한이 없는 사용자 네임스페이스를 생성한 직후, XFRM SA를 설치하거나 netfilter TEE 규칙을 삽입합니다.
• 특이한 nft, iptables, XFRM 또는 로컬 사용자 컨텍스트에서 발생하는 TEE 활동.
• 다음과 같은 setuid 바이너리의 실행: su 또는 sudo 네트워킹 설정이 완료된 직후, 두 가지 모두를 건드릴 이유가 전혀 없는 사용자가 그 작업을 수행했습니다.
• 예상되는 보안 감사 이벤트가 발생해야 할 호스트에서 해당 이벤트가 갑자기 나타나지 않는 경우.

해당 기간 동안 노출된 EL9 또는 EL10 호스트에서 신뢰할 수 없거나 부분적으로만 신뢰할 수 있는 로컬 코드가 실행된 경우, 디스크에 증거가 없다는 사실을 침해되지 않았다는 의미로 해석하기보다는 패치 적용을 최우선으로 하고, 해당 호스트를 면밀히 조사해야 할 대상으로 간주해야 합니다.

이 주제가 중요한 이유

DirtyClone은 원격 코드 실행(RCE)이 아니며, 인증되지 않은 인터넷 사용자가 모든 리눅스 서버에 루트 권한을 얻을 수 있다는 의미도 아닙니다. 하지만 이 버그가 실제로 발생하는 환경에서는 그런 구분이 별다른 위안이 되지 않습니다. CI 러너는 다른 사람의 코드를 실행하기 때문입니다. 공유 호스팅 플랫폼은 고객의 코드를 실행합니다. 쿠버네티스 노드는 신뢰 수준이 각기 다른 컨테이너를 실행합니다. 개발자 샌드박스 및 빌드 호스트는 종종 이 클래스에 접근할 수 있게 만드는 바로 그 네임스페이스 동작을 허용합니다. 이러한 각 환경에서 로컬 권한 상승이 경계를 넘어서는 사건입니다. 이는 허용된 곳에서 실행되던 코드를, 절대 허용되어서는 안 될 곳에서 루트 권한을 얻은 코드로 바꿔버립니다.

DirtyClone이 헤드라인에서 시사하는 것보다 긴급도가 낮은 이유는, 동시에 이를 오해하기 쉬운 이유이기도 합니다. DirtyFrag 및 Fragnesia 체인이 완전히 포함된 커널은 보호됩니다. 하지만 여기서 핵심은 ‘완전’이라는 단어입니다. 원래 DirtyFrag 패치를 적용한 후 더 이상 업데이트를 진행하지 않은 커널이나, 배포판 백포트 적용이 지연된 호스트 역시 여전히 공격 경로에 노출되어 있습니다. 위험은 지난 유지보수 기간을 건너뛴 시스템, 아무도 재부팅하지 않는 장기간 가동 중인 CI 실행 서버, 그리고 다음 분기를 위해 따로 마련된 서버들에 집중되어 있습니다. 바로 이러한 호스트들에서 이와 같은 N-day 취약점이 조용히 당일 문제로 변모하게 됩니다. 전체 수정 체인을 확인하지 않고 영향을 받는 커널 스트림만을 기준으로 삼는 스캐너 전용 워크플로는, 패치가 적용된 호스트에 대해 허위 경보를 울리거나 여전히 노출된 호스트를 놓칠 수 있습니다.

우선순위별 개선 조치 체크리스트

1. 먼저 커널 업데이트가 밀려 있는 EL9 및 EL10 시스템, 특히 컨테이너 호스트, CI 실행 서버, 공유 시스템 및 멀티테넌트 환경에 패치를 적용하거나 재부팅이 필요 없는 패치를 적용하십시오.
2. 실행 중인 커널이 DirtyFrag, Fragnesia 및 DirtyClone에 대한 수정 체인을 모두 포함하고 있는지 확인해야 하며, 익스플로잇 실행에 실패했다는 사실만으로 안전성을 추론해서는 안 됩니다.
3. DirtyFrag의 부분적인 수정 사항은 여전히 취약한 것으로 간주하십시오. 전체 체인만이 해당 경로를 차단합니다.
4. rebootless-patch의 적용 범위를 확인할 때, CVE-2026-43503에 대한 매핑이 반영될 때까지는 일부 도구에서 해당 보호 기능이 CVE-2026-46300 항목 아래에 표시될 수 있습니다.
5. CloudLinux CL8 및 CL9의 경우 이 제품군의 EL 피드 전송이 지연될 수 있으므로, 사용 중인 정확한 버전을 확인해 주시기 바랍니다.
6. 워크로드가 허용하는 범위 내에서 권한이 없는 사용자 네임스페이스를 비활성화하십시오.
7. 차단 esp4 그리고 esp6 IPsec이 사용되지 않는 경우 자동 로드하고, rxrpc 또한, 대가족을 대상으로 보안 강화 조치를 취하고 있으며 AFS나 RxRPC를 사용하지 않는 경우에도 마찬가지입니다.
8. 특이한 네임스페이스, XFRM, ESP, TEE 등을 찾아보세요, nft, su, 그리고 sudo 노출 기간 동안의 활동 내역을 확인하고, 깨끗한 파일 해시는 불충분한 증거로 간주합니다.

모든 커널에 패치를 적용할 수 있으며, 재부팅이 필요하지 않습니다. 아직 KernelCare를 사용하지 않으신 분이라면, 지금이 바로 재부팅 없이 패치를 적용하는 방식이 긴급 유지보수 시간이나 가동 중단 없이 중요한 리눅스 시스템을 어떻게 보호하는지 확인해 볼 좋은 기회입니다.

지금 바로 KernelCare를 다운로드하세요 →

참조

• Red Hat CVE-2026-43503, 중요, CVSS 7.0, RHEL 9 및 10에 영향, RHEL 6/7/8에는 영향 없음; Bugzilla 2480902
• 레드햇 보안 데이터 JSON, CVE-2026-43503
• NVD CVE-2026-43503 (kernel.org CNA 점수 8.8, 적용 범위 변경)
• 데비안 보안 추적기, CVE-2026-43503
• 관련 결함 CVE-2026-46300 (Bugzilla 2477015), 동일한 근본 원인으로 인한 결함 skb_try_coalesce, 해결 방법을 공유합니다
• JFrog 보안 연구팀, “리눅스 LPE 변종 ‘DirtyClone (CVE-2026-43503)’ 분석 및 악용”
• SecurityWeek, ‘DirtyClone’ 리눅스 커널 취약점으로 루트 권한 획득 가능
• The Hacker News, 새로운 ‘DirtyClone’ 리눅스 커널 취약점으로 인해 로컬 사용자가 복제된 패킷을 통해 루트 권한을 획득할 수 있게 됨
• 공개 PoC, rafaeldtinoco/security/exploits/dirtyclone (JFrog; 김현우의 DirtyFrag ESP 프라이머리)
• Linux v7.1-rc5의 메인라인 수정 사항