Cloudflare는 “Copy Fail” 리눅스 취약점에 어떻게 대응했나 (새 탭에서 열림)

2026년 4월 29일 공개된 Linux 커널 권한 상승 취약점 “Copy Fail”(CVE-2026-31431)에 대해 Cloudflare는 공개 직후 영향 범위와 탐지 가능성을 분석했다. Cloudflare의 자동화된 커널 업데이트와 기존 행위 기반 탐지 체계 덕분에 취약점 악용을 수분 내 식별할 수 있었으며, 실제 환경·고객 데이터·서비스에는 아무런 영향이 없었다. 핵심 대응은 최신 LTS 커널 패치 적용, 인프라별 노출도 분석, 공격 행위 검증이었다.

Cloudflare의 Linux 커널 운영 체계

• Cloudflare는 330개 도시에 걸친 대규모 Linux 인프라를 운영한다.
• 커뮤니티 Linux LTS 버전을 기반으로 자체 커널을 빌드하며, 여러 LTS 계열을 동시에 사용할 수 있다.
• 보안·안정성 업데이트가 반영되면 자동화된 작업이 약 1주일 주기로 내부 커널 빌드를 생성한다.
• 새 빌드는 스테이징 데이터센터에서 검증한 뒤, Edge Reboot Release(ERR) 파이프라인을 통해 약 4주 주기로 전 세계 엣지 인프라에 배포·재부팅한다.
• CVE가 공개될 때는 수정 사항이 이미 안정화된 LTS 버전에 수 주 전 반영되어 있는 경우가 많아, Cloudflare는 공개 시점에 이미 패치를 배포한 상태인 경우가 많다.
• 취약점 공개 당시 대부분의 시스템은 6.12 LTS를 사용했고, 일부는 6.18 LTS로 전환 중이었다.

AF_ALG와 커널 암호화 API

• Linux 커널 암호화 API는 kTLS와 IPsec 같은 기능을 제공한다.
• 비권한 사용자 프로세스도 AF_ALG 소켓을 통해 암호화·복호화 기능을 요청할 수 있다.
• algif_aead 모듈은 AEAD 암호 알고리즘을 처리한다.
• 일반적인 처리 흐름은 다음과 같다.
  • AF_ALG 소켓을 열고 AEAD 템플릿에 바인딩
  • 키를 설정하고 요청 소켓을 생성
  • sendmsg() 또는 splice()로 입력 전달
  • recvmsg()로 암호화 연산 실행
• 특히 splice()는 실제 데이터를 복사하기보다 페이지 캐시의 페이지 참조를 전달하므로, 이번 취약점 악용에 중요한 역할을 했다.

페이지 캐시와 인플레이스 암호화의 문제

• Linux 페이지 캐시는 파일 내용을 공유하는 시스템 캐시다.
• 페이지 캐시에 있는 파일 페이지가 수정되면, 해당 페이지가 캐시에서 제거되기 전까지 모든 사용자가 수정된 내용을 볼 수 있다.
• algif_aead는 2017년 성능 개선 과정에서 입력·출력 페이지를 연결해 인플레이스 연산을 수행하도록 최적화됐다.
• 그러나 이 구조에는 암호화 알고리즘이 의도된 출력 영역을 넘어 쓰지 못하도록 충분히 제한하는 검증이 없었다.
• 그 결과 공격자는 파일의 페이지 캐시를 암호화 scatterlist에 연결해, 파일의 특정 위치에 데이터를 덮어쓸 수 있었다.

“Copy Fail” 취약점의 작동 원리

• recvmsg() 처리 중 authencesn 래퍼가 정상적인 출력 영역을 넘어 4바이트를 기록한다.
• 공격자는 splice()를 이용해 대상 파일의 페이지 캐시 페이지를 scatterlist에 포함시킬 수 있다.
• 이때 다음 요소를 공격자가 조절할 수 있다.
  • 대상 파일: 읽을 수 있는 파일
  • 쓰기 위치: assoclen과 splice() 파라미터로 조정
  • 기록 값: sendmsg()의 특정 AAD 바이트로 제어
• 기본 공격 대상은 거의 모든 Linux 배포판에 존재하는 setuid-root 바이너리 /usr/bin/su다.
• 공격자는 해당 파일을 페이지 캐시에 올린 뒤 암호화 API 요청을 구성하고, recvmsg() 실행 중 발생하는 범위를 벗어난 쓰기로 바이너리의 코드 영역을 변조한다.
• recvmsg()가 -EBADMSG 오류를 반환하더라도 페이지 캐시에 대한 4바이트 쓰기는 이미 수행될 수 있다.
• 이후 변조된 /usr/bin/su가 실행되면 setuid 권한으로 인해 삽입된 코드가 root 권한으로 실행될 수 있다.
• Linux 업스트림 수정 커밋 a664bf3d603d는 문제가 된 2017년 인플레이스 최적화를 되돌려 이 공격 경로를 제거했다.

Cloudflare의 대응

• 취약점 공개 직후 보안팀과 커널 엔지니어링팀이 병렬로 대응을 시작했다.
• 먼저 어떤 커널 버전이 취약한지 확인하고, 각 인프라 구성에서 실제 노출 가능성을 분석했다.
• 기존의 자동 커널 빌드·검증·배포 절차를 통해 수정된 LTS 커널을 신속하게 적용할 수 있는 기반을 확보하고 있었다.
• 보안팀은 공개된 익스플로잇 기법을 검토해 Cloudflare 환경에서 공격이 가능한지 검증했다.
• 기존 행위 기반 탐지 시스템이 AF_ALG, splice(), 비정상적인 페이지 캐시 조작 등 익스플로잇의 행동 패턴을 수분 내 식별할 수 있음을 확인했다.
• 결과적으로 실제 침해, 고객 데이터 노출, 서비스 중단은 발생하지 않았다.

실용적인 교훈

• 커널 취약점 대응에서는 단순히 패치를 기다리기보다 자동화된 빌드·테스트·점진적 배포 체계를 평소에 갖추는 것이 중요하다.
• LTS 커널을 사용하더라도 여러 버전이 공존할 수 있으므로 자산별 커널 버전과 패치 상태를 지속적으로 관리해야 한다.
• 시그니처 기반 탐지만으로는 부족하며, 시스템 호출 조합과 비정상적인 파일·페이지 캐시 접근을 관찰하는 행위 기반 탐지가 효과적이다.
• 취약점 공개 직후에는 패치 적용뿐 아니라 익스플로잇 재현, 환경별 노출도 분석, 탐지 검증을 동시에 수행해야 한다.