유출된 리눅스 커널 보고서에 ksmbd 버그 두 건과 ‘Dirty Frag Fix’를 우회하는 루트 익스플로잇이 포함되어 있다

요약

전체 버전으로 이동 ↓

사건 개요: 2026년 10월 20일과 21일(UTC), 트렌드마이크로의 제로 데이 이니셔티브(ZDI)가 커널 보안 팀에 6건의 취약점 보고서를 보냈으며, 실수로 LKML 및 netdev를 포함한 공개 메일링 리스트에도 전송했습니다. 이 중 5건은 커널 버그이고, 1건은 사용자 공간 네트워크 관리자인 ConnMan의 문제입니다. 어떤 보고서에도 패치가 포함되어 있지 않았으며, 아직 CVE가 할당된 항목도 없습니다. 또한 3건에는 완전한 PoC 소스 코드가 포함되어 있었습니다. Phoronix는 10월 22일에 이 소식을 보도했습니다. 이 섹션으로 이동 →

중요한 취약점:ZDI-CAN-33367은 네트워킹 헬퍼인 skb_zerocopy의 버그로, 권한이 없는 로컬 사용자가 읽기 전용 파일의 페이지 캐시에 데이터를 쓸 수 있게 해줍니다. 이는 Dirty Pipe와 같은 유형의 취약점으로, 루트 권한 획득까지 단 한 걸음만 남았습니다. TuxCare는 사내에서 이 취약점을 재현하여 루트 셸을 확보했으며, 이는 5월에 적용된 Dirty Frag(CVE-2026-43284)에 대한 수정 사항을 우회합니다. 또한 이 보고서가 공개되었을 당시, 업스트림에 수정 사항이 병합되거나 배포판 커널에 포함되지 않은 상태였습니다. 따라서 이 취약점은 진정한 제로데이 취약점이었습니다. 이 섹션으로 이동 →

영향을 받는 대상: TuxCare의 테스트 결과, 이 익스플로잇은 AlmaLinux 8, 9, 10, CloudLinux 9, 10, Debian 12, 13, Ubuntu 24.04 및 26.04에서 루트 권한을 획득했으며, 이 과정에서 Ubuntu의 AppArmor 제한을 우회했습니다. CentOS 6 및 7 커널은 이 취약점에 영향을 받지 않습니다. 이 익스플로잇에 필요한 모든 모듈을 포함하고 있는 CloudLinux 8과 Ubuntu 22.04는 아직 테스트되지 않았습니다. 이 섹션으로 이동 →

9.0 ksmbd 점수에 대해서는 어떻게 될까요? 두 경우 모두 커널 내 SMB 서버가 실행 중이어야 하며, 관리자가 의도적으로 설정하지 않는 한 이 서버는 꺼진 상태로 유지됩니다. 공개된 PoC는 코드 실행보다는 커널 힙 누수와 충돌을 보여줍니다만, 더 심각한 문제가 발생할 가능성을 배제할 수는 없습니다. 이 섹션으로 이동 →

현재 상황: ZDI-CAN-33367에 대한 CVE는 아직 할당되지 않았습니다. 업스트림 수정 패치는 커널의 네트워킹 트리에 반영되었으나 아직 메인라인에는 반영되지 않았습니다. AlmaLinux 9는 수정된 커널을 배포한 반면, AlmaLinux 10은 아직 배포하지 않았습니다. KernelCare의 재부팅 없이 적용 가능한 패치는 EL10 및 EL9용으로 출시되었으며, EL8용은 출시 준비가 완료되었고, Debian 및 Ubuntu에 대한 작업은 진행 중입니다. 10월 27일 현재, 실제 환경에서 악용된 사례는 보고되지 않았습니다. 이 섹션으로 이동 →

오늘 할 일: 비특권 사용자 네임스페이스가 활성화되어 있는지 확인하고, 필요하지 않은 호스트에서는 이를 비활성화하십시오. A 0 여기서 ‘no’는 새로운 사용자 네임스페이스를 생성할 수 없음을 의미하며, 이는 공개 PoC를 차단해야 합니다:

sysctl user.max_user_namespaces

이 섹션으로 이동 →

로컬 권한 상승 버그는 대개 ‘다음 주에 해결할 문제’로 분류되는 경향이 있습니다. 먼저 셸을 확보해야 한다는 논리 때문인데, 이미 셸을 확보했다면 더 큰 문제가 있는 셈이니까요.

KernelCare가 주로 실행되는 호스트 환경에서는 이러한 논리가 성립하지 않습니다. 300개의 cPanel 계정이 있는 공유 호스팅 서버는 설계상 300명의 로컬 사용자를 가지며, 이들 각각은 PHP나 cron 작업을 실행할 수 있습니다. CI 러너는 풀 리퀘스트가 지시하는 모든 작업을 실행합니다. 대학의 로그인 노드는 셸을 제공하기 위해 존재합니다. 이 모든 경우에서 “로컬 사용자”는 단순히 “고객”이나 “작업”을 의미하며, 정상적으로 작동하는 페이지 캐시 쓰기 작업만으로도 이들 중 누구에게나 루트 권한을 부여할 수 있습니다.

이것이 바로 ZDI-CAN-33367의 문제점입니다. 수정 패치가 나오기도 전에 보고서, 분석 결과, PoC 소스 코드가 공개 커널 메일링 리스트에 올라왔습니다. 보통은 패치가 먼저 배포되고 그 후에 세부 내용이 공개되지만, 이번에는 그 순서가 반대로 진행되었습니다.

커널의 보안 버그 신고 지침에 따르면, 신고자는 공개 메일링 리스트가 아닌 서브시스템 관리자와 커널 보안 팀에 비공개로 버그를 전달해야 하며, 재현 방법도 공개하지 말아야 합니다. 이렇게 하면 다른 사람이 세부 내용을 확인하기 전에 수정 패치를 준비할 수 있습니다. ZDI도 일반적으로 동일한 방식으로 운영됩니다. ZDI의 공개 정책에 따르면, 세부 정보가 공개되기 전까지 벤더에게 패치를 배포할 수 있는 120일의 기간이 주어지며, 곧 발표될 권고 사항 목록에는 5건의 커널 보고서에 대해 2027년 2월 18일을 마감일로 명시하고 있습니다.

ConnMan 보고서는 10월 20일 00:17(UTC)에 공개 ConnMan 메일링 리스트에 처음 게시되었습니다. ZDI 자체 메일링 리스트에는 10월 19일로 기록되어 있는데, 이는 미국 시간 기준으로 보고서가 전송된 날짜입니다. ZDI-CAN-33367을 포함한 5건의 커널 보고서는 10월 21일 저녁(UTC)에 이어 게시되었으며, 커널 보안 팀은 물론 LKML, netdev, linux-cifs, dri-devel, linux-nvme 메일링 리스트에도 전달되었습니다. Greg Kroah-Hartman을 비롯한 여러 유지보수 담당자들은 해당 보고서가 이제 공개되었으며 패치 없이 접수되었다고 답했습니다. 6건 중 3건에는 상세한 설명과 완전한 PoC 소스 코드가 포함되어 있습니다. 2건의 커널 보고서는 제목 외에는 공개된 내용이 없으며, 마지막 1건은 커널 버그가 아닙니다.

이상하게도, 이 목록에서 커널 점수가 가장 낮은 버그가 바로 이 글에서 가장 많은 분량을 차지하고 있습니다. CVSS 기본 점수는 결함 자체를 나타낼 뿐입니다. 이 점수는 작동하는 익스플로잇 코드가 이미 공개되었는지 여부를 반영하지 않는데, ZDI-CAN-33367의 경우 이미 공개된 상태입니다. 익스플로잇 실행에 필요한 전제 조건이 갖춰진 호스트에서는, 점수 1~2점보다 그 사실이 훨씬 더 중요합니다.

이들 중 어느 것도 아직 CVE 번호가 할당되지 않았습니다. 단순한 서류 작업처럼 들릴 수 있지만, 많은 스캐너와 패치 대시보드가 모든 정보를 CVE ID를 기준으로 처리하기 때문에, 당분간은 이러한 보고서가 해당 도구들에 전혀 표시되지 않을 수도 있습니다. ID가 할당될 때까지는 평소 사용하던 도구를 수동 점검과 공급업체 업데이트로 보완해야 할 것입니다.

skb_zerocopy() 바이트를 복사하는 대신 동일한 메모리 페이지에 대한 참조를 전달함으로써 소켓 버퍼 간에 패킷 데이터를 이동시킵니다. 이는 처리량 측면에서 매우 효과적입니다. 또한 이는 페이지 캐시 버그에서 끊임없이 나타나는 일종의 지름길이기도 한데, 파일의 일부인 페이지에 대한 참조가 결국 쓰기 가능한 위치에 남게 되는 경우가 바로 그것입니다.

Dirty Pipe는 2022년에 파이프를 통해 이를 성공시켰습니다. Copy Fail은 2026년 4월 AF_ALG 암호화 소켓을 통해 이를 수행했습니다. 5월에는 Dirty Frag (CVE-2026-43284)가 IPsec 계층인 ESP를 통해 이를 수행했는데, 이 공격은 패킷의 페이지가 파일에 속해 있는 경우에도 패킷을 그 자리에서 복호화했습니다. ZDI-CAN-33367은 이 마지막 공격의 후속 사례입니다.

Dirty Frag 수정 사항에는 보호 메커니즘이 추가되었습니다. 커널이 독점적으로 소유하지 않은 페이지에서 패킷 데이터가 들어오면, 해당 데이터에는 SKBFL_SHARED_FRAG, 그리고 ESP는 해당 플래그를 확인한 뒤, 복호화하기 전에 비공개 사본을 생성합니다. skb_zerocopy() 동일한 페이지를 새로운 버퍼로 넘기지만 플래그는 함께 전달하지 않습니다. 가드(guard)는 작동하지 않고, ESP는 해당 위치에서 바로 복호화되며, 쓰기 작업은 공격자가 읽기만 가능한 파일의 페이지 캐시에 기록됩니다. 근본적인 오류는 커밋 단계로 거슬러 올라갑니다. af2806f8f90a, 이 책에서는 skb_zerocopy() 커널 3.14에서.

이로 인해 다소 어색한 결과가 발생합니다. AlmaLinux 8, 9, 10 버전 모두 ‘Dirty Frag’ 수정 사항을 포함하고 있으며, TuxCare도 AlmaLinux 커널 변경 내역에서 이를 확인했으나, 어쨌든 이 버전들은 여전히 취약합니다. CVE-2026-43284가 ‘해결됨’으로 표시된 패치 대시보드는 이 버그에 대해 아무런 정보를 제공하지 않습니다.

‘Dirty Pipe’와 마찬가지로, 이는 순수한 페이지 캐시 쓰기 공격입니다. 이후 해당 파일을 읽거나 실행하는 프로세스는 공격자가 조작한 버전을 받게 되며, ‘Dirty Pipe’와 ‘Copy Fail’의 경우 이러한 변경 사항이 디스크상의 파일에 반영되지 않아 포렌식 조사가 더 어려워졌습니다. setuid 바이너리를 대상으로 하거나 /etc/passwd 그리고 루트 권한 획득까지는 한 걸음만 더 가면 됩니다. 이 익스플로잇은 루트 권한을 얻기 위해 별도의 기능이나 KASLR 유출이 필요하지 않습니다.

공개된 PoC에는 구체적인 요구 사항 목록이 있습니다. 이 PoC는 권한이 없는 사용자 네임스페이스가 필요하며, 이는 권한이 없는 프로세스가 자체 샌드박스 내에서 네트워크 관리자 권한을 획득하는 일반적인 방식입니다. 또한 필요에 따라 자동으로 로드되는 모듈에 의존합니다: nfnetlink_queue, nft_queue, nlmon, cls_u32, act_pedit, act_mirred 그리고 esp4, 그리고 AEAD가 아닌 ESP 암호화의 기반이 되는 암호화 모듈들. 데비안 12의 6.1 커널에서는 파일 페이지를 패킷으로 전송하기 위해 약간 다른 경로를 거쳐야 하지만, 이 익스플로잇은 여전히 작동합니다. 이 목록은 공개된 익스플로잇을 설명한 것이지, 해당 버그를 악용할 수 있는 모든 경로를 다룬 것은 아닙니다. 하지만 이를 통해 완화 조치가 가능해지며, 이에 대해서는 아래에서 더 자세히 다룹니다.

Netdev 관리자인 Eric Dumazet은 다른 제보자가 일주일 전에 동일한 버그에 대한 패치를 함께 제출했으며, 수정 사항이 곧 제공될 것이라고 보고서에 답변했습니다. 10월 22일, 해당 패치가 netdev에 올라왔습니다. 이는 skb_zerocopy()가 공유 페이지 플래그를 복사하도록 하는 한 줄짜리 변경 사항이며, 안정판 팀에도 참조(Cc)로 전달되었습니다.  이후 이 패치는 커밋 `79dc34beb1fd`로 네트워킹 트리에 반영되었으나, 아직 메인라인에는 반영되지 않았습니다. 어쨌든, 유지보수자 트리에 수정 사항이 반영되었다고 해서 수정된 커널이 사용자의 호스트에 언제 도달할지는 알 수 없습니다. 업스트림의 수정 사항은 여전히 배포판 커널로 반영된 후 패키지가 되어야 하며, 이후 노출된 모든 서버에서 재부팅 또는 재부팅 없이 적용 가능한 패치를 통해 적용되어야 합니다. 한편, 이 취약점을 입증하는 PoC 코드는 이미 공개 아카이브에 저장되어 있습니다.

TuxCare는 아래의 각 대상에 대한 공개 PoC를 재구현하여 실행했습니다. “Root verified”는 uid 0 셸에서 종료되었음을 의미합니다.

이 두 가지 구버전은 각기 다른 이유로 안전합니다. CentOS 6의 2.6.32 커널은 skb_zerocopy() 전적으로 그렇기 때문에 악용할 여지가 전혀 없습니다. CentOS 7의 3.10 커널에는 이 기능이 있지만, 해당 커널의 ESP 코드는 비선형 패킷을 복호화하기 전에 항상 비공개 사본을 생성합니다. 인플레이스(in-place) 단축 기능은 4.11 버전에서 업스트림에 도입되었으나 EL7에는 반영되지 않았으며, 어차피 EL7에서는 비특권 사용자 네임스페이스가 기본적으로 비활성화되어 있습니다.

아직 테스트되지 않은 버전으로는 우분투 22.04와 EL ELS 커널, AlmaLinux ESU 및 FIPS 커널, 오라클 UEK, 클라우드 및 HWE 커널, CloudLinux 7 커널을 포함한 몇 가지 별도의 커널 계열이 있습니다. CloudLinux 8 역시 테스트되지 않았지만, 이 커널은 공개된 익스플로잇에 필요한 모든 모듈을 빌드합니다. 수정된 CloudLinux 7h 및 8 커널(4.18.0-553.177.1.lve.1)은 베타 버전입니다. 검증이 완료될 때까지는 이들 모두를 잠재적 취약 대상로 간주하십시오.

Ubuntu 24.04 및 이후 버전에서는 비특권 사용자 네임스페이스에 AppArmor 제한을 적용하며, 이는 다음으로 제어됩니다. kernel.apparmor_restrict_unprivileged_userns. 하지만 이로 인해 이 익스플로잇이 차단되지는 않았습니다. PoC는 사용자 네임스페이스 생성이 허용된 컨테이너 런처 패키지의 AppArmor 프로필을 통해 실행됨으로써 이를 우회합니다. 이를 완화 조치로 간주해서는 안 됩니다.

ZDI는 두 ksmbd 보고서에 모두 9.0점을 부여하고 이를 원격 코드 실행 취약점으로 분류했으며, 이로 인해 해당 사안이 헤드라인을 장식하게 되었습니다. 공개된 PoC(개념 증명)는 코드 실행보다는 커널 메모리 유출 및 시스템 충돌을 보여줍니다. 이 자체만으로도 심각한 보안 문제이며, 공개된 결과만으로는 공격자가 수행할 수 있는 행위의 전체적인 범위를 파악하기 어렵습니다. 또한 ZDI는 ZDI-CAN-33774에 대해 공개 자료에는 나타나지 않은 범위를 벗어난 쓰기 경로를 언급하고 있습니다.

피해 규모를 제한하는 요인은 노출 여부입니다. 두 버그 모두 커널에 내장된 SMB 서버 인 ksmbd에서 발생합니다. 이는 대부분의 리눅스 파일 서버에서 실행되는 사용자 공간 SMB 서버인 Samba와는 별개이며, Samba만을 통해 파일을 공유하는 호스트는 이러한 버그의 영향을 받지 않습니다.

AlmaLinux와 CloudLinux 9 및 10은 ksmbd를 아예 빌드하지 않습니다. Debian과 Ubuntu는 이를 빌드하지만, 사용자가 직접 선택해야만 설치됩니다. 관리자가 설치한 후에야 실행됩니다. ksmbd-tools, 이는 기본적으로 포함되어 있지 않으며, 다음을 시작합니다. ksmbd 서비스. ZDI-CAN-33549는 추가적인 조건을 더합니다. RDMA 네트워크 장치를 통한 SMB Direct와, 로그인 또는 게스트 액세스를 통해 접근 가능한 쓰기 가능한 공유 폴더가 필요합니다. 우분투는 SMB Direct를 기본으로 빌드하지만, 데비안은 그렇지 않으며, 호스팅 서버에서 RDMA 하드웨어를 찾아보기 어렵습니다.

ksmbd를 실행 중이라면 ZDI-CAN-33774 취약점을 심각하게 받아들여야 합니다. 이 취약점은 로그인 전에도 네트워크를 통해 접근 가능하며, 한 번에 28바이트의 커널 힙 정보를 유출시키고 호스트를 다운시킬 수 있습니다. ksmbd 유지보수자 전남재 답글을 달았습니다 그의 브랜치에서는 이미 다음과 같이 수정되어 있다는 점입니다. 커밋 68f410faedaf, 아직 메인라인에 반영되지 않은 기능입니다. 만약 systemctl is-active ksmbd '비활성'이라고 표시되어 있고 lsmod 나열되어 있지 않다 ksmbd, 이는 서버가 실행 중이 아니라는 좋은 징후이지만, 이 가능성을 배제하기 전에 호스트의 다른 어떤 프로세스도 이를 시작하지 않았는지 확인하십시오. 만약 서버가 실행 중이고 해당 공유에 의존하는 다른 프로세스가 없다면, 다음 명령어로 중지하십시오. systemctl disable --now ksmbd. 해당 공유 기능이 필요하다면, 수정된 커널이 제공될 때까지 신뢰할 수 없는 네트워크에서는 이를 사용하지 마십시오.

더미의 나머지 부분

ZDI-CAN-34068은 VMware의 가상 GPU용 드라이버인 vmwgfx에서 발생하는 범위를 벗어난 쓰기(out-of-bounds write) 취약점으로, 로컬 권한 상승으로 평가됩니다. ZDI-CAN-34076은 NVMe over Fabrics 대상인 nvmet에서 발생한 초기화되지 않은 메모리 누수입니다. 두 취약점 모두 제목만 공개된 상태입니다. 기술적 세부 정보가 없어 확인하거나 완화할 구체적인 사항이 없으므로, 추가 정보가 나올 때까지 별도의 조치는 계획되어 있지 않습니다.

ZDI-CAN-32005는 사용자 공간 네트워크 관리자인 ConnMan에 포함된 문제입니다. 이는 커널 버그가 아니므로 KernelCare가 수정하는 범위에 해당하지 않습니다. ConnMan을 배포하고 계신다면, 평소 이용하시는 패키지 채널을 통해 업데이트 소식을 확인하시기 바랍니다.

아래에 제시된 두 가지 완화 방안 모두 아직 사내 PoC를 통해 검증되지 않았습니다. 먼저 스테이징 호스트에서 각각을 테스트하여 어떤 요소가 이에 의존하는지 확인하시고, 두 방안 모두를 실제 수정 조치의 대체 수단으로 간주하지 마십시오.

가장 일반적인 방법은 권한이 없는 사용자 네임스페이스를 비활성화하는 것입니다. 설정 user.max_user_namespaces 에 0 새로운 사용자 네임스페이스의 생성을 차단하며, 공개된 PoC는 사용자 네임스페이스 생성에 의존하고 있으므로 이로 인해 차단될 것입니다. 우분투의 AppArmor 제한과 달리, 이는 어떤 AppArmor 프로필로도 우회할 수 없는 커널 수준의 엄격한 제한입니다:

echo 'user.max_user_namespaces = 0' > /etc/sysctl.d/99-zdi-33367.conf
sysctl --system

이미 존재하는 네임스페이스는 그대로 유지되므로, 그 안에서 이미 실행 중인 모든 것은 계속 실행됩니다. 또한 이에 따른 부담도 실제로 존재합니다. 루트리스 컨테이너, Flatpak 앱 및 일부 브라우저 샌드박스는 사용자 네임스페이스에 의존하기 때문에 오류가 발생할 수 있습니다.

더 가벼운 옵션은 공개 PoC가 의존하는 모듈 중 덜 흔히 사용되는 두 가지를 중단시키며, nlmon 그리고 act_pedit, 일반적인 모듈 메커니즘을 통한 로딩 과정에서:

printf 'install nlmon /bin/false\ninstall act_pedit /bin/false\n' > /etc/modprobe.d/zdi-33367.conf
lsmod | grep -E '^(nlmon|act_pedit) '

그리고 lsmod 이 줄은 현재 두 모듈 중 어느 것이 로드되어 있는지 여부를 알려줄 뿐입니다. 만약 하나가 표시된다면, 새 규칙은 해당 모듈을 언로드하지 않습니다. 해당 모듈에 의존하는 것이 없는지 확인한 다음, 다음 명령을 사용하여 해당 모듈을 언로드하십시오. modprobe -r, 또는 재시작을 예약할 수 있습니다. 하지만 결과가 비어 있다고 해서 해당 블록이 제대로 설정되었다는 증거는 아닙니다. 다음 명령을 실행하세요. modprobe -n -v nlmon 그리고 modprobe -n -v act_pedit, 그리고 둘 다 다음을 출력하는지 확인합니다. install /bin/false 줄. 이는 모듈 구성이 올바른지 확인해 주는 것이지, 익스플로잇이 차단되었다는 뜻은 아닙니다. 이를 사용하는 서버는 거의 없습니다. nlmon 또는 pedit ~에서의 활동 tc, 하지만 단정 짓기 전에 확인해 보세요. 이 두 가지를 차단한다고 해서 버그로 이어지는 모든 경로를 막을 수 있는 것은 아닙니다. 알려진 사실은 공개된 PoC가 이 두 가지를 필요로 한다는 것뿐입니다. PoC에는 esp4 마찬가지로, 호스트가 IPsec을 사용하지 않고 귀하가 차단한 경우 esp4 지난 5월에 진행한 ‘Dirty Frag’ 작업과 관련하여, 해당 블록이 여전히 제자리에 있는지 확인해 주세요.

사용자 네임스페이스를 비활성화하는 것이 주요 옵션이므로, 사용자 네임스페이스 없이도 문제없이 작동할 수 있는 호스트에서는 우선 이 방법부터 시도해 보세요. 먼저 해당 호스트에서 어떤 서비스가 실행 중인지 확인하십시오. 웹, 메일, 데이터베이스 및 공유 호스팅 서버의 경우, 해당 환경에서 루트리스 컨테이너나 샌드박싱을 사용하는 서비스가 없다면 일반적으로 사용자 네임스페이스를 비활성화하는 것이 실용적입니다. 반면 사용자 네임스페이스에 의존하는 CI 러너, 빌드 호스트 및 개발자 워크스테이션의 경우, 두 모듈을 차단하는 것이 시스템에 미치는 영향을 최소화하는 대안이 될 수 있지만, 버그가 발생할 수 있는 다른 경로는 여전히 남아 있을 수 있습니다. 재부팅 없이 적용 가능한 패치가 출시되면 이러한 호스트를 최우선으로 처리하십시오.

1분도 채 안 걸리는 서버 점검

다음 세 가지 명령어로 대부분의 질문에 답할 수 있습니다:

sysctl user.max_user_namespaces
systemctl is-active ksmbd
lsmod | grep -E '^(ksmbd|nlmon|act_pedit) '

A 0 첫 번째 방법에서는 새로운 사용자 네임스페이스가 비활성화되므로, 공개된 악용 경로를 차단할 수 있을 것입니다. inactive 두 번째 줄을 보면 ksmbd가 실행 중이 아닌 것으로 보이며, 세 번째 줄은 ksmbd 현재 해당 모듈이나 두 개의 차단 가능한 모듈 중 하나가 로드되어 있습니다. Ubuntu 24.04 및 이후 버전에서는 이 내용을 너무 깊이 해석하지 마십시오. sysctl kernel.apparmor_restrict_unprivileged_userns. PoC는 테스트 과정에서 해당 제한을 우회했습니다. 이는 대략적인 지표일 뿐, 완전한 보안 테스트는 아닙니다. 대규모 환경을 운영하는 경우, Ansible, Salt, 또는 루프 처리된 일반 SSH 등 이미 임시 명령을 처리하는 시스템을 통해 동일한 명령어를 실행해 보십시오.

KernelCare의 ZDI-CAN-33367에 대한 재부팅 없이 적용 가능한 패치가 AlmaLinux, CloudLinux, RHEL, Oracle Linux 및 Rocky Linux의 EL10 및 EL9 커널용으로 출시되었습니다. 이 패치는 업스트림 수정 후보를 기반으로 제작되었으며, TuxCare는 이 패치가 공개된 익스플로잇을 차단함을 확인했습니다. EL10 패치는 프로덕션 피드와 ePortal 피드 모두에 포함되어 있습니다. EL9 패치는 프로덕션 피드에는 포함되어 있으나, 아직 ePortal에는 포함되지 않았습니다. EL8 패치는 출시 준비가 완료되었으며, Debian 및 Ubuntu용 패치는 현재 개발 중이지만 출시 일정은 아직 정해지지 않았습니다. EL6 및 EL7 커널은 이 취약점에 해당하지 않으므로, 해당 버그에 대한 재부팅 없이 적용 가능한 패치는 제공되지 않습니다.

EL9 및 EL10에서 KernelCare 자동 업데이트가 설정된 호스트는 정상적인 일정에 따라 패치를 적용받으며, 사용자는 kcarectl –update 명령을 통해 즉시 패치를 적용할 수도 있습니다. 재부팅이 필요하지 않은데, 위의 모듈 차단 사항으로 인해 재부팅이 필요할 수 있으므로 이번 경우에는 평소보다 더 중요한 점입니다. CVE ID가 할당되지 않았기 때문에, TuxCare CVE 트래커에는 오늘 이 보고서에 대한 정보가 표시되지 않습니다. ID가 할당되면, 해당 트래커에 배포판별 재부팅 없이 적용 가능한 패치 상태가 표시될 것입니다.

지금 바로 KernelCare Enterprise를 이용하세요 →

왜 이런 정보 유출이 상황을 뒤바꾸는지

조율된 정보 공개는 방어 측에 선제적 대응의 기회를 주기 위한 것이지만, 이번 주에는 그러한 기회가 전혀 없었다.

조정된 공개 절차에 따르면, 기술적 세부 사항이나 익스플로잇 코드가 공개되기 전에 유지보수 담당자와 배포판 운영자들은 대개 수정 사항을 준비할 시간을 확보합니다. 하지만 이번에는 순서가 뒤바뀌었습니다. 먼저 익스플로잇이 작동하고, 그 후에야 수정 조치가 이루어진 것입니다. 공개된 익스플로잇과 패치가 적용된 호스트 사이의 이 간격은 모든 패치 프로세스가 최소화하려고 노력하는 부분인데, ZDI-CAN-33367의 경우 누구도 대응할 틈도 없이 그 간격이 벌어져 버렸습니다.

업스트림 수정본이 곧 나올 예정이며, 이미 네트워킹 트리에는 반영되어 있습니다. 일주일 전에 다른 누군가가 이 버그를 발견하고 패치를 보냈는데, 이는 현재 얼마나 많은 사람들이 같은 커널 코드를 꼼꼼히 살펴보고 있는지를 보여줍니다. 이와 같은 중복 사례가 더 많이 발생할 것이며, 안정판 커널에 수정 사항이 반영되기 전에 버그가 공개되는 경우도 더 늘어날 것으로 예상됩니다.

그러니 오늘 바로 사용자 네임스페이스를 확인하고, 필요 없는 곳에서는 모두 비활성화하세요. 누군가 ksmbd를 활성화해 놓고 잊어버린 경우가 있는지 확인해 보세요. 그런 다음 해당 수정 사항이 배포판의 커널에 반영되는지 주시하고, 재부팅 없이 적용되는 패치를 사용하든 재부팅을 하든, 시스템 군이 실제로 감당할 수 있는 방식에 따라 노출된 모든 호스트에 이를 얼마나 빨리 적용할 수 있을지 계획을 세우세요.

지금 바로 KernelCare Enterprise를 이용하세요 →

이번 주 일련의 사건들

출처

이 게시물의 주요 출처는 ZDI-CAN-33367 보고서, Eric Dumazet의 답변, skb_zerocopy 패치, ZDI-CAN-33774 스레드, ksmbd 수정 커밋, ConnMan 보고서 등을 포함한 공개 메일링 리스트상의 원본 ZDI 보고서와 유지보수자의 답변, 그리고 ZDI의 향후 권고 사항 목록, Phoronix의 관련 기사, 커널 보안 버그 보고 가이드, ZDI의 공개 정책, 커널의 ksmbd 문서, Max Kellermann의 ‘Dirty Pipe’ 분석 보고서, ‘Copy Fail’ 공개 내용, ‘Dirty Frag’에 대한 NVD 항목, 그리고 TuxCare가 위에서 언급한 배포판들을 대상으로 직접 수행한 테스트 결과 등이 포함됩니다.