---
title: "리눅스 로컬 권한 상승 취약점 '카피 페일', 732바이트 파이썬으로 루트 획득 가능"
published: 2026-04-29T18:13:53.000Z
canonical: https://jeff.news/article/1964
---
# 리눅스 로컬 권한 상승 취약점 '카피 페일', 732바이트 파이썬으로 루트 획득 가능

카피 페일은 2017년 이후 배포된 주류 리눅스 커널에 영향을 주는 로컬 권한 상승 취약점으로, 레이스 조건이나 커널별 오프셋 없이 같은 732바이트 파이썬 스크립트로 루트 권한을 얻을 수 있다고 공개됐어. 원인은 커널 암호화 API의 에이에프 알고리즘과 스플라이스 경로가 얽히며 페이지 캐시에 4바이트 쓰기가 가능해지는 논리 버그로 설명됨.

- 카피 페일은 리눅스 로컬 권한 상승 취약점인데, 설명만 보면 꽤 매운 편임
  - 대부분의 리눅스 권한 상승 취약점은 레이스 타이밍이나 커널 버전별 오프셋 같은 조건이 붙는 경우가 많음
  - 그런데 이 취약점은 직선적인 논리 버그라 그런 전제가 필요 없다고 함
  - 공개 글은 같은 732바이트 파이썬 스크립트가 2017년 이후 배포된 주류 리눅스 배포판에서 루트 셸을 얻는다고 주장함

> [!WARNING]
> 로컬 취약점이라고 가볍게 보면 안 됨. 공유 개발 서버, 빌드 서버, 셀프 호스티드 시아이 러너처럼 남의 코드가 일반 사용자 권한으로 실행되는 환경에서는 바로 루트 권한 상승 시나리오가 됨.

- 취약점의 흐름은 커널 암호화 API, `AF_ALG`, `splice()`가 얽힌 경로에서 페이지 캐시에 4바이트 쓰기가 가능해지는 구조로 설명됨
  - 문제의 출발점은 `authencesn`과 `algif_aead` 쪽 논리 버그로 소개됨
  - 네트워크 접근, 커널 디버깅 기능, 미리 준비된 커널 프리미티브가 필요 없다고 함
  - 기본 배포판 설정에서 커널 암호화 API가 켜져 있는 경우가 많아서 영향 범위가 넓다고 봄

```mermaid
sequenceDiagram
    participant 일반_사용자
    participant 에이에프_알고리즘
    participant 스플라이스
    participant 페이지_캐시
    participant 셋유아이디_바이너리
    일반_사용자->>에이에프_알고리즘: 암호화 소켓 경로 호출
    에이에프_알고리즘->>스플라이스: 데이터 이동 경로 연결
    스플라이스->>페이지_캐시: 쓰기 가능한 목적지로 오인
    페이지_캐시->>셋유아이디_바이너리: 4바이트 변경
    일반_사용자->>셋유아이디_바이너리: 실행 후 루트 셸 획득
```

- 공개된 개념 증명 코드는 방어자가 자기 시스템과 벤더 패치를 확인할 수 있게 하기 위한 용도라고 밝힘
  - 파이썬 3.10 이상 표준 라이브러리만 사용한다고 되어 있음
  - 기본 타깃은 `/usr/bin/su`이고, 다른 셋유아이디 바이너리를 인자로 넘길 수 있다고 함
  - 원문은 여러 배포판에서 같은 익스플로잇이 수정 없이 동작했다고 설명함

- 우선 패치해야 하는 곳은 '여러 사용자가 같은 커널을 공유하는 곳'임
  - 공유 개발 박스, 셸 제공 서비스, 점프 호스트, 빌드 서버가 직접 언급됨
  - 깃허브 액션 셀프 호스티드 러너, 깃랩 러너, 젠킨스 에이전트처럼 신뢰하지 않는 풀 리퀘스트 코드를 실행하는 시스템도 위험권임
  - 노트북 호스트, 에이전트 샌드박스, 서버리스 함수, 테넌트 제공 컨테이너나 스크립트 실행 환경도 포함됨

- 컨테이너 환경에서도 포인트는 '커널 공유'임
  - 페이지 캐시는 호스트 전체에서 공유됨
  - 적절한 프리미티브를 가진 파드가 노드를 장악하면 테넌트 경계를 넘을 수 있다고 설명함
  - 그래서 단순히 컨테이너 안이라 괜찮다는 식의 판단은 위험함

> [!IMPORTANT]
> 권장 조치는 배포판 커널을 메인라인 커밋 `a664bf3d603d`가 포함된 버전으로 업데이트하는 것임. 이 커밋은 2017년의 `algif_aead` 인플레이스 최적화를 되돌려 페이지 캐시 페이지가 쓰기 가능한 목적지 목록에 들어가지 않게 함.

- 바로 패치할 수 없다면 임시 완화책은 `algif_aead` 모듈 비활성화임
  - 원문은 `/etc/modprobe.d/disable-algif.conf`에 설치 차단 규칙을 넣고, 이미 로드된 모듈은 제거하는 식의 방식을 제시함
  - 대부분의 시스템에서는 체감 영향이 거의 없을 거라고 설명함
  - 다만 오픈에스에스엘의 `afalg` 엔진을 명시적으로 켰거나, 임베디드 암호화 오프로딩 경로를 쓰거나, 애플리케이션이 직접 `aead`, `skcipher`, `hash` 소켓을 바인딩한다면 확인이 필요함

- 신뢰하지 않는 워크로드를 돌리는 환경이라면 패치 여부와 별개로 `AF_ALG` 소켓 생성을 시컴프로 막으라고 권고함
  - 시아이, 샌드박스, 컨테이너 런타임 쪽에서는 이게 실용적인 방어선이 될 수 있음
  - 원문은 `lsof`나 `ss -xa`로 실제 사용 여부를 확인해보라고 덧붙임

- 흥미로운 뒷이야기도 있음. 이 취약점은 Xint Code가 리눅스 `crypto/` 서브시스템을 약 1시간 스캔해서 찾아낸 것으로 소개됨
  - 같은 스캔에서 아직 조율 공개 중인 다른 고위험 버그도 나왔다고 함
  - 글 하단은 Xint Code의 보안 감사 역량 소개로 이어지며, Redis, PostgreSQL, MariaDB 같은 데이터베이스 부문 성과와 DARPA AI 사이버 챌린지 결선 진출 이력을 언급함

---

## 기술 맥락

- 이 취약점에서 제일 중요한 선택지는 커널 패치예요. 원문이 지목한 수정은 2017년에 들어간 `algif_aead` 인플레이스 최적화를 되돌리는 쪽인데, 성능 최적화가 페이지 캐시 쓰기 경로와 만나면서 권한 상승으로 이어졌다는 판단이 깔려 있어요.

- `AF_ALG`는 일반 앱이 커널 암호화 API를 쓰게 해주는 문이라서 기본 배포판에 켜져 있는 경우가 많아요. 그래서 공격자는 특수한 커널 디버그 기능이나 네트워크 접근 없이도, 로컬 사용자 권한만 있으면 이 문을 두드릴 수 있다는 게 위험해요.

- 컨테이너에서 더 신경 써야 하는 이유는 컨테이너가 커널을 공유하기 때문이에요. 앱 프로세스는 격리돼 보여도 페이지 캐시와 커널 취약점은 호스트 단위로 영향을 주거든요. 그래서 파드 하나의 로컬 권한 상승이 노드 전체 문제로 커질 수 있어요.

- 임시 완화로 `algif_aead`를 막는 건 공격 경로를 좁히려는 선택이에요. 대부분의 서비스는 커널 암호화 API를 직접 쓰지 않고 사용자 공간 암호화 라이브러리를 쓰기 때문에 영향이 작을 수 있지만, 암호화 오프로딩이나 `afalg` 엔진을 켠 시스템은 먼저 사용 여부를 확인해야 해요.

- 시컴프로 `AF_ALG` 소켓 생성을 막으라는 권고는 운영 관점에서 꽤 현실적이에요. 신뢰하지 않는 코드가 계속 들어오는 시아이 러너나 샌드박스에서는 커널 패치만 기다리기보다, 애초에 위험한 커널 인터페이스 접근을 줄이는 게 방어층을 하나 더 만드는 방법이에요.

## 핵심 포인트

- 네트워크 접근 없이 로컬 일반 사용자 계정만 있으면 공격 조건이 성립함
- 2017년부터 패치 전까지의 주류 리눅스 배포판이 영향권으로 제시됨
- 공유 개발 서버, 셀 서비스, 점프 호스트, 빌드 서버, 셀프 호스티드 시아이 러너, 컨테이너 노드가 우선 패치 대상임
- 패치는 메인라인 커밋을 포함한 배포판 커널 업데이트이며, 임시 완화로 에이에프 알고리즘 모듈 비활성화와 시컴프 차단이 권장됨

## 인사이트

이건 '로컬 권한 상승이라 덜 급함'으로 넘기기 어려운 부류야. 요즘 인프라는 시아이, 샌드박스, 노트북, 컨테이너처럼 남의 코드를 로컬 사용자 권한으로 실행하는 곳이 많아서, 로컬 버그가 곧 노드 탈취로 이어질 수 있음.