‘Copy Fail’이 기존의 리눅스 커널 취약점 공격과 다른 이유는 무엇인가

이 블로그 글의 AI 요약으로 바로 가기

요약

내용: ‘Copy Fail’(CVE-2026-31431)이라 불리는 리눅스 로컬 권한 상승 취약점. 이는 커널의 인증 AEAD 경로에 존재하는 논리적 결함으로, 사용자 공간에서 AF_ALG 소켓 인터페이스와 splice(2)를 통해 접근할 수 있습니다.

영향: 공개된 732바이트 규모의 개념 증명(PoC) 코드를 사용하면, 취약한 커널을 실행 중인 주요 리눅스 배포판에서 권한이 없는 로컬 사용자를 루트 권한으로 안정적으로 승격시킬 수 있습니다.

상태: AlmaLinux, Ubuntu 및 기타 다운스트림 배포판에서 패치된 커널이 배포되고 있습니다. CISA는 5월 1일 CVE-2026-31431을 ‘알려진 악용 취약점’ 목록에 추가했습니다. CVSS 7.8 (HIGH).

위험도: 로컬 벡터, 권한 불필요, 사용자 상호작용 불필요, 매우 높은 성공률. 많은 컨테이너화되거나 공유 실행 환경에서, 컨테이너 내부에서의 성공적인 악용은 호스트 수준의 침해로 이어질 수 있습니다.

지금 당장 조치를 취하십시오: 영향을 받은 커널을 즉시 보호하십시오. 재부팅이 필요 없는 라이브 패치(live patching)를 사용하는 조직은 유지보수 시간대나 재부팅을 기다리지 않고도 이 취약점을 악용하는 경로를 차단할 수 있습니다. 그렇지 않은 경우, 운영상 가능한 한 빨리 공급업체에서 패치한 커널을 배포하십시오. 두 가지 방법 모두 즉시 실행할 수 없는 경우, 아래의 완화 지침을 따라 취약한 AF_ALG AEAD 경로를 일시적으로 비활성화하십시오.

‘Copy Fail’이 중요한 이유는, 공격자들이 가장 꺼리는 세 가지 요소, 즉 광범위한 유포 범위, 매우 높은 성공률을 보이는 공격 기법, 그리고 공개 당일에 공개된 개념 증명(PoC)이 결합되어 있기 때문이다.

저도 영향을 받나요?

아직 패치를 적용하지 않았다면, 거의 틀림없이 그렇습니다.

‘Copy Fail’ 취약점은 커널 4.14 버전부터의 상류 리눅스에 영향을 미치며, 이는 활발히 유지보수되고 있는 거의 모든 엔터프라이즈 배포판이 해당 취약한 코드 경로를 상속받았음을 의미합니다:

Resolute(26.04) 이전 버전의 Ubuntu
레드햇 엔터프라이즈 리눅스 8, 9 및 10
AlmaLinux 8, 9, 10 및 Kitten 10
Rocky Linux, CentOS Stream 및 Oracle Linux의 대응 버전
페도라 (현재 및 최근 버전)
데비안 안정판 및 테스트판
openSUSE Tumbleweed 및 Leap
CloudLinux 변형을 포함한 대부분의 다운스트림 리빌드

더 큰 우려는 적극적으로 관리되는 기업용 기기 군 외부의 장치들입니다. 여기에는 임베디드 리눅스 어플라이언스, 네트워킹 장비에 탑재된 OEM 커널, 산업용 시스템, 그리고 더 이상 패치를 받을 수 없는 수명 종료(EOL) 상태의 시스템 등이 포함됩니다. 만약 특정 장치가 최근에 공급업체의 커널 업데이트를 받지 못했다면, 해당 장치는 영구적으로 보안 위협에 노출된 상태로 남아 있을 수 있다고 가정해야 합니다.

이 취약점은 커널이 algif_aead를 노출하는지에 달려 있으며, 이는 배포판에 따라 두 가지 방식 중 하나로 구성됩니다.

간단히 확인해 볼까요:


# Check if loaded as a module (Debian, Ubuntu, Arch-family)

lsmod | grep '^algif_aead '

# Check if built into the kernel (RHEL, AlmaLinux, Rocky, CentOS Stream, Oracle, CloudLinux)

grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)

lsmod 출력이 비어 있다고 해서 완전히 안전하다고 볼 수는 없습니다. 데비안(Debian), 우분투(Ubuntu), 아치(Arch) 계열 배포판에서는 algif_aead가 필요에 따라 자동 로드되는데, 권한이 없는 프로세스라도 일치하는 알고리즘 이름을 가진 AF_ALG 소켓을 열기만 해도 로드를 유발할 수 있습니다. RHEL 계열 배포판에서는 해당 코드가 커널에 직접 컴파일되어(CONFIG_CRYPTO_USER_API_AEAD=y) 상태에 관계없이 lsmod에 절대 표시되지 않습니다. 커널 명령줄에서 AEAD initcall을 명시적으로 차단하거나 커널에 패치가 적용되지 않은 한, 해당 호스트는 취약한 것으로 간주해야 합니다.

또한 배포판이 사용자 네임스페이스를 강화한다고 해서 무조건 안전하다고 볼 수는 없습니다. ‘Copy Fail’ 트리거는 새로운 네임스페이스를 생성할 필요가 없습니다. 기본 설치 환경에서는 표준 비특권 프로세스에서도 AF_ALG 소켓 패밀리에 직접 접근할 수 있기 때문입니다.

‘카피 실패’란 무엇인가

Copy Fail은 리눅스 커널 암호화 하위 시스템의 로컬 권한 상승 취약점입니다. 이 버그는 IPsec ESN에 사용되는 인증 암호화 모드인 authencesn AEAD 템플릿에 존재하며, AF_ALG와 splice(2)를 함께 사용할 때 악용될 수 있습니다.

이 취약점을 유발하는 조합은 수년 간격으로 이루어진 세 가지 변경 사항에서 비롯되었으며, 그 어느 것도 그 자체로는 잘못된 것이 아니었습니다. 2011년에 IPsec ESP 확장 시퀀스 번호를 처리하기 위해 추가된 authencesn 템플릿은 호출자의 대상 버퍼를 임시 저장 공간으로 사용했는데, 커널 내부 xfrm 레이어에서만 이를 호출할 때는 아무런 문제가 없었습니다. 이후 AF_ALG는 AEAD 연산을 사용자 공간에 노출시켰다. 2017년, 성능 최적화를 위해 AEAD 경로 내부의 복사 작업이 제거되면서 커널이 제공된 메모리 페이지를 직접 조작할 수 있게 되었다. 이 조합은 splice(2)를 통해 파일 기반 페이지 캐시 페이지에 접근할 때 데이터 경로가 생성되면서 위험해졌다.

이 버그가 중요한 이유 중 하나는 바로 이 발견 자체에 있습니다. Theori의 연구원 이태양은 AF_ALG 소켓과 splice(2)를 결합하면 스캐터리스트(scatterlist) 페이지 출처와 관련된, 아직 충분히 탐구되지 않은 공격 표면이 생성될 수 있다는 가설을 세웠습니다. 연구팀은 수동으로 검토하는 대신, 이 한 줄짜리 가설을 AI 지원 스캐닝 시스템인 Xint Code에 입력하고 crypto/ 디렉터리를 대상으로 스캔을 실행했습니다. 약 1시간 후, 'Copy Fail'이 가장 심각한 수준의 취약점으로 확인되었습니다. 동일한 스캔에서 발견된 다른 고위험 버그들은 현재 조정된 공개 절차를 통해 처리 중입니다.

업스트림 수정 사항은 원래 최적화 커밋(a664bf3d603d)을 그대로 되돌린 것입니다. 이 세부 사항이 중요한 이유는, 이러한 버그가 검토 과정에서 종종 간과되는 경위를 잘 보여주기 때문입니다. 즉, 최적화 자체는 단독으로 볼 때 올바르게 보였지만, 인접한 실행 경로에 대해서는 전혀 고려되지 않았기 때문입니다.

‘카피 페일’이 다른 이유

지난 10년 동안 끊임없이 등장해 온 리눅스 LPE(로컬 권한 상승) 취약점들—Dirty COW, Dirty Pipe, StackRot, Dirty Frag 및 이와 유사한 취약점들—을 지켜보셨다면, 이 부분이 특히 주목할 만합니다.

‘Dirty Pipe’가 중요한 이유는 페이지 캐시 손상을 실질적인 권한 상승 기법으로 전환했기 때문입니다. 하지만 이 범주에 속하는 대부분의 버그는 여전히 실행상의 장애 요인이 존재했습니다. 이러한 버그들은 경합 조건이 발생하거나, 특정 커널 버전에만 국한되거나, 특수한 모듈에 의존하거나, 네임스페이스 제한으로 인해 차단되거나, 신뢰성이 낮아 방어 측이 현실적으로 시간을 벌 수 있을 정도였습니다.

Copy Fail은 이러한 불편함을 상당 부분 해소해 줍니다.

공개된 이 익스플로잇은 연구진이 테스트한 주요 리눅스 배포판에서 별다른 수정 없이도 작동하는 것으로 알려졌다. 배포판별로 별도의 대규모 오프셋 테이블이나 복잡한 대상 선택 로직이 필요하지 않다. 이 익스플로잇의 실행 경로는 이례적으로 호환성이 뛰어나다.

이 취약점이 노출된 기간도 유난히 길다. 해당 취약점을 유발하는 최적화 코드는 2017년 리눅스 업스트림에 도입되었으며, 현재까지도 공급업체의 지원 기간 내에 있는 장기 지원(LTS) 커널로 확산되었다. 여기에는 기업 시스템, 임베디드 시스템, 어플라이언스, 그리고 조직들이 수년간 업그레이드를 미루는 경우가 많은 고정된 인프라가 포함된다.

무엇보다 중요한 점은, 이 공격 기법이 매우 신뢰할 수 있다는 것입니다. 현대의 많은 커널 LPE(로컬 권한 상승) 공격은 확률적 특성을 띠는데, 힙 셰이핑, 레이스 타이밍, 또는 여러 기본 기법을 결합한 복잡한 연쇄 공격 등이 이에 해당합니다. 반면 ‘Copy Fail’은 비교적 단순합니다. 공격 시도는 호스트 시스템을 불안정하게 만들지 않은 채, 성공하거나 명확하게 실패합니다.

접근 가능한 공격 표면 또한 유난히 흔한 편입니다. 최근 일부 커널 취약점 공격에 활용된 틈새 모듈들과 달리, algif_aead는 주요 배포판 전반에 널리 포함되어 있으며, 기본적으로 컴파일되어 있거나 필요 시 자동 로드됩니다. 서버, 데스크톱, 컨테이너 호스트의 기본 설치 환경에서는 권한이 없는 프로세스에서 취약한 코드로 이어지는 접근 경로가 빈번하게 노출됩니다.

결과적으로, 기존의 많은 ‘시간 벌기’ 식 가정은 이 상황에서 별 도움이 되지 않습니다. 실제로 위험을 실질적으로 줄이려면 커널에 패치를 적용하거나 취약한 경로에 대한 접근을 차단해야 합니다.

현대적인 인프라가 왜 상황을 더 악화시키는가

“로컬 공격자”라는 용어는 과거에는 물리적 접근, 도난당한 SSH 인증 정보, 또는 사전 네트워크 침해와 같이 비교적 제한된 상황을 의미하곤 했습니다.

그 정의는 2026년 현재 리눅스 인프라가 운영되는 방식을 더 이상 반영하지 않습니다.

현대적인 인프라는 공유 실행을 기반으로 구축됩니다. 쿠버네티스 노드는 서로 다른 네임스페이스의 워크로드를 함께 호스팅합니다. CI/CD 러너는 외부 기여자가 제출한 풀 리퀘스트 코드를 실행합니다. 클라우드 노트북, 개발자 샌드박스, 멀티테넌트 SaaS 플랫폼, 빌드 시스템은 공유 커널에서 신뢰도가 부분적으로 확인된 코드를 일상적으로 실행합니다.

그런 환경에서 ‘지역적’이라는 표현은 점점 더 과거에 ‘인터넷에 노출된’이라는 말이 가졌던 의미와 비슷해지고 있다.

CI에 유입된 악성 npm 종속성, 낮은 권한의 셸을 제공하는 웹 애플리케이션 RCE, 해킹당한 개발자 계정, 또는 불완전한 컨테이너 탈출 체인 등은 모두 완전한 루트 권한을 획득하는 발판이 될 수 있습니다. Copy Fail은 초기 침투 지점과 완전한 커널 수준 침해 사이의 거리를 단축시킵니다.

이 취약점만으로는 원격으로 악용할 수 없습니다. 공격자는 여전히 호스트의 어딘가에서 코드 실행 권한을 확보해야 합니다. 하지만 공유 실행 환경에서는 잠재적인 발판이 이미 충분히 많기 때문에, 이러한 구분이 예전만큼 중요하지는 않습니다.

이 취약점 공격이 실제로 어떻게 작동하는가

리눅스는 AF_ALG 소켓을 통해 커널의 암호화 기능을 사용자 공간에 노출합니다. 프로세스는 authencesn(hmac(sha256),cbc(aes))와 같은 알고리즘을 요청하고 표준 읽기/쓰기 인터페이스를 통해 데이터를 전달할 수 있습니다.

2017년 최적화 작업에서는 특정 AEAD 연산 수행 시 불필요한 내부 복사를 피함으로써 성능을 향상시키려 했습니다. 입력 데이터를 임시 버퍼로 복사했다가 결과를 다시 복사해 내는 대신, 커널이 제공된 메모리 페이지에서 직접 연산을 수행할 수 있도록 한 것입니다.

이 가정은 입력이 파일 기반 디스크립터에서 splice(2)를 통해 전달될 때 성립하지 않습니다. 일반적인 읽기 및 쓰기 작업과 달리, splice는 데이터를 복사하는 대신 기존 캐시된 페이지에 대한 참조를 전달할 수 있습니다. 암호화 경로는 이러한 페이지를 쓰기 가능한 임시 저장 공간으로 잘못 간주하고, 해당 페이지에 대해 인플레이스 변환을 수행했습니다.

이러한 동작은 authencesn에 특유한 것입니다. GCM, CCM, 일반 authenc와 같은 다른 표준 AEAD 알고리즘들은 쓰기 작업을 정당한 출력 영역으로만 제한합니다. 원래 작업의 양 끝단을 모두 제어하는 내부 IPsec 코드 경로를 위해 작성된 authencesn 템플릿은 호출자의 대상 스캐터리스트를 임시 저장 공간으로 취급합니다. AF_ALG가 해당 경로를 사용자 공간에 노출하고 splice가 파일 기반 페이지를 그 안에 삽입했을 때, 그 결과로 생성된 프리미티브는 읽기 가능한 파일의 페이지 캐시에 작업당 4바이트를 제어된 방식으로 기록하게 되었습니다.

실제로 각 작업은 실패합니다. 암호문이 조작된 것이기 때문에 HMAC 검증이 실패하고, recvmsg()는 호출자에게 오류를 반환합니다. 그럼에도 불구하고 4바이트 쓰기 작업은 계속 수행됩니다. 공격자는 선택된 오프셋에서 이 작업을 반복함으로써 /usr/bin/su와 같은 setuid 바이너리의 캐시된 이미지에 셸코드를 심습니다.

디스크의 내용은 절대 변하지 않습니다. 변경 사항은 캐시된 페이지가 메모리에서 제거될 때까지만 메모리에 존재합니다. 따라서 공격자가 루트 권한으로 실행할 수 있을 만큼 충분히 오랫동안 캐시된 실행 파일 이미지가 변경되었더라도, 파일 시스템 무결성 검사 도구, 파일 해싱, 디스크 포렌식 분석에서는 아무런 이상 징후도 포착하지 못할 수 있습니다.

이 공개 PoC는 비교적 짧은 체인을 따릅니다:

authencesn에 바인딩된 AF_ALG 소켓을 엽니다
/usr/bin/su와 같은 setuid 바이너리를 읽기 모드로 열기
splice를 사용하여 대상의 캐시된 페이지를 AF_ALG 경로로 이동합니다
호출당 공격자가 선택한 4바이트를 기록하는 인플레이스 암호화 연산을 실행합니다
오프셋을 따라 반복하여 캐시된 이미지에 셸코드를 삽입합니다
수정된 캐시된 바이너리를 루트 권한으로 실행합니다

원본 Python PoC 외에도 C, Go 및 arm64용 재구현 버전이 이미 존재합니다. 대상 시스템에 구형 Python이 설치되어 있다는 점은 큰 장애물이 되지 않습니다. 더 심층적인 구현 세부 사항이 필요한 방어 담당자들에게는 여전히 원본 Xint/Theori 문서가 최고의 기술적 참고 자료입니다.

완화

가장 안전한 대응 방안은 실행 중인 커널을 즉시 보호하는 것입니다. 위험 노출을 줄일 수 있는 실질적인 방법 세 가지를, 처리 속도와 운영에 미치는 영향의 정도에 따라 순서대로 나열합니다.

1. 재부팅 없이 패치 적용 (가장 빠르며, 서비스 중단 없음)

KernelCare는 여러 다운스트림 배포판이 업데이트된 커널 패키지 버전을 배포하기 전에, 지원되는 실행 중인 엔터프라이즈 커널에 대한 ‘Copy Fail’ 취약점에 대한 라이브 패치를 공개했습니다.

재부팅이 필요 없는 이 패치는 시스템 재부팅 없이도 실행 중인 커널의 취약점을 차단하여, 다음 유지보수 주기를 기다릴 필요 없이 즉시 보안 위협을 줄여줍니다.

일부 취약점 스캐너는 재부팅 없이 패치를 적용한 후에도 영향을 받는 커널 버전을 계속 감지할 수 있습니다. 이는 공급업체 패키지 버전과 스캐너의 탐지 로직이 보호된 실행 중인 커널 상태보다 뒤처질 수 있기 때문입니다.

가동 시간이 중요한 인프라를 관리하는 조직에게 이는 문제를 해결하는 가장 빠른 방법입니다.

아직 KernelCare 고객이 아니신가요? 6월 말까지 신규 고객 대상 할인 혜택이 제공됩니다. KernelCare에 대해 자세히 알아보세요.

2. 패치된 커널을 설치하고 시스템을 재부팅합니다

일반적인 해결 방법은 공급업체에서 제공하는 패치된 커널 패키지를 배포하고 영향을 받은 시스템을 재부팅하는 것입니다.

조직은 자사가 사용하는 배포판에 대한 패치 제공 여부를 확인하고, 쿠버네티스 노드, CI/CD 러너, 공유 호스트, 개발자 인프라, 멀티테넌트 애플리케이션 플랫폼 등 부분적으로 신뢰할 수 있는 코드가 실행될 수 있는 환경을 우선적으로 관리해야 합니다.

3. 임시 수동 대응 조치 (패치 적용을 미뤄야 하는 경우)

라이브 패치나 즉시 재부팅 창을 사용할 수 없는 경우, 커널 명령줄을 통해 AF_ALG AEAD 공격 표면을 일시적으로 비활성화할 수 있습니다.

먼저 읽어주세요: 아래의 완화 조치는 AF_ALG AEAD 공격 표면을 제거합니다. 대부분의 워크로드는 성능 저하가 미미합니다. dm-crypt/LUKS, kTLS, IPsec/XFRM, OpenSSL, GnuTLS, NSS 및 SSH는 이에 의존하지 않습니다. OpenSSL afalg 엔진을 명시적으로 사용하거나, AF_ALG를 통한 하드웨어 암호화 오프로드, 또는 직접 AEAD 소켓 바인딩을 사용하는 애플리케이션은 오류가 발생하거나 성능이 저하될 수 있습니다. 광범위하게 배포하기 전에 반드시 검증하십시오.

먼저, 사용 중인 커널에서 algif_aead가 어떻게 제공되는지 확인하십시오:

# Loadable module (Debian, Ubuntu, Arch family)

grep -qE '^algif_aead ' /proc/modules && echo "loaded as module" || echo "not currently loaded"

# Built-in (RHEL, AlmaLinux, Rocky, CentOS Stream, Oracle Linux, CloudLinux)

grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)

config grep 명령어의 결과가 =y인 경우, 해당 코드는 커널에 컴파일됩니다. modprobe blacklists 및 rmmod 명령어는 오류 메시지 없이 성공한 것처럼 보이지만, 실제로는 아무런 보호 기능을 제공하지 않습니다.

범용 완화 조치 (모듈 및 내장 커널 모두에서 작동) – 커널 명령줄을 통해 initcall을 비활성화합니다:

sudo grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"

sudo reboot

재부팅 후 다음 사항을 확인하십시오:

grep -o 'initcall_blacklist=algif_aead_init' /proc/cmdline

출력이 비어 있다면 해당 매개변수가 적용되지 않았음을 의미합니다. grubby를 다시 확인하고 시스템이 실제로 재부팅되었는지 확인하십시오.

로드 가능한 모듈 전용 완화 조치 (데비안, 우분투, 아치 및 유사 배포판) – 재부팅을 미뤄야 할 때 유용합니다:

sudo sh -c 'echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif_aead.conf'

sudo rmmod algif_aead 2>/dev/null || true

확인:

grep -qE '^algif_aead ' /proc/modules && echo "still loaded" || echo "not loaded"

RHEL 계열 호스트에서는 이 방법을 신뢰하지 마십시오. 두 명령어 모두 시스템이 내장형인지 여부와 관계없이 성공 메시지를 반환하므로, 잘못된 보안 감각을 줄 수 있습니다.

악용이 의심될 경우, 캐시된 페이지를 지워 수정된 실행 페이지가 디스크에서 다시 로드되도록 하십시오:

sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

이는 확산 방지 조치일 뿐, 근본적인 해결책은 아닙니다. 공격자가 이미 루트 권한을 획득했다면, 시스템의 다른 곳에 이미 지속성 메커니즘이 존재할 수 있습니다.

SELinux와 AppArmor는 기술적으로 AF_ALG 소켓 생성을 차단할 수 있지만, 이는 제한되지 않거나 광범위하게 허용된 프로세스에 대해 이를 거부하도록 구성된 경우에만 가능합니다. 모든 주요 배포판의 기본 정책은 이를 허용합니다. MAC 기반 제한은 당일 대응책이 아닌, 전체 시스템에 대한 배포를 위한 보안 강화 조치로 간주해야 합니다.

OVHcloud는 쿠버네티스 운영자를 위해 관리형 클러스터용 DaemonSet 대응 방안을 발표했습니다. 이 방식은 비상 대응 기간 동안 클러스터를 일괄 재시작하기 어려운 모든 쿠버네티스 환경에 폭넓게 적용할 수 있습니다.

워크로드가 AF_ALG에 의존하고 있어 이를 비활성화할 수 없는 경우, 남은 옵션은 신뢰할 수 없는 로컬 실행을 격리하거나, 유지보수 시간이 확보될 때까지 커널에 재부팅 없이 패치를 적용하는 것입니다.

KernelCare Enterprise 사용자를 위해, 여러 다운스트림 배포판에서 업데이트된 커널 패키지 버전을 공개하기 전에, 기존 지원 대상 엔터프라이즈 커널에 대한 ‘Copy Fail’ 문제 해결용 재부팅 불필요 패치가 출시되었습니다.

그 결과, 일부 스캐너는 실행 중인 커널이 재부팅 없이 패치되어 이미 보호된 상태임에도 불구하고, 일시적으로 취약한 커널 버전을 계속 탐지할 수 있습니다. 이에 따라 공급업체 측에서 업데이트된 커널 빌드와 이에 상응하는 탐지 로직이 곧 제공될 것으로 예상됩니다.

탐지

‘복사 실패’에 대해 신뢰할 수 있는 침해 후 탐지 시그니처는 존재하지 않습니다.

공격이 성공하더라도 디스크에는 아무런 흔적도 남지 않으며, 시스템 호출 패턴은 정상적인 사용자 공간 암호화 활동과 유사하고, 페이지가 스왑아웃되면 캐시된 변경 사항도 사라집니다.

대부분의 환경에서, 공격이 발생하기 전에 시스템 호출 텔레메트리, eBPF 계측 또는 상세한 감사 로깅이 이미 활성화되어 있지 않은 한, 사후 확인은 어려울 것입니다.

주목해야 할 가장 유용한 신호로는 다음이 있습니다:

알려진 AF_ALG 소비자가 없는 시스템에서 algif_aead 모듈이 예기치 않게 로드됨
AF_ALG 활동 직후 su 또는 sudo가 비정상적으로 실행됨
파일 기반 설명자를 통해 AF_ALG 소켓을 대상으로 하는 splice(2) 작업

파이썬 실행 패턴에 기반한 탐지 규칙은 다른 구현 방식은 탐지하지 못할 수 있습니다. C, Go, arm64로 재구현된 이 익스플로잇은 이미 공개되어 있으며, 대상 시스템에 파이썬이 설치되어 있지 않아도 실행 가능합니다. 이는 확실한 보장 사항이 아닌 추론에 기반한 방법일 뿐입니다. 취약점이 노출된 기간 동안 신뢰할 수 없는 사용자가 셸 액세스 권한을 가졌던 시스템은 모두 잠재적으로 침해된 것으로 간주해야 합니다.

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

재부팅 없이 적용 가능한 패치를 적용하거나 패치된 커널을 즉시 배포하십시오. KernelCare Enterprise 사용자는 재부팅 없이 지원되는 실행 중인 커널에서 해당 취약점 공격 경로를 차단할 수 있습니다. 그렇지 않은 경우, 공급업체에서 패치한 커널 패키지를 설치하고 영향을 받은 시스템을 재부팅하십시오.
패치 적용을 미뤄야 할 경우, 워크로드에 미치는 영향을 확인한 후 initcall_blacklist=algif_aead_init 커널 명령줄 완화 조치를 적용하십시오. 일부 초기 권고 사항에서 제시된 modprobe 기반의 임시 해결책은 RHEL 계열 커널에서는 작동하지 않습니다.
부분적으로 신뢰할 수 있는 코드가 실행될 수 있는 환경을 검토하십시오. 여기에는 CI 시스템, 공유 호스트, 쿠버네티스 노드, 개발자 인프라 및 SaaS 워커 플릿이 포함됩니다.
4월 29일 공개된 내용을 시작으로, 의심스러운 AF_ALG 활동을 추적하십시오.
패치된 시스템을 재부팅하여 취약한 런타임 상태와 캐시된 페이지를 제거하십시오.

왜 이런 종류의 버그가 계속 재발하는가

‘복사 실패(Copy Fail)’, ‘더티 파이프(Dirty Pipe)’, ‘더티 프래그(Dirty Frag)’는 구현 세부 사항에서는 차이가 있지만, 메모리 소유권에 대해 잘못된 가정을 하는 성능 중심의 빠른 경로라는 근본적인 패턴은 공통적으로 가지고 있습니다.

각 경우마다, 쓰기 작업이 커널이 수정해도 안전하다고 잘못 판단한 페이지에 도달했습니다.

페이지 캐시는 의도적으로 공유되기 때문에 반복적으로 취약점이 됩니다. 파일을 읽는 모든 프로세스는 동일한 기본 물리 페이지를 참조합니다. 해당 공유 페이지에 의도치 않게 단 한 번의 쓰기 작업이 이루어져도, 그 페이지에서 실행 코드를 불러오는 권한이 있는 바이너리 프로그램들이 이를 감지할 수 있습니다.

해결책은 단순히 “최적화를 중단하라”는 것이 아닙니다. 현대 시스템은 이러한 성능 경로에 의존하고 있습니다. 또한 최근 악용 사례에 연루된 모듈을 무조건 영구적으로 비활성화하는 것 역시 장기적인 해결책이 될 수 없습니다.

더 근본적인 해결책은 커널 메모리 처리 경로 전반에 걸쳐 더 강력한 페이지 소유권 보장을 적용하는 것인데, 이는 업스트림 유지보수자들이 이미 착수한 작업이지만, 커널에서 성능에 가장 민감한 일부 하위 시스템에 영향을 미치기 때문에 진행 속도가 더딘 실정입니다.

‘Copy Fail’은 이 계열의 마지막 취약점이 아닐 가능성이 높습니다.

그리고 리눅스는 문제의 표면적인 부분만을 보여줄 뿐일지도 모릅니다.

‘Copy Fail’은 철저한 검토를 거친 오픈소스 코드 내에서 거의 10년 동안 발견되지 않은 채 남아 있다가, AI 지원 스캐너가 운영자의 단 한 번의 명령만으로 약 1시간 만에 이를 찾아냈습니다. 리눅스는 누구나 공개적으로 스캔할 수 있기 때문에 스캔 대상이 되는 스택의 일부입니다. 상업용 펌웨어, 벤더 커널, 레거시 프로토콜, 칩 마이크로코드로 구성된 훨씬 더 방대한 영역은 역사적으로 '숨겨진 코드는 숨겨진 버그를 의미한다'는 가정에 의존해 왔습니다. 이고르 셀레츠키(Igor Seletskiy)가 『 오픈 소스는 빙산의 일각이다( Open Source is the Tip of the Iceberg)』에서 주장하듯, 그 가정은 이제 유효성을 잃어가고 있습니다. 'Copy Fail'은 초기 데이터 포인트 중 하나일 뿐이며, 마지막 사례 중 하나가 되지는 않을 것입니다.