엣지 방어: Cloudflare가 Copy Fail Linux 취약점을 완화한 방법

2026년 4월 29일, "Copy Fail"(CVE-2026-31431)로 알려진 심각한 로컬 권한 상승 취약점이 공개되었습니다. 대규모 Linux 인프라를 운영하는 모든 운영자에게 이러한 취약점은 매우 중대한 경주와 같습니다. 공개 직후부터 실제 공격이 시작되기까지의 시간은 종종 몇 시간 단위로 측정됩니다.

이 사건에 대한 Cloudflare의 대응은 심층 방어(defense-in-depth)의 모범 사례를 제공하며, 자동화된 패치, 행동 기반 탐지, 그리고 정밀한 런타임 완화 조치가 결합되어 전통적인 업데이트 주기가 너무 느릴 때 어떻게 위협을 무력화할 수 있는지 보여줍니다.

"Copy Fail" 취약점 이해하기

완화 조치를 이해하려면 먼저 익스플로잇의 메커니즘을 이해해야 합니다. 이 취약점은 Linux 커널의 AF_ALG 소켓 패밀리에, 특히 인증된 연관 데이터(AEAD) 암호화에 사용되는 algif_aead 모듈 내에 존재합니다.

익스플로잇의 메커니즘

문제의 핵심은 경계 외 쓰기(out-of-bounds write)입니다. 2017년, 목적지와 참조 페이지를 함께 연결하는 in-place 암호화 작업을 허용하기 위한 최적화가 도입되었습니다. 그러나 이 설계에는 충분한 경계 검증이 부족했습니다.

사용자가 recvmsg()를 실행하면, 커널의 authencesn 래퍼는 합법적인 출력 영역을 넘어 4바이트를 작성합니다. 공격자는 splice() 시스템 호출을 활용하여 대상 파일(예: setuid-root 바이너리 /usr/bin/su)의 페이지 캐시를 암호화 scatterlist에 연결할 수 있습니다.

이를 통해 공격자는 다음과 같은 작업을 수행할 수 있습니다:

대상 파일의 페이지 캐시를 채움으로써 어떠한 읽기 가능한 파일이라도 타겟팅할 수 있습니다.
assoclen 및 splice 파라미터를 통해 쓰기 오프셋을 제어할 수 있습니다.
sendmsg()의 AAD 바이트를 통해 작성되는 값을 제어할 수 있습니다.

setuid 바이너리의 페이지 캐시에 셸코드를 주입함으로써, 공격자는 해당 바이너리가 다음에 호출될 때 루트 권한으로 해당 코드를 실행할 수 있으며, 이는 사실상 모든 로컬 보안 제어를 우회하는 결과를 낳습니다.

Cloudflare의 대응 전략

Cloudflare의 대응은 서비스 가용성을 유지하면서 "취약점 노출 기간"을 최소화하기 위해 설계된 병렬 워크스트림으로 특징지어집니다.

행동 기반 탐지 vs. 시그니처

Cloudflare 방어의 가장 중요한 측면 중 하나는 기존의 행동 기반 탐지 시스템입니다. 시그니처(특정 익스플로잇의 형태를 아는 것)에 의존하는 전통적인 백신이나 IDS와 달리, Cloudflare의 시스템은 anomalous process execution patterns(비정상적인 프로세스 실행 패턴)을 모니터링합니다.

내부 검증 과정에서 이 시스템은 Copy Fail 익스플로잇을 몇 분 만에 탐지했습니다. 단 하나의 규칙 변경이나 사람의 개입 없이도 스크립트 인터프리터부터 암호화 서브시스템을 거쳐 권한 상승 바이너리까지의 전체 실행 체인을 연결했습니다. 이는 보안 팀에게 실제 공격 시도가 발생할 경우 실시간으로 즉시 탐지될 것이라는 즉각적인 확신을 제공했습니다.

위협 헌팅 및 포렌식

"침해를 가정하라(assume compromise)"는 원칙에 따라, Cloudflare는 공개 직전 48시간 동안 전체 플릿(fleet-wide) 로그를 대상으로 소급적 헌팅을을 수행했습니다. 그들은 익스플로잇이 남긴 독특한 커널 로그 흔적을 검색하고, 알려진 정상적인 패키지 매니페스트와 시스템 바이너리의 무결성을 대조하여 어떠한 지속성(persistence)이 확보되었는지 확인했습니다.

bpf-lsm을 통한 정밀 완화

장기적인 해결책은 커널 패치와 재부팅이지만, Cloudflare의 인프라 규모(330개 이상의 도시)로 인해 전역적 재부팅 주기는 매우 많은 시간이 소요됩니다. 팀은 두 가지 완화 경로를를 탐색했습니다:

무차별한 방식: algif_aead 모듈을 완전히 제거하는 것입니다. 효과적이지만, 커널 암호화 API에 의존하는 내부 서비스가 중단될 수 있는 위험이 있습니다.
정밀한 방식: bpf-lsm을 사용하는 것입니다.

bpf-lsm의 작동 방식

Cloudflare는 socket_bind LSM 훅에 eBPF 프로그램을 배포포함했습니다. 무차별한 차단단이 아니라, 프로그램은 다음과 같은 로직 게이트를 구현했습니다:

소켓 패밀리가 AF_ALG가 아니면, 호출을 허용합니다.
소켓 패밀리가 AF_ALG라면, 호출하는 바이너리의 경로를 알려진 정상적인 서비스의 엄격한 허용 목록(allow-list)에서 확인합니다.
허용 목록에 없는 바이너리라면, bind 요청을 거부합니다.

배포 프로세스

예기치 않은 서비스 중단을 방지하기 위해 Cloudflare는 2단계 배포를 진행했습니다:

가시성 단계(Visibility Phase): prometheus-ebpf-exporter를 사용하여 플릿 전체의 AF_ALG 사용량을 추적했습니다. 이를 통해 단 하나의 내부 서비스만이 해당 API를 합법적으로 사용하고 있음을 확인했습니다.
강제 적용 단계(Enforcement Phase): 허용 목록이 검증된 후, bpf-lsm 프로그램이 다른 모든 접근을 차단하도록 배포되었습니다.

교훈 및 향후 강화 방안

성공적인 완화 조치에도 불구하고, 이번 사건은 몇 가지 개선이 필요한 영역을 강조했습니다. 주요 교훈 중 하나는 "LTS lag"의 위험성입니다. Cloudflare는 메인라인 커널의 수정 사항이 특정 LTS 커널 라인에 아직 백포트(backport)되었지 않았기 때문에 취약점에 노출되었습니다.

유사한 문제를 방지하기 위해 Cloudflare는 다음과 같이 약속했습니다:

커널 공격 표면 축소: 런타임 차단에 의존하기보다, 빌드 단계에서 사용하지 않는 모듈을 사전에 제거하기 위해 커널 설정을 감사합니다.
API 가시성 개선: 향후 완화 조치를 가속화하기 위해 어떤 프로덕션 서비스가 특정 커널 API에 의존하는지 더 나은 매핑을 개발합니다.
bpf-lsm 도구 개선: eBPF 기반 완화 도구의 배포 속도와 로깅 기능을 강화합니다.

결론

Copy Fail에 대한 대응은 현대적인 인프라에서 패치가 유할한 유일한 방어선이 아닙니다. 강력한 커널 업데이트 파이프라인과 런타임 완화 조치를 위한 eBPF의 민첩성, 그리고 탐지 방식의에 대한 행동 기반 접근법을 결합함으로써, Cloudflare는 서비스를 중단하거나 고객 데이터를 위험에 빠뜨리지 않고 플릿을 보호할 수 있었습니다. 커뮤니티 구성원이 토론에서 언급했듯이, 이는 안정성을 위한 LTS 커널의 가치를 재확인시켜 주지만, 동시에 조직이 LTS 라인이 메인라인 보안 패치와 차이가 발생할 때를 대비한 계획을 있어야 한다는 점을 강조합니다.