CIFSwitch 리눅스 커널 취약점으로 인해 cifs-utils에서 로컬 루트 권한 획득 가능

2026년 5월 28일 – 읽는 데 7분 크리스 드마르스, 수석 개발자 옹호자

요약

내용: CIFSwitch라고 불리는 새로운 리눅스 로컬 권한 상승 취약점은, cifs.spnego 키 설명에 대한 커널 측의 검증 누락과 사용자 공간의 cifs.upcall 헬퍼가 해당 설명에 부여하는 신뢰를 악용합니다. 이로 인해 영향을 받는 호스트의 권한이 없는 로컬 계정에서 루트 셸을 획득할 수 있습니다. 해당 커널 코드 경로는 2007년부터 존재해 왔습니다. 본 문서 작성 시점에는 아직 CVE가 할당되지 않았습니다.

영향: Asim Manizada가 공개한 이 개념 증명(PoC)은, 해당 취약점의 공격 전제 조건을 충족하는 시스템에서 권한이 없는 로컬 사용자라면 누구나 루트 권한을 획득할 수 있는 확실한 경로를 제공합니다. 작성자는 약 30여 개의 배포판 및 에디션 조합에서 이 취약점이 확인되었다고 밝혔습니다.

상태: Manizada는 리눅스 배포판에 대한 공개 유예 기간이 끝난 후 , 2026년 5월 28일 oss-security에 CIFSwitch 취약점을 공개했습니다. 이 버그는 5월 16일에 kernel/cifs 유지보수 담당자에게 보고되었으며, 업스트림 수정 패치 (커밋 3da1fdf4efbc)는 일주일 넘게 공개된 상태이며 안정판에 반영될 예정입니다.

중요도: AlmaLinux 9.7, Rocky Linux 9 Workstation, CentOS Stream 9 GNOME, Linux Mint 21/22, Kali 2021~2026 헤드리스 버전, SLES 15 SP7/SAP에서 설치 즉시 취약함이 확인되었습니다. Debian 11/12/13, Ubuntu 18/20/22/24.04, openSUSE Leap 15.6, Oracle Linux 8/9 및 Amazon Linux 2023에 cifs-utils를 수동으로 설치한 경우 취약합니다.

이 문제가 중요한 이유: 이 취약점은 기본적으로 설치된 특권 헬퍼를 노리며, 비특권 로컬 셸만 있으면 공격이 가능하며, 공개된 작동 가능한 PoC가 존재합니다. 권한이 없는 공격자가 코드를 실행할 수 있는 모든 리눅스 호스트는, cifs-utils 및 기본 cifs.spnego 규칙이 존재하고, CIFS 커널 모듈이 사용 가능하며, 권한이 없는 네임스페이스가 활성화되어 있고, LSM 정책이 피벗을 차단하지 않는 경우 즉각적인 위험에 처한 것으로 간주해야 합니다.

지금 바로 다음 조치를 취하세요: 호스트가 Kerberos 인증 SMB 공유를 마운트하지 않는 경우(대부분의 서버는 마운트하지 않음), 기본 cifs.spnego request-key 규칙을 재정의하거나 제거하세요. 루트 권한이 없는 컨테이너나 비특권 unshare 기능이 필요하지 않다면, 대신 비특권 사용자 네임스페이스를 비활성화하세요. 관련 명령어와 장단점은 아래에 나와 있습니다.

자세한 내용

아심 마니자다(Asim Manizada)는 리눅스 배포판(linux-distros)과 합의한 공개 유예 기간이 만료된 2026년 5월 28일, oss-security 메일링 리스트를 통해 CIFSwitch 취약점을 공개했다. 최초 보고서는 5월 16일에 커널 유지보수 담당자들에게 전달되었다. 업스트림 패치는 일주일 넘게 공개된 상태이며, 안정판(stable)에 적용될 예정으로 대기 중이다. 다운스트림 배포판들은 여전히 이 패치를 적용하고 있다.

이 커널 문제는 2007년 f1d662a 커밋으로 거슬러 올라가며, 이 커밋에서는 설명 검증 후크 없이 cifs.spnego 키 유형이 추가되었습니다. 이 결함은 19년 동안 잠복해 있었는데, 이는 실제 익스플로잇 체인이 이후 추가된 두 가지 요소, 즉 Linux v3.8(2013년)의 비특권 사용자 네임스페이스와 cifs-utils의 네임스페이스 전환 로직에 의존하기 때문입니다(명목상으로는 6.14 이상 버전이지만, 다른 CVE 수정 사항의 백포트(backport)로 인해 이전 버전의 cifs-utils에도 문제가 발생했습니다). 이 세 가지 요소가 모두 한곳에 모여 있지 않으면, 이 체인은 처음부터 끝까지 실행되지 않습니다.

마니자다는 자신의 보고서에서 이 버그가 커널 객체, 보안 속성, 그리고 해당 객체들이 커널과 사용자 공간 사이를 오가는 경계에 대해 LLM을 활용한 그래프 추론을 통해 발견되었다고 솔직하게 밝히고 있다. 이 발견 방식 자체만으로도 흥미롭다. 하지만 현재로서는 이 버그가 어떤 영향을 미치는지, 그리고 이를 어떻게 막을 수 있는지가 더 시급한 문제다.

이 취약점 공격의 작동 원리

이 공격은 네 가지 요소를 연결합니다. 바로 ‘키링(keyrings)’이라 불리는 리눅스 커널 기능, ‘cifs.upcall’이라는 사용자 공간 헬퍼, 리눅스 사용자 네임스페이스, 그리고 NSS(Name Service Switch)입니다. 각 요소는 제 역할을 수행하는 정상적인 인프라입니다. 문제는 커널과 사용자 공간 사이의 신뢰 경계가 제대로 적용되지 않았다는 점이며, 나머지 공격 과정은 이로부터 이어집니다.

1단계: 커널 키링과 cifs.spnego 키 유형

리눅스 키링(Linux keyrings)은 Kerberos 티켓 및 암호화 키와 같은 인증 자료를 저장하는 커널 하위 시스템입니다. 커널이 보유하지 않은 키가 필요할 경우, 콜아웃(callout) 메커니즘을 통해 사용자 공간에 키 생성을 요청합니다. /etc/request-key.d/에 있는 규칙은 “이 유형의 키를 생성하려면 이 헬퍼를 루트 권한으로 실행하라”고 명시하고 있습니다. Kerberos를 사용하는 SMB 또는 CIFS 마운트의 경우, 키 유형은 cifs.spnego이며 기본 헬퍼는 cifs-utils 패키지에 포함된 /usr/sbin/cifs.upcall입니다.

커널이 cifs.spnego 키를 요청하면, 권한을 나타내는 필드(마운트 사용자 ID, 자격 증명 UID, 프로세스 ID, 대상 네임스페이스)를 포함하는 설명 문자열을 생성합니다. 이 문자열은 커널에서 제공되어야 합니다. 사용자 공간 헬퍼는 이러한 필드를 신뢰하며, 이를 바탕으로 어떤 자격 증명을 조회할지, 어떤 네임스페이스에서 작업할지 결정합니다.

2단계: 누락된 커널 확인

사용자 공간에서는 request_key() 시스템 호출을 직접 호출하여 원하는 설명을 포함한 cifs.spnego 키를 요청할 수 있습니다. 패치 적용 전에는 커널의 cifs_spnego_key_type 정의에서 키링 하위 시스템에 “특정 출처의 설명만 허용하라”고 지시하는 .vet_description 후크가 누락되어 있었습니다. 이 후크가 없으면 권한이 없는 어떤 프로세스라도 위조된 설명이 포함된 cifs.spnego 키를 요청할 수 있으며, 키링은 공격자의 설명을 그대로 받아들여 루트 권한으로 cifs.upcall을 실행하게 됩니다.

마니자다(Manizada)의 분석 글에서 먼저 짚어둘 만한 세부 사항은 다음과 같습니다. 커널이 cifs.upcall을 실행하기 위해 실제로 키를 반환할 필요는 없습니다. 헬퍼가 먼저 실행됩니다. 커널이 키를 유효하지 않다고 거부할 때쯤이면, 루트 헬퍼는 이미 공격자가 의도한 작업을 완료한 상태입니다. 바로 이 점이 앞서 언급한 검증 후크의 부재가 그토록 심각한 결과를 초래하는 이유입니다.

3단계: 루트 헬퍼 내 네임스페이스 전환

cifs.upcall parses the description, finds upcall_target=app and pid=<some-pid>, and calls setns() to switch into the namespaces of the supplied pid. This is a deliberate feature, intended to make cifs.upcall resolve names against the right filesystem and network view when serving containerized mounts. The problem is that the kernel has just been tricked into trusting an attacker’s pid as if it came from a real kernel-side CIFS operation.

4단계: 코드 로딩 기본 요소로서의 NSS

루트 권한을 해제하기 전에, cifs.upcall은 getpwuid()를 사용하여 계정 조회를 수행합니다. 리눅스에서 계정 조회는 NSS(Name Service Switch)를 통해 이루어지는데, 이는 /etc/nsswitch.conf에 구성된 플러그인 방식의 시스템으로, 각 조회 유형에 대해 어떤 공유 라이브러리를 로드할지 결정합니다. 이제 cifs.upcall이 공격자의 마운트 네임스페이스 내에 위치하게 되었으므로, 이 함수가 읽는 nsswitch.conf는 공격자의 것이며, 로드되는 NSS 모듈은 공격자가 제어하는 libnss_*.so.2입니다. 이 공유 객체는 헬퍼 내부에서 루트 권한으로 실행됩니다.

5단계: sudo를 통한 지속성 확보

공개 PoC의 NSS 모듈은 /etc/sudoers.d/ 디렉터리에 파일을 생성하여 공격자에게 NOPASSWD: ALL 권한을 부여합니다. 헬퍼 프로세스가 종료된 후, 공격자는 네임스페이스를 벗어나 sudo를 실행합니다. 셸은 루트 권한을 갖게 됩니다. 디스크에 저장된 cifs.upcall 바이너리는 변경되지 않으며, 악용은 활성 헬퍼 프로세스와 공격자가 제어하는 네임스페이스 내에서 발생합니다.

수정 사항은 간단합니다. 업스트림 패치에는 current_cred()를 커널의 비공개 spnego_cred와 비교하는 4줄 분량의 cifs_spnego_key_vet_description() 함수가 추가되었습니다. 두 값이 일치하지 않으면 키 요청이 -EPERM 오류로 거부됩니다. 이 유형의 키를 생성할 수 있는 권한은 오직 커널 자체의 CIFS 코드 경로에만 부여됩니다. 이 조치만으로도 2단계에서 체인을 차단하기에 충분합니다.

누가 영향을 받나요?

이 취약점이 있는 cifs.spnego 코드 경로는 2007년으로 거슬러 올라가지만, 공개된 익스플로잇 체인은 사실상 리눅스 v3.8 시대의 비특권 사용자 네임스페이스 지원 기능과 기타 필수 조건이 모두 갖춰진 시스템에서만 실행 가능합니다. 이 익스플로잇 체인이 특정 호스트에서 작동하는지는 세 가지 하위 조건에 달려 있습니다. 즉, cifs-utils가 설치되어 있는지, 비특권 사용자 네임스페이스가 활성화되어 있는지, 그리고 호스트의 LSM 정책(SELinux 또는 AppArmor)이 체인의 어떤 단계도 차단하지 않는지 여부입니다.

기본 설정에서 바로 취약점 악용 가능 (cifs-utils 사전 설치, 비특권 네임스페이스 활성화, 기본 LSM 정책이 체인 허용): AlmaLinux 9.7 Workstation 및 Azure 클라우드 이미지, Rocky Linux 9 Workstation, CentOS Stream 9 GNOME, Linux Mint Cinnamon 21.3 및 22.3, Kali Linux 2021.4부터 2026.1까지(헤드리스), SLES 15 SP7, SLES SAP 15 SP7, SLES SAP 16.

또한 KernelCare에서 CloudLinux 10에 대해 내부적으로 확인했습니다. CL은 tuned 프로필을 통해 SELinux가 비활성화된 상태로 제공되므로, RHEL 10, AlmaLinux 10, Rocky Linux 10 및 Oracle Linux 10을 보호하는 SELinux 예외 처리 기능은 CloudLinux 10에는 적용되지 않습니다.

cifs-utils를 수동으로 설치한 경우 취약점이 발생합니다: Ubuntu 18.04, 20.04, 22.04 및 24.04 데스크톱 및 서버(24.04의 경우 AppArmor 사용자 정책을 우회하기 위해 공개적으로 문서화된 aa-exec -p trinity 트릭이 추가로 필요합니다); Pop!_OS 22.04 및 24.04; Debian 11, 12 및 13; CentOS Stream 9 Cinnamon/KDE/MATE/XFCE; Rocky Linux 9 KDE 및 Workstation-Lite; openSUSE Leap 15.6; Rocky Linux 8 GenericCloud; Oracle Linux 8 및 9 KVM; Amazon Linux 2023 KVM.

기본 정책으로 차단되었으나 내부적으로는 취약점 노출: 대부분의 EL10 배포판(RHEL 10, AlmaLinux 10, Rocky Linux 10, Oracle Linux 10)은 SELinux 강제 모드에서 cifs.upcall 네임스페이스 피벗을 차단합니다. Ubuntu 26.04는 기본 AppArmor userns 정책 하에서 해당 체인을 차단합니다. Fedora 40부터 44까지 및 CentOS Stream 10 역시 기본적으로 차단합니다. 운영자가 setenforce 0을 실행하거나 AppArmor userns sysctl 설정을 완화할 경우, 이러한 호스트는 공격에 취약해집니다.

일반 사용자가 악용할 수 없는 PoC: cifs-utils 6.2가 포함되어 있으며 네임스페이스 전환 로직이 적용되기 전 버전의 Amazon Linux 2. 기본적으로 user.max_user_namespaces가 0으로 설정된 CentOS 7 및 RHEL 7. 구버전 cifs-utils 6.9가 포함된 Kali Linux 2019.4 및 2020.4.

노출 여부는 궁극적으로 세 가지 요소에 달려 있습니다. 즉, cifs.upcall이 사용 가능한지, 권한이 없는 사용자의 접속이 허용되는지, 그리고 LSM 정책이 네임스페이스 피벗을 차단하는지 여부입니다. 다음 섹션에 소개된 명령어를 사용하여 이를 확인해 보십시오.

지금 바로 위험을 줄이세요

이 체인에는 두 가지 전제 조건이 있으며, 각각 명확한 완화 효과를 제공합니다. 작업 부하에 맞는 장단점을 가진 방식을 선택하십시오.

권장 사항: 기본 cifs.spnego 요청 키 규칙을 재정의하세요

호스트가 Kerberos 인증 SMB 공유를 마운트하지 않는 경우(대부분의 서버는 그렇지 않음), 기본 cifs.spnego 요청 키 규칙은 사용되지 않습니다. 이 규칙을 재정의하면 체인이 1단계에서 중단됩니다. NTLM/비밀번호 기반 SMB 클라이언트 마운트는 일반적으로 Kerberos SPNEGO 업콜에 의존하지 않지만, 규칙을 제거하기 전에 마운트 옵션을 확인하시기 바랍니다.

echo 'create cifs.spnego * * /usr/sbin/keyctl negate %k 30 %S' | sudo tee /etc/request-key.d/cifs.spnego.conf

사용 중인 배포판에서 keyctl 경로가 다르게 설정되어 있다면 해당 경로를 수정하십시오. 이는 작성자가 권장하는 재정의 방식과 일치하며, 키링(keyring)이 아닌 바이너리를 통해 요청을 실패로 처리하는 대신 키 요청을 깔끔하게 무효화합니다.

SMB를 전혀 사용하지 않는다면, 해당 파일을 완전히 삭제하십시오:

sudo rm /etc/request-key.d/cifs.spnego.conf

Kerberos 인증 SMB 공유를 마운트하는 호스트에는 이 설정을 적용하지 마십시오. cifs.upcall은 바로 해당 마운트가 의존하는 SPNEGO 티켓 헬퍼입니다.

패치가 적용된 후에는 cifs-utils를 다시 설치하여(기본 규칙으로 복원됨) 또는 사용자 정의 파일을 삭제하여 원래 상태로 되돌리십시오.

대안: 권한이 없는 사용자 네임스페이스 비활성화

PoC는 업콜을 트리거하기 전에 비공개 사용자 및 마운트 네임스페이스를 입력해야 합니다. 권한이 없는 사용자를 차단하면 cifs-utils의 상태와 관계없이 체인이 중단됩니다.

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

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

호환성 참고 사항: 비특권 사용자 네임스페이스는 루트리스 컨테이너 런타임(루트리스 Podman, 루트리스 Docker, bwrap 기반 Flatpak), 여러 CI 샌드박스, 비특권 unshare(1), 그리고 Chromium의 샌드박스에서 필수적으로 요구됩니다. 워크로드 호스팅 환경에서는 허용되지만, 개발자 호스트나 컨테이너 호스트에서는 운영에 지장을 줄 수 있습니다.

다른 방법: SMB 클라이언트를 사용하지 않는 경우 cifs-utils를 제거합니다.

대부분의 서버 클러스터에는 이 기능이 필요하지 않습니다. 이 패키지를 제거하면 cifs.upcall과 기본 request-key 규칙이 함께 제거됩니다.

# Debian / Ubuntu
sudo apt remove cifs-utils

# RHEL / AlmaLinux / Rocky / Oracle / CentOS Stream
sudo dnf remove cifs-utils

호스트가 노출되어 있는지 확인하세요

# Is cifs-utils installed?
command -v cifs.upcall && (rpm -q cifs-utils 2>/dev/null || dpkg -l cifs-utils 2>/dev/null)

# Is the default cifs.spnego request-key rule present?
cat /etc/request-key.d/cifs.spnego.conf 2>/dev/null

# Are unprivileged user namespaces enabled?
sysctl user.max_user_namespaces kernel.unprivileged_userns_clone 2>/dev/null

호스트는 cifs.upcall이 설치되어 있고, cifs.spnego 요청 키 규칙이 존재하며, 권한이 없는 사용자의 접속이 허용된 경우에만 유효한 대상이 됩니다.

KernelCare 재부팅 없이 적용되는 패치

2026년 5월 29일 14:00 UTC 기준 현황: EL8 재부팅 불필요 패치가 메인 피드에 배포되었습니다. AlmaLinux 9 패치도 메인 피드에 배포되었습니다. 나머지 EL9 변형, EL10, Oracle Linux UEK 커널(UEK6 및 UEK7), Ubuntu, Debian 및 Proxmox VE용 재부팅 불필요 패치는 테스트 피드에 배포되었습니다.

테스트 피드에 기능이 제공되면 아래 지침에 따라 신청해 주세요:

kcarectl --update --prefix test

검증이 완료되면, 패치는 다음 예정된 실행 시점에 적용되거나 필요에 따라 수동으로 적용할 수 있습니다:

kcarectl --update

패치가 적용되었는지 확인하십시오. 이 패치는 CVE ID가 없으며, 업스트림 설명을 통해 식별할 수 있습니다:

kcarectl --patch-info | grep 'cifs.spnego'
# expected: kpatch-description: smb: client: reject userspace cifs.spnego descriptions (cifs LPE)

CVE가 할당되면, kcarectl –patch-info | grep CVE-2026- 명령어를 실행하면 해당 정보를 확인할 수 있습니다.

향후 전개에 주목해야 할 점

CVE 할당은 아직 진행 중입니다. Red Hat, Ubuntu, Debian, SUSE, Oracle 및 Amazon의 배포판 커널 업데이트는 다운스트림 배포판들이 대기 중인 안정판 백포트를 적용함에 따라 순차적으로 배포되고 있습니다.

리부트 없이 적용 가능한 패치가 출시되고 CVE가 할당되는 대로 이 게시물을 계속 업데이트하겠습니다.

모든 커널에 패치를 적용하며, 재부팅이 필요하지 않습니다

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

KernelCare에 대해 자세히 알아보세요 →

요약

기사 이름

CIFSwitch 리눅스 커널 취약점으로 인해 로컬 루트 권한 획득 가능

설명

CIFSwitch는 cifs-utils, 사용자 네임스페이스 및 취약한 CIFS SPNEGO 처리 방식을 사용하는 시스템에서 루트 권한을 획득할 수 있는 리눅스 로컬 권한 상승 취약점입니다.

작성자

크리스 드마르스

게시자 이름

TuxCare

게시자 로고