OVSwrap 리눅스의 새로운 취약점으로 인해 기본 설정 시스템에서 로컬 사용자가 루트 권한을 획득할 수 있게 됨

요약

전체 버전으로 이동 ↓

개요: OVSwrap으로도 알려진 CVE-2026-64531은 Open vSwitch 액션 유효성 검사 경로에서 발생하는 리눅스 커널의 로컬 권한 상승 취약점입니다. 커널이 크기가 허용 범위를 초과하는 중첩된 액션을 생성할 때 16비트 길이 필드가 오버플로우되며, 이로 인해 파서가 공격자가 제어하는 바이트 영역 내에서 읽기를 재개하게 되고, 해당 바이트가 정상적인 Open vSwitch 액션으로 처리됩니다. 이 섹션으로 이동 →

영향: 일반 로컬 사용자가 커널 포인터를 유출하고, 커널 메모리를 읽으며, 표적 쓰기 공격을 수행할 수 있습니다. 공개된 개념 증명(PoC)은 이러한 과정을 연결하여 sudoers 항목을 작성하고 루트 셸을 여는 완전한 자격 증명 손상 경로를 보여줍니다. 이 PoC에는 약 800개의 x86-64 커널 빌드에 대한 사전 계산된 오프셋이 포함되어 있습니다. 이 섹션으로 이동 →

위험도: 위험도 점수가 7.8이므로, 이를 최우선 순위로 처리해야 합니다. 이 취약점을 악용하기 위해서는 일반적인 로컬 계정만 있으면 되며, 그 외에는 Open vSwitch 구성, 실행 중인 ovs-vswitchd, OVS 브리지, 초기 네임스페이스 내의 CAP_NET_ADMIN 권한, 특권 컨테이너 등이 전혀 필요하지 않습니다. unshare -Urn 명령어는 공격자가 생성한 네임스페이스 내에서 해당 기능을 제공합니다. 이 섹션으로 이동 →

영향을 받는 대상: 비특권 사용자 네임스페이스가 허용되고 openvswitch 모듈을 로드할 수 있는 모든 커널. 이는 대부분의 배포판에서 기본 설정으로 제공됩니다. 당사의 백포트 분석을 통해 확인된 적용 범위: Enterprise Linux 9.7 이상, Enterprise Linux 10.1 이상, Debian 12 및 13, Ubuntu 22.04 및 24.04, Amazon Linux 2023. 이 섹션으로 이동 →

상태: 제로데이 취약점이 아닙니다. 2026년 6월 19일에 비공개로 보고되었으며, 7월 24일에 안정화 브랜치에서 수정되었습니다. CVE 기록과 리눅스 CVE 공지는 7월 27일에 공개되었고, 이어 7월 28일에 전체 분석 보고서와 작동하는 익스플로잇이 공개되었습니다. 실제 환경에서 악용된 사례에 대한 공개적인 보고는 없습니다. 이 섹션으로 이동 →

지금 바로 다음 조치를 취하십시오: 고정된 벤더 커널을 적용하고 시스템을 재부팅하거나, KernelCare 재부팅 불필요 라이브 패치를 배포하십시오(이 패치는 이미 여러 배포판 사용자에게 자동으로 배포된 바 있습니다). 호스트가 Open vSwitch를 사용하지 않는 경우, 당분간 해당 모듈을 차단하십시오. 한 가지 주의할 점은, apparmor_restrict_unprivileged_userns 및 관련 Debian과 Ubuntu의 userns 강화 설정은 이 체인을 차단하지 못한다는 것입니다. 저희 커널 팀에서 이를 테스트했습니다. 이 섹션으로 이동 →

모듈이 로드되었는지 확인하는 것은 올바른 테스트 방법이 아닙니다. 실행 중인 커널에 대해 해당 모듈이 디스크에 존재하는지 확인하십시오:

ls /lib/modules/$(uname -r)/kernel/net/openvswitch/openvswitch.ko* 2>/dev/null

만약 경로가 출력된다면, 아직 해당 모듈을 로드한 것이 있든 없든 상관없이 커널에 패치가 적용되거나 모듈이 차단될 때까지 호스트가 노출된 상태가 됩니다.

OVSwrap 에 노출된 호스트 대부분은 Open vSwitch를 의도적으로 실행해 본 적이 없습니다. 바로 이 점이 팀들을 당황하게 만드는 부분입니다.

OVS는 OpenStack, OVN, 쿠버네티스 CNI, 가상화 플랫폼 등 소프트웨어 정의 네트워킹(SDN)과 널리 연관되어 있습니다. 사용자의 스택에 이러한 구성 요소가 하나도 없다면, 이 CVE가 해당되지 않는다고 보는 것이 타당합니다. 하지만 이 취약점이 있는 코드는 거의 모든 주요 배포판의 표준 커널 패키지에 로드 가능한 모듈 형태로 포함되어 있으며, 커널은 요청이 있을 때 이를 필요에 따라 로드합니다.

권한이 없는 사용자가 이를 요청합니다. 이 사용자는 개인 사용자 및 네트워크 네임스페이스를 생성하고, 해당 네임스페이스 내에서 CAP_NET_ADMIN 권한을 부여받으며, 이 권한만으로도 Netlink 인터페이스를 통해 Open vSwitch 플로우를 설치하기에 충분합니다. 이 요청에 따라 모듈이 호스트 커널에 자동 로드됩니다. 관리자의 승인도, 구성 파일도, 데몬도 필요하지 않습니다.

따라서 “우리는 Open vSwitch를 사용하지 않는다”는 말은 보안 위험에 대한 언급이 아닙니다. 이는 해당 모듈을 차단했을 때 문제가 발생할지 여부에 대한 언급이며, 이는 별개의 문제이자 더 유용한 질문입니다.

시점도 주목해야 할 또 다른 사항입니다. 업스트림 커밋 3f1f75536668은 이 취약점이 공개되기 4일 전에 안정판에 반영되었으므로, 안정판 커널 업데이트 주기가 짧은 플릿의 경우 이미 보호받고 있을 수 있습니다. 또한 4일은 “수정 패치 제공” 시점과 “800개 빌드에 대한 오프셋이 포함된 작동하는 익스플로잇”이 등장하기까지의 전체 기간이기도 합니다.

Open vSwitch 액션은 Netlink 속성으로 전달됩니다. 각 액션은 16비트 nla_len 필드를 포함하는 struct nlattr 헤더로 시작하며, 이 필드는 최대 65,535바이트까지 나타낼 수 있습니다.

OVS가 플로우를 검증할 때, 중첩된 액션을 커널이 직접 생성하는 내부 액션 스트림으로 확장합니다. 여기서 중요한 것은 OVS_ACTION_CLONE인데, 이는 다른 액션 목록을 감싸고 있으므로 중첩이 가능하기 때문입니다. 취약점이 있는 코드는 생성된 중첩 속성이 여전히 16비트 길이 필드 내에 들어가는지 확인하지 않았습니다.

[Attacker enters a private user and network namespace]
|
v
[Attacker gains CAP_NET_ADMIN inside that namespace]
|
v
[Attacker installs a flow packing hundreds of conntrack
actions inside a CLONE wrapper]
|
v
[Generated nested action stream exceeds 65,535 bytes]
|
v
[Length is stored in the 16-bit nla_len field and wraps
to a small value]
|
v
[Parser resumes mid-stream, inside attacker-controlled data]
|
v
[Forged action headers are parsed as real OVS actions]
|
v
[Kernel read and constrained write primitives]
|
v
[Host-process credentials corrupted, root shell]

이 익스플로잇은 CLONE 래퍼 안에 수백 개의 conntrack 액션을 압축해 넣습니다. OVS가 이를 확장함에 따라 생성된 스트림이 nla_len이 수용할 수 있는 크기를 초과하게 되고, 해당 값이 잘려나가 매우 작은 값으로 감싸지면서 파서가 잘못된 오프셋에서 중단됩니다. 이후 파서는 공격자가 선택한 바이트 영역, 즉 유효한 액션 헤더처럼 보이도록 조작된 부분에서 스트림 처리를 재개합니다. 커널은 이를 실제 액션으로 처리합니다.

접근성 요구 사항이 유일한 실질적인 제한 사항입니다. 즉, x86-64 아키텍처, conntrack 및 FTP-helper를 지원하는 OVS 커널 데이터 경로, 그리고 비특권 네임스페이스 생성이 허용되어야 합니다. rootless 컨테이너가 활성화된 기본 x86-64 배포판 커널은 이 세 가지 조건을 모두 충족합니다.

프라이머리트는 포지드 액션에서 파생됩니다.

가짜 터널 SET 작업은 커널 포인터 유출 및 커널 메모리 읽기 취약점을 유발합니다. 별도의 터널 대상 정리 경로는 특정 32비트 참조 카운트 감소 형태의 제한된 쓰기 취약점을 유발합니다.

단 한 번의 32비트 감산만으로는 별다른 영향을 미치지 못할 정도로 미미해 보이지만, 실제로도 그 자체로는 그렇습니다. 이를 둘러싼 일련의 과정이 결합되어 비로소 충분한 효과를 발휘하는 것입니다. 네임스페이스에 진입하기 전에, 이 익스플로잇은 호스트 측에 남아 있는 프로세스를 포크합니다. 그런 다음 해당 프로세스의 인증 정보를 대상으로 감산을 수행하고, 프로세스가 권한을 획득하면 sudoers 구성 파일에 항목을 추가한 뒤 루트 셸을 실행합니다.

그 결과, 시스템이 다운되는 대신 신뢰할 수 있는 권한 상승이 발생합니다. 약 800개의 커널 빌드에 대해 미리 계산된 오프셋을 활용하면, 지원되는 대상 시스템에서 이 현상을 재현하는 데 필요한 작업량은 거의 제로에 가깝습니다.

호스트를 악용할 수 있는지 여부는 두 가지 조건에 따라 결정되며, 이 두 가지 조건은 거의 모든 환경에서 기본값으로 설정되어 있습니다. 바로 비특권 사용자 네임스페이스가 허용되어 있고, openvswitch가 표준 커널 패키지에 포함되어 있으며 이에 대한 자동 로드 제한이 없다는 점입니다. 배포판들은 네임스페이스를 활성화된 상태로 두는데, 이는 rootless Podman, rootless Docker, Bubblewrap, Flatpak, 비특권 unshare(1), 그리고 Chromium의 샌드박스 등이 모두 네임스페이스에 의존하기 때문입니다.

공개된 공격 방식은 다음을 필요로 하지 않습니다:

• 실행 중인 ovs-vswitchd 프로세스
• 기존 Open vSwitch 브리지
• 기존 Open vSwitch 구성
• 호스트 네임스페이스 내의 CAP_NET_ADMIN
• 특권 컨테이너
• 공격이 시작되기 전에 로드해야 하는 모듈

즉, 공격 표면은 OVS를 적극적으로 실행하는 호스트보다 더 넓다는 뜻입니다. 여기에는 권한이 없는 사용자도 모듈을 실행할 수 있는 취약한 시스템이 포함되며, 연구원의 테스트 결과 이는 기본 설정으로 테스트된 대부분의 배포판에 해당한다는 사실이 밝혀졌습니다.

그 결과가 어떻게 될지 상상해 보세요. 마지막 병합 요청에서 푸시된 내용을 무조건 실행하는 공유 빌드 러너. 일반 계정에서 고객 코드가 실행되는 멀티테넌트 노드. 루트 권한이 없는 컨테이너와 아무도 읽어보지 않은 수백 개의 종속성이 있는 개발자 워크스테이션. 이 모든 경우에서 공격자는 이미 로컬 계정을 확보한 상태이며, 필요한 모듈은 단 한 번의 Netlink 요청만으로 스스로 로드될 수 있습니다.

각 호스트에 대한 결정은 간단합니다:

• 호스트가 OVS를 사용하지 않고, 해당 호스트의 어떤 구성 요소도 OVS 기반 브리지에 의존하지 않는다면, 해당 모듈을 차단하십시오. 이렇게 하면 해당 경로 중 하나를 차단하는 대신, 취약점이 있는 코드 경로 자체를 제거하게 됩니다.
• 호스트가 OVS를 사용하는 경우(OVN 또는 OpenStack Neutron 노드이든, ovn-kubernetes 또는 Antrea를 실행하는 Kubernetes 클러스터이든, OVS 기반 브리지를 사용하는 libvirt 또는 oVirt 호스트이든 상관없이) 해당 모듈은 그대로 두십시오. 대신 권한이 없는 사용자 네임스페이스를 거부하거나 패치를 적용하십시오.

버그는 오래된 것이지만, 이를 악용할 수 있는 기간은 그렇지 않다

두 가지 날짜가 중요하며, 이 두 날짜를 혼동하면 잘못된 분류 결과가 나옵니다.

16비트 길이 필드에 대한 안전하지 않은 할당 문제는 약 13년 전부터 존재해 왔습니다. 그 기간 대부분 동안 별도의 조건부 제한을 통해 생성된 액션 스트림의 크기를 32 KiB로 제한했기 때문에, 액션이 nla_len을 넘을 만큼 커지는 일은 결코 발생하지 않았습니다. 이 제한은 2025년 3월에 해제되었고, 그로 인해 잠재된 버그가 발현될 수 있게 되었습니다.

메인라인 기준으로 보면, 해당 문제가 발생하는 버전은 리눅스 6.14 무렵부터입니다. 이전의 장기 지원(LTS) 브랜치들은 원래 버그가 발생했을 때가 아니라, 제한 해제 패치가 해당 브랜치로 역포트되었을 때 취약해졌습니다.

공개된 안정 상태 범위:

• 5.15.180부터 5.15.211까지
• 6.1.132부터 6.1.177까지
• 6.6.84부터 6.6.144까지
• 6.18.0부터 6.18.39까지
• 7.1.0부터 7.1.4까지

보고된 최초 수정 릴리스: 5.15.212, 6.1.178, 6.6.145, 6.12.97, 6.18.40 및 7.1.5.

벤더 커널은 업스트림과 양방향으로 차이가 나기 때문에, 위의 범위는 정답이라기보다는 출발점에 가깝습니다. RHEL에서 파생된 일부 5.14 커널은 해당 기능을 활성화하는 변경 사항이 반영되어 있어, 표에 제시된 모든 범위보다 낮은 위치에 있음에도 불구하고 영향을 받습니다. 반면, 일부 SUSE 6.12 커널은 기존 상한값을 유지하고 있어, 표의 범위 내에 있음에도 불구하고 영향을 받지 않습니다.

엔터프라이즈 배포판은 업스트림 버전을 채택하지 않고 개별 커밋을 백포트하기도 하므로, 공개된 기간 범위를 벗어난 버전의 커널에도 여전히 취약점이 있는 조합이 포함될 수 있습니다. 이 기간 제한은 6.14 개발 라인에 직접 도입된 후, 해당 변경 사항이 이전 버전의 장기 지원(LTS) 브랜치로 백포트됨에 따라 해당 브랜치들로 확대 적용되었습니다. 정확한 배포판 커널에 대한 정보는 보안 권고문이나 패치 상태를 확인하시기 바랍니다.

2025년 3월, “net: openvswitch: 오작동을 일으키는 액션 길이 검사 제거”라는 커밋(a1e64addf3ff)을 통해 해당 제한이 제거되었습니다. OVS 액션은 내부 형식으로 변환되는 과정에서 길이가 늘어나거나 줄어들 수 있기 때문에, 이 제한으로 인해 예측 불가능한 오류가 발생했기 때문입니다. 총 길이 검사를 제거한 것은 합리적인 조치였습니다. 그 부작용으로, 개별 중첩 속성이 65,535바이트를 초과하는 것을 막을 수 없게 되었습니다.

당사의 커널 분석 결과, 다음 지원 플랫폼 계열에서 취약점이 있는 경로가 확인되었습니다:

• Enterprise Linux 9.7 이상
• Enterprise Linux 10.1 이상
• 데비안 12(6.1.132-1 버전 이후만 해당) 및 데비안 13
• Ubuntu 22.04 LTS 및 Ubuntu 24.04 LTS
• Amazon Linux 2023

Enterprise Linux의 적용 범위는 해당 RHEL, AlmaLinux, Rocky Linux 및 CloudLinux 커널 중 영향을 받는 코드를 공유하는 부분을 포함합니다. CloudLinux 9는 AlmaLinux 9 커널을, CloudLinux 10은 AlmaLinux 10 커널을 실행하므로, 두 버전 모두 이 취약점에 직접적으로 노출됩니다.

적용 범위는 릴리스 및 변형 버전에 따라 다릅니다. 동일한 배포판의 다른 릴리스가 목록에 포함되었다고 해서 인접한 스트림이 취약하거나 수정되었다고 추측해서는 안 됩니다.

아직 명확히 밝혀지지 않은 두 가지 사항이 있습니다. 엔터프라이즈 리눅스 8과 알마리눅스 8과는 별개의 커널 라인을 운영하는 클라우드리눅스 8은 아직 출시 여부가 확정되지 않았으며, 우분투 20.04와 그 이전 버전의 데비안 및 우분투 장기 지원(LTS) 브랜치 역시 마찬가지입니다. 이들 모두에 대한 의문점은 상한선 제거 기능을 역포트했는지 여부입니다.

초기에 버려야 할 한 가지 보안 강화 관련 가정은 다음과 같습니다. 연구원에 따르면, 테스트 결과 SELinux나 AppArmor 모두 이 익스플로잇의 어떤 단계도 차단하지 못했습니다. 단, 아래에서 다루게 될 일부 우분투(Ubuntu) 릴리스에서 AppArmor의 사용자 네임스페이스 정책이 네임스페이스 생성을 차단한 경우는 예외입니다. 이 경우 강제 모드(Enforcing mode)를 적용하더라도 결과는 달라지지 않습니다.

일반적인 사용자 네임스페이스 제한이 도움이 되지 않을 수 있는 이유

이 부분이 누군가의 주말을 날려버릴 가능성이 가장 높은 부분입니다.

최근 출시된 우분투 버전에는 커널의 `kernel.apparmor_restrict_unprivileged_userns` 설정으로 제어되는, 비특권 사용자 네임스페이스 생성을 제한하는 AppArmor 정책이 포함되어 있습니다. 이는 대부분의 팀이 가장 먼저 손대는 설정이며, 단순한 `unshare -Urn` 명령어 실행을 실제로 차단합니다. 우분투 24.04 및 26.04에서는 기본 정책이 적용된 상태에서 직접적인 시도가 실패합니다.

이것은 의존해서는 안 될 완화 조치입니다. 공개적으로 기록된 AppArmor 우회 기법은 24.04 버전에서 해당 정책을 무력화하며, 26.04 버전에서는 제한 기능이 비활성화되는 즉시 이 익스플로잇이 작동합니다. 저희 커널 팀은 데비안과 우분투의 사용자 보안 강화 기능이 활성화된 상태에서도 취약한 경로에 도달했습니다. 이 정책을 패치가 적용되기 전까지의 일시적인 방해물로 간주하십시오.

네임스페이스 생성을 아예 거부하면 공개 체인이 끊어지게 됩니다. 공격자가 더 이상 unshare -Urn을 통해 CAP_NET_ADMIN에 접근할 수 없기 때문입니다. 이를 수행하는 제어 메커니즘은 업스트림 측에 있습니다:

# /etc/sysctl.d/99-ovswrap.conf
user.max_user_namespaces = 0

sudo sysctl --system

kernel.unprivileged_userns_clone 대신 user.max_user_namespaces를 사용하십시오. 후자는 더 이상 사용되지 않는 데비안 계열의 다운스트림 패치로, 엔터프라이즈 리눅스에는 아예 존재하지 않습니다. 또한 두 설정이 모두 존재할 수 있는 우분투의 경우, unprivileged_userns_clone 설정만 적용하면 커널 버전에 따라 네임스페이스 생성을 위한 잔여 경로가 남을 수 있습니다.

실제로 적용된 값을 확인해 보십시오. 나중에 실행되는 /usr/lib/sysctl.d/에 있는 배포 파일이 아무런 경고 없이 우선 적용되기 때문입니다:

sysctl user.max_user_namespaces

호환성 문제는 실제로 발생합니다. 루트 권한이 없는 컨테이너 도구가 제대로 작동하지 않고, 권한이 없는 unshare(1) 명령어가 제대로 작동하지 않으며, 크로미움의 샌드박스도 제대로 작동하지 않습니다. 일반적인 호스팅 환경이나 데이터베이스 클러스터에서는 아무도 눈치채지 못하지만, 개발자 워크스테이션이나 컨테이너 빌드 호스트에서는 몇 분 안에 바로 문제가 드러납니다.

대안이 있을까요?

적절한 임시 해결책은 호스트가 실제로 Open vSwitch를 사용하는지 여부에 따라 달라집니다. 두 가지 방법 모두 근본적인 해결책의 대안이 될 수는 없습니다.

1. Open vSwitch 모듈을 차단하십시오. OVS를 사용하지 않는 모든 호스트(대부분의 호스팅 플릿이 이에 해당함)에서 이 방법을 권장합니다. 먼저 `lsmod | grep openvswitch`를 실행하여 `ovs-vswitchd`가 실행 중이 아닌지 확인하십시오. 그런 다음:

# /etc/modprobe.d/99-ovswrap.conf
blacklist openvswitch
install openvswitch /bin/false

실제로 작업을 수행하는 것은 install 명령어입니다. 블랙리스트 항목만으로는 커널 자체의 온디맨드 모듈 요청을 차단할 수 없는데, 이 익스플로잇이 바로 이 경로를 이용하기 때문에 블랙리스트 등록만으로는 이 문제를 완화할 수 없습니다. 또한, 루트 사용자는 modprobe –ignore-install 명령어를 사용하여 install 지시어를 무시할 수 있으며, initramfs를 통해 강제 로드되는 모듈은 두 지시어 모두의 적용을 받지 않는다는 점에 유의하십시오.

이 규칙은 향후 로드되는 모듈만 차단합니다. 모듈이 이미 메모리에 로드되어 있는 경우, 해당 모듈에 의존하는 모든 작업을 중지하고 모듈을 언로드해야 하며, 이 경우에도 재부팅이 필요하지 않습니다:

sudo modprobe -r openvswitch

모듈 파일은 디스크에 그대로 남아 있으며, 이후에도 modinfo openvswitch 명령을 실행하면 여전히 결과가 반환됩니다. 이는 정상적인 현상입니다. 해당 규칙의 로딩은 중단되지만, 아무것도 삭제되지는 않습니다.

OVN 또는 OpenStack Neutron 컴퓨팅 및 네트워크 노드, ovn-kubernetes 또는 Antrea를 사용하는 Kubernetes 클러스터, OVS 기반 브리지가 구성된 libvirt 및 oVirt 호스트에는 이 설정을 적용하지 마십시오. 해당 환경에서 이 모듈을 차단하면 네트워킹이 중단됩니다.

2. 권한이 없는 사용자의 네임스페이스를 거부하십시오. 위의 user.max_user_namespaces sysctl을 사용하십시오. 이 설정은 모듈 상태와 관계없이 작동하므로, 앞서 설명한 rootless-tooling 오작동을 감수해야 하지만, 실제로 OVS를 실행하는 호스트에 대한 대체 방안이 됩니다. 먼저 사용자의 워크로드를 대상으로 테스트해 보십시오.
3. 타사 BPF 가드 기능을 신중하게 다루어야 합니다. 공개 익스플로잇 저장소에는 BPF 기반의 긴급 가드 기능이 포함되어 있습니다. 당사는 이 기능을 테스트하지 않았습니다. 실제 운영 환경에 적용하기 전에 대표적인 시스템에서 검토 및 검증을 거치시고, 이를 공급업체의 수정 패치와 동등한 것으로 간주하지 마십시오.

패치를 적용한 후, 더 이상 필요하지 않은 경우 네임스페이스 제한을 해제하십시오:

sudo rm -f /etc/sysctl.d/99-ovswrap.conf

모듈 블록은 그대로 두어도 됩니다. 이 블록은 커널 버전에 구애받지 않으며, 업데이트나 재부팅 후에도 유지됩니다. 또한 Open vSwitch를 사용할 필요가 없는 호스트에서는 공격 표면의 일부를 차단해 줍니다. 향후 해당 호스트에서 OVS가 필요해질 경우 네트워킹이 실패하는 이유를 다음 담당자가 알 수 있도록 관련 내용을 문서화한 뒤, rm /etc/modprobe.d/99-ovswrap.conf 명령어를 사용하여 제거하십시오.

상류 수정 사항은 커밋 3f1f75536668, “net: openvswitch: 크기가 초과된 중첩된 액션 속성 거부”입니다.

이 기능은 nla_len에 안전하게 표현할 수 없는 크기의 생성된 중첩 액션을 거부하는 유효성 검사 기능을 추가합니다. 크기가 너무 큰 값이 16비트로 잘리는 것을 방치하는 대신, 커널은 유효하지 않은 액션이 데이터 경로에 도달하기 전인 유효성 검사 단계에서 이를 차단합니다.

이 변경 사항은 데이터 경로의 고속 경로가 아닌 유효성 검사 경로에 위치합니다. 커널 데이터 구조의 마이그레이션이나 태스크별 영구 상태가 필요하지 않기 때문에, 재부팅 없이 패치를 적용하는 데 적합합니다.

실행 중인 커널 패치 및 검증

업데이트된 커널 패키지를 설치한다고 해서 메모리에서 실행 중인 커널에 패치가 적용되는 것은 아닙니다. 일반적인 업데이트 절차는 다음과 같습니다. 사용 중인 배포판 및 릴리스에 정확히 맞는 수정된 패키지를 설치하고, 시스템을 재부팅한 후 수정된 커널이 실행 중인지 확인하십시오.

uname -r

디스크에 있는 최신 패키지가 아니라, 해당 공급업체의 권고 사항과 비교해 보십시오. 또한 2026년 7월 24일 이후에 빌드된 커널에 해당 수정 사항이 포함되어 있다고 가정하지 마십시오. 배포판 버전 번호는 업스트림 릴리스와 일대일로 대응하지 않으며, 이 브랜치들에 취약점이 도입된 것은 백포트 과정을 통해 이루어졌고, 수정 사항 역시 별도의 일정에 따라 백포트되었습니다.

재부팅 없는 패치 적용

KernelCare는 활성 커널에 동일한 업스트림 검증 로직을 적용합니다. 패치가 적용되면 OVS는 길이가 순환하기 전에 생성된 크기가 초과된 중첩된 작업을 거부하며, 이를 위해 Open vSwitch를 비활성화하거나 모듈 정책을 변경하거나 워크로드를 재시작할 필요가 없습니다. 이는 커널 전용 버그로, 사용자 공간 라이브러리 구성 요소를 추적할 필요가 없습니다.

대부분의 배포 환경에서는 설정된 간격(일반적으로 4시간마다)에 따라 백그라운드에서 새로운 패치를 자동으로 적용합니다. 프로덕션 피드에서 필요에 따라 패치를 가져오려면:

kcarectl --update

해당 커널 계열의 테스트 피드에서 패치가 아직 검토 중인 경우:

kcarectl --update --prefix test

그런 다음 설치된 패치 정보에 해당 CVE가 포함되어 있는지 확인하십시오:

kcarectl --patch-info | grep 'CVE-2026-64531'

임시 완화 조치를 제거하기 전에, 현재 실행 중인 커널 버전에 맞는 패치가 제공되는지 확인하십시오. 해당 커널 계열에 대한 패치가 아직 적용되지 않았다면, 모듈 차단 또는 네임스페이스 제한을 그대로 유지하십시오.

탐지 및 사고 검토

명확한 지표가 딱 하나 있는 것은 아니므로, 여기에 제시된 모든 내용을 ‘증거’라기보다는 ‘단서’로 받아들이시기 바랍니다.

가장 유용한 신호는 모듈 그 자체입니다. Open vSwitch를 정당한 용도로 사용하지 않는 호스트에서 lsmod에 openvswitch가 나타나는 것만으로도 이미 이상 징후이며, 이에 대한 모듈 로드 감사 기록이나 저널 항목을 면밀히 조사해 볼 가치가 있습니다. 이 신호는 modprobe 차단 기능을 적용하면 사라지므로, 적용하기 전에 먼저 확인해 보시기 바랍니다.

그런 다음, 공개된 PoC가 루트 권한을 어떻게 활용하는지 확인해 보세요:

sudo stat /etc/sudoers /etc/passwd /etc/shadow
sudo find /etc/sudoers.d -maxdepth 1 -type f -printf '%TY-%Tm-%Td %TH:%TM:%TS %p\n'

/etc/sudoers.d/ 디렉터리 아래에 예상치 못한 sudoers 항목이나 새로운 파일이 있는 것은 공개된 개념 증명(PoC)의 흔적이지만, 루트 권한을 가진 공격자는 이 단계를 완전히 건너뛸 수도 있습니다. 또한, 새로 생성되었거나 권한이 부여된 계정, 출처를 알 수 없는 SSH 키, 그리고 해당 sudo, 로그인 또는 인증 이벤트와 일치하지 않는 권한 상승 사례도 확인해야 합니다. 커널 쓰기 작업을 통해 자격 증명이 손상된 경우 인증 기록이 남지 않기 때문입니다.

기타 행동상 단서: 일반적으로 해당 작업을 수행하지 않는 워크로드가 사용자 및 네트워크 네임스페이스를 생성하는 비특권 프로세스, 루트 권한으로 실행되지만 루트로 시작되지 않았고 setuid 조상 프로세스가 없는 프로세스, 그리고 OVS 흐름 유효성 검사 경로에서 발생하는 커널 경고나 오류(oops) 등(유효성 검사 실패 시 발생할 수 있음).

저희는 아직 제한된 환경이나 컨테이너화된 환경에서 공개된 PoC를 사내에서 재현해 보지 못했으므로, 직접 환경에서 해당 시스템 호출 경로를 테스트해 보기 전까지는 사용자별 또는 컨테이너별 격리 기능만으로는 이 문제가 차단된다고 가정하지 마십시오.

아닙니다. 해당 문제는 2026년 6월 19일에 비공개로 보고되었으며, 수정 패치는 7월 24일 조정된 공개 유예 기간에 따라 안정화 브랜치에 반영되었고, 관련 문서와 PoC는 7월 28일에 공개되었습니다. 공개된 내용 어디에도 수정 패치가 적용되기 전에 실제 환경에서 악용된 사례에 대한 주장은 없습니다.

그렇다고 해서 이 문제가 우선순위가 낮은 것은 아닙니다. 이 취약점이 공개되자마자 공격자들은 일반 로컬 계정에서 루트 권한으로 상승하는 검증된 경로와 더불어, 방대한 커널 빌드 모음에 대한 오프셋 정보를 확보하게 되었습니다. 4일간의 선점 효과는 이미 안정판 커널에 대한 패치를 신속하게 적용하고 있던 시스템군에만 도움이 될 뿐입니다.

CVE-2026-64531이 중요한 이유

다음 세 가지 세부 사항 때문에 이 문제를 일상적인 일로 치부하기 쉬운데, 이 세 가지 모두 오해를 불러일으킵니다.

로컬 액세스가 필요하기 때문에 2단계 문제처럼 보이지만, 사실 테넌트, CI 실행자, 신뢰할 수 없는 종속성들은 이미 로컬 액세스 권한을 가지고 있습니다. Open vSwitch가 필요하기 때문에 틈새 네트워킹 문제처럼 보이지만, 해당 모듈은 요청 시 자동으로 로드됩니다. 또한 비특권 사용자 네임스페이스가 필요하기 때문에 기존의 보안 강화 조치로 이미 해결된 문제처럼 보이지만, 대부분의 데비안 및 우분투 팀이 이 부분에서 신뢰하는 특정 보안 강화 조치는 효과가 없습니다.

버전 이력에서 또 다른 교훈을 얻을 수 있습니다. 2025년 3월에 크기 제한을 제거한 변경 사항으로 인해, 10년 동안 방치되어 있던 할당 작업이 실제 권한 상승 취약점으로 변모했으며, 이는 릴리스가 아닌 일반적인 백포트 형태로 장기 지원 브랜치에 반영되었습니다. 업스트림 버전 번호만을 기준으로 삼는 분류 대기열이었다면, 해당 커널들을 처리 대상 범위 밖으로 판단했을 것입니다.

기존 방식으로 패치된 시스템의 경우, 공급업체 업데이트를 설치하고 호스트가 해당 업데이트로 정상 부팅되는지 확인하십시오. 긴급 재부팅 자체가 운영상의 위험을 초래하는 대규모 시스템 환경의 경우, KernelCare는 시스템을 오프라인 상태로 전환하지 않고도 실행 중인 커널 내에서 취약한 검증 경로를 차단합니다. 어느 쪽이든, 현재로서는 OVS를 사용하지 않는 모든 호스트에서 모듈을 차단하는 것이 가장 비용 효율적인 방법입니다. 이 방법은 되돌릴 수 있고 영향이 적으며, 해당 코드 경로와 씨름하기보다는 아예 제거해 버리기 때문입니다.

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

연표

참조

• 아심 마니자다, OVSwrap 공개, oss-security, 2026년 7월 28일, 및 seclists 미러
• OVSwrap 기술 문서: https://heyitsas.im/posts/ovswrap
• 공개된 OVSwrap 개념 증명 및 BPF 가드: https://github.com/manizada/OVSwrap
• Upstream Linux 수정 사항 3f1f75536668, “net: openvswitch: 크기가 초과된 중첩된 액션 속성 거부”
• CVE-2026-64531에 대한 리눅스 CVE 공지
• CVE 기록, CVE-2026-64531
• 해당되는 RHEL, AlmaLinux, Rocky Linux, CloudLinux, Debian, Ubuntu 및 Amazon Linux 보안 권고 사항