리눅스 로컬 권한 상승 취약점 '카피 페일', 732바이트 파이썬으로 루트 획득 가능

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

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

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

• 공개된 개념 증명 코드는 방어자가 자기 시스템과 벤더 패치를 확인할 수 있게 하기 위한 용도라고 밝힘

  • 파이썬 3.10 이상 표준 라이브러리만 사용한다고 되어 있음
  • 기본 타깃은 /usr/bin/su이고, 다른 셋유아이디 바이너리를 인자로 넘길 수 있다고 함
  • 원문은 여러 배포판에서 같은 익스플로잇이 수정 없이 동작했다고 설명함

• 우선 패치해야 하는 곳은 '여러 사용자가 같은 커널을 공유하는 곳'임

  • 공유 개발 박스, 셸 제공 서비스, 점프 호스트, 빌드 서버가 직접 언급됨
  • 깃허브 액션 셀프 호스티드 러너, 깃랩 러너, 젠킨스 에이전트처럼 신뢰하지 않는 풀 리퀘스트 코드를 실행하는 시스템도 위험권임
  • 노트북 호스트, 에이전트 샌드박스, 서버리스 함수, 테넌트 제공 컨테이너나 스크립트 실행 환경도 포함됨

• 컨테이너 환경에서도 포인트는 '커널 공유'임

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

• 바로 패치할 수 없다면 임시 완화책은 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 소켓 생성을 막으라는 권고는 운영 관점에서 꽤 현실적이에요. 신뢰하지 않는 코드가 계속 들어오는 시아이 러너나 샌드박스에서는 커널 패치만 기다리기보다, 애초에 위험한 커널 인터페이스 접근을 줄이는 게 방어층을 하나 더 만드는 방법이에요.