패키지 해시도 멀쩡하고, 디스크의 바이너리도 바뀐 흔적이 없는데, 그래도 일반 계정이 루트가 될 수 있다면 무엇을 먼저 의심해야 할까요. CopyFail은 바로 그 불편한 질문을 던집니다. 많은 리눅스 운영 습관이 "디스크 변조"에는 강하지만, 페이지 캐시처럼 메모리에 올라간 파일 이미지가 손상되는 상황에는 생각보다 취약하다는 점을 드러냈습니다.
지금 이 이슈가 중요한 이유는 두 가지입니다. 첫째, CVE-2026-31431은 2017년 이후의 광범위한 리눅스 커널에 영향을 주는 로컬 권한 상승 버그로 공개 PoC가 나와 있고, 미 정부는 이미 실제 악용 징후를 이유로 연방기관 패치 기한까지 제시했습니다.12 둘째, 이 취약점은 단순히 "로컬이면 이미 끝"이라고 넘길 문제가 아니라, CI 러너·공유 개발 서버·쿠버네티스 노드처럼 원래부터 비신뢰 코드가 돌아가는 환경에서 우선순위를 완전히 바꿔놓습니다.34
"디스크는 깨끗하다"는 안심이 이번엔 통하지 않는다
CopyFail의 핵심은 파일 자체를 디스크에서 바꾸는 게 아니라, 커널의 페이지 캐시에 올라간 파일 내용을 건드린다는 데 있습니다. 공개된 설명에 따르면 비권한 사용자가 AF_ALG와 splice()를 조합해 읽을 수 있는 파일의 페이지 캐시에 제어된 4바이트 쓰기를 만들 수 있고, 이를 setuid 바이너리에 적용하면 실행 시 루트 권한을 얻을 수 있습니다.35
실무적으로 더 중요한 건 여기서부터입니다. 온디스크 파일은 그대로이기 때문에 패키지 검증, 파일 해시 비교, 전통적인 파일 무결성 모니터링만으로는 "침해가 없었다"는 결론을 내리기 어렵습니다.3 재부팅이나 메모리 압박 후 캐시가 사라지면 흔적도 옅어집니다. 즉, 이번 취약점은 "파일이 바뀌었는가"보다 "실행 시점의 메모리상 파일 이미지가 오염됐는가"를 봐야 하는 사건입니다.
이 차이는 사고 대응에도 바로 영향을 줍니다. 디스크 포렌식만 믿지 말고, 당시의 프로세스 실행 기록, 비정상적인 AF_ALG 소켓 생성, 비권한 사용자의 splice() 사용, setuid 바이너리 실행 전후 계정 전환 흔적 같은 런타임 증거를 더 중시해야 합니다. 패치 후 재부팅은 필요하지만, 그것만으로 "악용 흔적이 없었다"고 단정하는 건 위험합니다.
"로컬 취약점"이니 점검창까지 기다려도 된다는 오해
이 취약점의 CVSS는 7.8이지만, 운영 환경에 따라 체감 위험도는 훨씬 다릅니다.3 같은 커널 버그라도 어디서 돌아가느냐가 우선순위를 갈라놓습니다.
오늘 바로 올려야 하는 쪽은 명확합니다. 여러 사용자가 같은 커널을 공유하는 점프 호스트, 셀프호스티드 CI 러너, 공유 개발 박스, 쿠버네티스 노드, 사용자 코드를 실행하는 SaaS나 노트북 환경입니다.5 이들 환경에서는 "로컬 접근"이 특별한 전제조건이 아니라 정상 운영 조건입니다. PR 하나, 컨테이너 하나, 일반 셸 계정 하나가 곧 루트 상승의 출발점이 됩니다.
반대로 단일 사용자 워크스테이션은 상대적으로 우선순위가 낮을 수 있습니다. 다만 이것도 "안전하다"는 뜻은 아닙니다. 웹 RCE, 도난 계정, 악성 스크립트 실행 같은 초기 침해가 이미 들어온 뒤라면 CopyFail은 매우 짧은 경로의 권한 상승 수단이 됩니다.6
여기서 흔한 반론이 있습니다. "로컬 계정을 이미 땄으면 사실상 끝 아닌가?" 이번에는 그 말이 특히 게으른 가정입니다. 현대 인프라는 로컬 사용자와 비신뢰 코드 실행을 일상적으로 허용합니다. 컨테이너, 빌드 잡, 분석 노트북, 내부 협업 서버가 모두 그렇습니다. CopyFail은 그 일상적 권한을 곧바로 호스트 루트로 바꾸는 버그입니다.
이번 주에 바꿔야 할 것: 커널 업데이트 외의 현실적 조치
가장 먼저는 커널 패치입니다. 메인라인 수정은 2017년 도입된 algif_aead의 인플레이스 최적화를 되돌리는 방식이며, 각 배포판 백포트 여부는 벤더 공지를 직접 확인해야 합니다.35 그리고 설치만 해놓고 재부팅하지 않으면 의미가 없습니다.
패치를 당장 못 한다면 임시 대응의 무게중심은 algif_aead 비활성화입니다. 모듈형이면 블랙리스트와 언로드가 가능하고, 일부 커널처럼 내장형이면 부트 파라미터 기반 우회가 필요할 수 있습니다.3 기능 영향은 대체로 제한적이지만, 정말 AF_ALG를 직접 쓰는 워크로드가 있는지는 확인해야 합니다.5
컨테이너와 CI 환경에서는 한 단계 더 가야 합니다. 패치 여부와 별개로 seccomp로 AF_ALG 소켓 생성 자체를 막는 편이 낫습니다.5 기본 프로파일이나 "restricted" 정책이 이것까지 자동으로 막아준다고 기대하면 안 됩니다는 지적도 나와 있습니다.4
그리고 setuid 바이너리 목록을 다시 보세요. CopyFail 하나만의 문제가 아니라, 불필요한 setuid는 늘 권한 상승의 착지 지점이 됩니다. 이번 사건은 "커널 패치"와 "권한 상승 표면 축소"를 따로 보지 말라는 경고에 가깝습니다.
마지막으로, 이번 사건을 계기로 리눅스 방어 습관도 업데이트해야 합니다. 파일이 깨끗하다는 사실은 이제 충분한 안심 근거가 아닙니다. 비신뢰 로컬 코드 실행이 있는가, AF_ALG 같은 커널 기능이 실제로 열려 있는가, 컨테이너를 보안 경계처럼 과신하고 있지는 않은가. CopyFail 이후의 더 좋은 질문은 거기서 시작합니다.
참고
1US government warns of severe CopyFail bug affecting major versions of Linux
4CERT-EU - High Vulnerability in the Linux Kernel ("Copy Fail")
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.