PAM pam_env를 통한 allow_active 사칭 (CVE-2025-6018)

메타데이터

항목	내용
CVE ID	CVE-2025-6018
영향 버전	openSUSE Leap 15 / SUSE Linux Enterprise 15 계열의 기본 PAM 설정
CVSS v3.1	7.8 (High)
공개일	2025-06-17 (Qualys 공개)
발견자	Qualys Threat Research Unit
비고	이 자체는 로컬 권한 상승의 "1단계"이며, 이후 udisks/libblockdev 연계로 root까지
이어지는 체인의 시작점으로 보고됐다(체인 전체는 이 문서 범위 밖).

개요

리눅스 데스크톱에서 polkit은 "물리적으로 콘솔 앞에 앉아있는 사용자(active user)"에게 일부 작업(디스크 마운트 등)을 비밀번호 없이 허용하는 allow_active 규칙을 흔히 쓴다. CVE-2025-6018은 SSH로 원격 로그인한, 물리적으로 콘솔에 앉아있지 않은 사용자가 PAM 설정의 허점을 이용해 "나는 콘솔에 앉아있는 사용자다"라고 시스템을 속여, allow_active 권한을 가로챌 수 있게 되는 취약점이다.

사전 지식

PAM 스택과 "auth"·"session" 단계

PAM(Pluggable Authentication Modules)은 로그인 과정을 여러 모듈의 파이프라인으로 처리한다. 이 파이프라인은 여러 단계(스택)로 나뉘는데, 이 문서에서 중요한 두 단계는:

auth 스택: "이 사용자가 누구인지, 인증이 맞는지"를 확인하는 단계. 로그인 초반에 실행된다.
session 스택: 인증이 끝난 뒤 "이 세션을 어떻게 설정할지"를 처리하는 단계. pam_systemd 같은 모듈이 여기서 실행되며, 이 세션을 systemd-logind에 등록한다.

auth 스택이 session 스택보다 먼저 실행된다는 순서가 이 취약점의 전제다.

`pam_env` 와 `~/.pam_environment`

pam_env 모듈은 로그인 과정에서 특정 환경변수들을 PAM 환경에 심어준다. 이 모듈에는 user_readenv 라는 옵션이 있는데, 이게 켜져 있으면(다수 배포판에서 기본값) 사용자 자신의 홈 디렉터리에 있는 ~/.pam_environment 파일을 읽어서 그 안에 적힌 환경변수를 그대로 PAM 환경에 추가한다. 즉 사용자가 자기 홈 디렉터리에 파일 하나를 써넣는 것만으로, 로그인 과정에서 쓰이는 환경변수를 직접 주입할 수 있다는 뜻이다.

`XDG_SEAT` / `XDG_VTNR` 와 systemd-logind

systemd-logind 는 각 로그인 세션이 "어느 콘솔(seat)의 몇 번 가상 터미널(VT)에서 왔는지"를 판단할 때 XDG_SEAT, XDG_VTNR 같은 환경변수를 참고한다. 물리 콘솔에서 로그인한 세션이라면 이 값들이 정상적으로 채워져 있고, systemd-logind는 이를 근거로 그 세션을 "물리적으로 활성 상태인(active)" 세션으로 표시한다. polkit은 이 "active" 표시를 보고 allow_active 권한을 부여할지 결정한다.

취약점 분석

근본 원인: PAM 스택 순서와 신뢰 경계의 불일치

pam_env(auth 스택)가 ~/.pam_environment를 읽어 환경변수를 채우는 시점은, pam_systemd (session 스택)가 그 환경변수를 읽어서 세션 속성을 결정하는 시점보다 먼저 온다. 문제는 pam_env가 채운 값이 "사용자 홈 디렉터리 파일에서 온, 사용자가 직접 통제 가능한 값"인데, pam_systemd는 이 값을 마치 "커널/드라이버가 알려준 신뢰할 수 있는 하드웨어 정보"인 것처럼 그대로 신뢰한다는 점이다.

로그인 흐름 (패치 전)

  auth 스택
    pam_env 실행
      user_readenv=1 이므로 ~/.pam_environment 읽음
      ┌─────────────────────────────┐
      │ XDG_SEAT=seat0              │  ← 공격자가 이 파일에 직접 써넣은 값
      │ XDG_VTNR=1                  │
      └─────────────────────────────┘
      위 값들을 PAM 환경에 그대로 추가
        │
        ▼
  session 스택
    pam_systemd 실행
      PAM 환경에서 XDG_SEAT/XDG_VTNR 읽음
      "이 세션은 seat0의 VT1, 즉 물리 콘솔이다" 로 판단   ← 오판
        │
        ▼
  systemd-logind: 이 세션을 active 로 표시
        │
        ▼
  polkit: allow_active 규칙 적용 → 물리 콘솔 전용 권한 부여   ✗ (SSH 세션인데도)

공격이 성립하는 경로

공격자는 SSH로 원격 로그인이 가능한 일반 계정을 가지고 있다(물리 콘솔 접근 없음).
로그인하기 전(또는 별도 세션에서), 자신의 홈 디렉터리에 ~/.pam_environment 파일을 만들어 XDG_SEAT, XDG_VTNR 값을 적어 넣는다.
SSH로 다시 로그인한다 — pam_env 가 이 파일을 읽어 PAM 환경에 반영한다.
pam_systemd 가 이 값을 그대로 믿고 세션을 "물리 콘솔의 active 세션"으로 표시한다.
polkit이 allow_active 규칙에 따라 원래는 콘솔 사용자에게만 허용해야 할 작업(예: 특정 장치 마운트, 세션 관리 작업)을 이 SSH 세션에도 허용한다.
이후 이 상승된 신뢰를 발판 삼아 추가적인 로컬 권한 상승 체인(udisks/libblockdev 연계 등, 이 문서 범위 밖)으로 이어질 수 있다고 보고됐다.

수정 방법

Qualys 및 SUSE가 제시한 근본 대응은 pam_env의 user_readenv 옵션을 명시적으로 0으로 설정해, 사용자 홈 디렉터리 파일에서 환경변수를 읽어오는 경로 자체를 차단하는 것이다.

로그인 흐름 (완화 후: user_readenv=0)

  auth 스택
    pam_env 실행
      user_readenv=0 이므로 ~/.pam_environment 무시
        │
        ▼
  session 스택
    pam_systemd 실행
      XDG_SEAT/XDG_VTNR 이 사용자 통제 파일에서 주입되지 않음
      → 세션을 물리 콘솔로 오판할 근거가 사라짐
        │
        ▼
  systemd-logind: 실제 하드웨어/세션 정보 기준으로만 active 판단

Qualys 공개 자료에 따르면 user_readenv 기능 자체가 보안상 문제가 있어 향후 PAM에서 제거될 예정이라고 언급되어 있다 — 즉 이번 수정은 "이 옵션을 끄는" 설정 변경 수준이며, 코드 자체의 구조적 변경(커밋 diff)은 이번에 직접 확인하지 못했다.

참고 자료

미해결/불확실 지점

이 CVE는 원래 CVE-2025-6019(udisks/libblockdev XFS race condition)와 묶인 체인 공격의 1단계다. 이 문서는 pam_env/allow_active 사칭 부분만 다뤘고, 체인의 나머지 절반(udisks 쪽 root 획득 경로)은 별도 CVE라 이번 문서 범위에 포함하지 않았다.
수정 방법이 코드 패치가 아니라 설정 변경(user_readenv=0)이라, 실제 배포판별 기본 설정 파일 diff는 확인하지 못했다.

FilesExpand file tree

CVE-2025-6018-pam-env-allow-active-spoof.md

Latest commit

History