인자를 세지 않자, 그 다음 자리엔 이미 환경변수가 앉아 있었다

01개요

polkit(옛 PolicyKit)은 리눅스에서 권한 없는 프로세스가 권한 있는 작업을 정책에 따라 요청할 수 있게 해주는 컴포넌트입니다. 그중 pkexec는 sudo와 비슷하게, 인가된 사용자가 다른 사용자(기본값 root) 권한으로 명령을 실행하게 해주는 SUID-root 바이너리입니다 — 실행 파일 소유자(root) 권한으로 항상 동작한다는 뜻입니다.

CVE-2021-4034는 이 pkexec가 명령줄 인자 개수(argc)가 0인 극단적인 호출을 전혀 예상하지 못한 채 짜여 있었다는 사실에서 시작합니다. argc=0으로 실행되면 pkexec는 '다음 인자'라고 믿는 자리를 읽는데, 그 자리는 실제로는 인자 배열 밖 — 프로세스의 환경변수 배열의 첫 항목입니다. 이 하나의 검증 누락이, 아래에서 다루는 것처럼 읽기와 쓰기 양쪽 모두에서 경계를 넘게 만듭니다.

pkexec는 2009년 5월 최초 커밋(c8c3d83, "Add a pkexec(1) command")부터 이 결함을 그대로 지니고 있었습니다 확인. 2022년 1월 25일 조율된 공개(coordinated disclosure)와 동시에 패치가 나왔지만, 결함 자체가 워낙 오래되고 트리거가 간단해 공개 직후 실제 악용이 빠르게 확인됐고, CISA는 2022년 6월 27일 이 CVE를 알려진 악용 취약점(KEV) 목록에 올렸습니다(대응 기한 2022년 7월 18일) 확인.

CVSS: 7.8 (CVSS 3.1, High, AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) · CWE-787(Out-of-bounds Write, 신고 벤더 Red Hat 분류) + CWE-125(Out-of-bounds Read, NVD 자체 추가 분류)

같은 이름으로 묶여 보도되는 별개 취약점은 확인되지 않았습니다 — CVE-2021-4034 하나가 이 사건 전체를 가리킵니다. CISA KEV 등록명은 "Red Hat Polkit Out-of-Bounds Read and Write Vulnerability"로, 읽기·쓰기 두 결함이 함께 있다는 점을 이름에 그대로 담고 있습니다. 확인

02영향받는 버전

03배경 — SUID 프로그램과, 커널이 argv·envp를 배치하는 방식

리눅스에서 실행 파일에 SUID 비트가 설정돼 있으면, 그 프로그램은 누가 실행하든 파일 소유자(여기선 root)의 권한으로 동작합니다. pkexec가 SUID-root인 이유는 명확합니다 — 권한 없는 사용자의 요청을 받아 권한 있는 작업을 대신 해줘야 하니, 그 자체가 이미 높은 권한으로 시작해야 합니다. 이런 프로그램은 태생적으로 '내가 받은 입력을 얼마나 의심해야 하는가'가 일반 프로그램보다 훨씬 중요합니다.

새 프로세스가 시작될 때, 리눅스 커널은 execve()에 넘겨진 인자 문자열들(argv)과 환경변수 문자열들(envp)의 포인터 배열을 새 프로세스의 스택 끝부분에 서로 이어 붙여 배치합니다. argv[0]부터 argv[argc-1]까지, 그 뒤에 배열의 끝을 알리는 NULL 하나, 그리고 바로 이어서 envp[0]부터 시작하는 환경변수 포인터들이 옵니다. 이 배치 자체는 정상적인 리눅스 프로세스 동작이며 문제가 아닙니다 — 문제는 이 배치를 전제로, argv 배열의 경계를 넘어서 읽거나 쓰는 코드가 있을 때 생깁니다.

일반적으로 argc는 최소 1입니다(argv[0]에 프로그램 자신의 이름이 들어가는 관례 때문입니다). 하지만 execve()는 시스템 호출 차원에서 이 관례를 강제하지 않습니다 — argv 배열을 아예 빈 상태({NULL})로 넘기며 execve()를 직접 호출하면 argc=0인 프로세스가 실제로 시작됩니다. pkexec는 자신이 항상 argc≥1로 불릴 것이라 가정했고, 이 가정이 다음 절의 단서입니다.

04취약점 발생 원인

이 취약점은 하나의 검증 누락(§W1)에서 출발해, 그 결과가 '경로 문자열로 오인'(§W2)되고, 다시 '경계 밖에 되쓰임'(§W3)으로 이어지는 3단 연쇄입니다. 아래 코드는 모두 polkit 공식 저장소의 실제 소스이며, 줄번호는 패치 직전 커밋(4ff1abe4, 패치 커밋 a2bf5c9c의 부모) 기준입니다.

1"인자 처리 루프는 argc=0을 그냥 건너뛴다"

pkexec의 main()은 --user·--help 같은 옵션을 처리하기 위해 for (n = 1; n < (guint) argc; n++) 루프로 argv를 훑습니다. 여기서 argc는 guint(부호 없는 정수)로 캐스팅되는데, argc=0이면 이 비교는 1 < 0이 되어(부호 없는 산술이라 항상 거짓) 루프 몸체가 단 한 번도 돌지 않습니다.

polkit 오픈소스 실제 소스 — pkexec.c · main() (커밋 4ff1abe4a4c1f8c8378b9eaddb0346ac6448abd8, 패치 커밋 a2bf5c9c의 부모=패치 직전 상태).

루프가 안 도는 것 자체는 안전해 보입니다. 문제는 이 루프를 빠져나온 다음, 코드가 n을 '실제 명령 인자가 시작하는 위치'로 그대로 믿고 계속 쓴다는 점입니다 — n은 여전히 초기값 1을 가진 채로요. argc=0이라 argv에는 인덱스 0(그 값은 NULL)밖에 없는데, 이후 코드는 argv[1]이 존재하는 인자라고 가정하고 접근합니다.

왜 이렇게 됐나이 루프는 '정상적인 호출이라면 argc는 항상 1 이상'이라는 암묵적 전제 위에서 짜였습니다. execve() 시스템 호출 자체는 이 전제를 강제하지 않는다는 사실이, 애플리케이션 코드 레벨의 관례와 커널이 실제로 허용하는 범위 사이의 간극입니다. 분석

2"경계 밖 값을, 검증 없이 프로그램 경로로 취급한다"

610행 path = g_strdup (argv[n])은 W1에서 고정된 n=1로 argv[1]을 읽습니다. argc=0인 이 상황에서 argv[1]은 배열 밖입니다 — 배경 절에서 설명한 메모리 배치 때문에, 이 자리는 실제로는 이 프로세스의 첫 환경변수(envp[0])를 가리키는 포인터입니다. 즉 path에는 공격자가 완전히 통제하는 문자열이 담깁니다.

polkit 오픈소스 실제 소스 — pkexec.c · main() (같은 커밋). 610행이 경계 밖 읽기, 629·632행이 그 값을 프로그램 경로로 취급하는 지점입니다.

이어서 629행 if (path[0] != '/')가 이 값이 절대 경로가 아니면, 632행 g_find_program_in_path(path)로 PATH 환경변수가 가리키는 디렉터리들에서 이 이름의 실행 파일을 찾습니다. path가 사실은 사용자가 넘긴 명령 인자가 아니라 공격자가 직접 설정한 첫 환경변수 값이라는 걸 이 코드는 전혀 모릅니다.

왜 이렇게 됐나g_find_program_in_path() 자체는 안전한 함수입니다(환경변수를 신뢰하지 않고 파일시스템만 확인). 위험한 건 이 함수에 '사용자 인자'라는 이름으로 위장한, 사실은 공격자가 쓴 환경변수가 입력으로 들어간다는 점입니다. 분석

3"탐색 결과를 같은 경계 밖 자리에 도로 쓴다"

639행 argv[n] = path = s;는 632행에서 찾은 실행 파일의 전체 경로(s)를, W1에서 고정된 인덱스 n=1 자리에 그대로 씁니다. argv[1]이 이 상황에서 실제로는 envp[0]이므로, 이 쓰기는 이 프로세스의 첫 환경변수 자리를 덮어씁니다.

polkit 오픈소스 실제 소스 — pkexec.c · main() (같은 커밋). 639행이 PATH 탐색 결과를 envp[0] 자리에 되쓰는 지점입니다.

Qualys 원 어드바이저리는 이 지점을 정확히 이렇게 정리합니다 — PATH를 PATH=name처럼 설정하고 현재 디렉터리에 name이라는 디렉터리를 만들어 그 안에 특정 이름의 실행 파일을 두면, g_find_program_in_path()가 돌려주는 문자열(예: name/value)이 envp[0] 자리에 그대로 써진다는 것입니다. 즉 공격자는 이 out-of-bounds 쓰기의 결과 문자열 내용까지 원하는 대로 설계할 수 있습니다 확인 — Qualys 원문 직접 대조.

이 쓰기 자체가 곧바로 코드 실행은 아닙니다. 의미는 'pkexec가 이후 자신의 환경을 정리(sanitize)할 때 참조할 자리 하나가, 원래 있어야 할 값이 아니라 공격자가 심은 값으로 바뀌어 있다'는 것입니다 — ld.so가 SUID 프로세스 실행 전에 이미 제거했어야 할 민감한 환경변수를 이 경로를 통해 재도입할 여지가 여기서 열립니다.

왜 이렇게 됐나쓰기 지점 역시 읽기 지점(W2)과 마찬가지로 n이 유효한 argv 인덱스인지 재확인하지 않습니다. 하나의 검증 누락(W1)이 읽기(W2)와 쓰기(W3) 두 번의 경계 침범을 동시에 정당화해 버린 셈입니다. 분석

05공격 과정

5.1 공격 과정 요약

• ① 공격자가 execve()를 인자 배열이 빈 상태({NULL})로 직접 호출해, pkexec(SUID root)를 argc=0으로 실행시킵니다.
• ② main()의 인자 처리 루프가 argc=0을 알아채지 못하고 그냥 통과해, '다음 인자 자리'를 가리키는 인덱스가 1로 고정됩니다.
• ③ 그 인덱스로 argv를 읽는 코드가, 메모리상 바로 뒤에 이어지는 첫 환경변수(envp[0]) — 공격자가 미리 설정해 둔 값 — 를 읽습니다.
• ④ 이 값이 절대 경로가 아니면 pkexec는 이를 프로그램 이름으로 보고 PATH 디렉터리들에서 실행 파일을 찾습니다.
• ⑤ 찾은 결과를 같은 out-of-bounds 자리에 그대로 되씁니다 — 이 되쓰기가 실제로는 envp[0] 자리를 공격자가 설계한 값으로 덮어씁니다.
• ⑥ pkexec가 이후 자신의 환경을 정리하는 단계에서, 이 자리의 값이 원래 setuid 실행 전에 걸러졌어야 할 민감한 환경변수처럼 다시 취급될 여지가 생깁니다.
• ⑦ 조건이 맞으면 이렇게 재도입된 환경변수가 root 권한으로 임의 코드가 실행되는 데까지 이어질 수 있습니다 — 이 마지막 단계의 구체적 트리거 조건(어떤 변수를 어떻게 재도입하는지)은 무해화 원칙에 따라 이 글에서 다루지 않습니다.

5.2 상세 공격 과정

이 공격의 첫 조건은 셸에서 pkexec를 그냥 실행하는 것과 다릅니다 — 표준 C 라이브러리의 execve()를 직접 호출하면서 인자 배열 자체를 비워({NULL}) 넘겨야, argc=0인 pkexec 프로세스가 실제로 시작됩니다. 이 조건 하나가 §7의 W1~W3 전체 연쇄의 전제입니다.

공격자는 이 실행 전에 자신의 환경변수, 특히 envp[0]이 될 첫 번째 변수를 원하는 값으로 미리 구성해 둡니다. Qualys 원 어드바이저리는 PATH 환경변수를 특정 문자열로 설정하고 현재 작업 디렉터리에 그 이름의 디렉터리·실행 파일을 함께 준비하는 조합을 구체적으로 제시합니다 — 이 글은 그 조합의 정확한 값·트리거 절차는 다루지 않고, 원리(경계 밖 읽기·쓰기가 왜 위험한 프리미티브로 이어지는가)까지만 남깁니다.

④~⑤에서 되쓰인 값이 실제로 코드 실행까지 이어지려면, pkexec가 이후 자신의 환경을 clearenv()로 완전히 비우기 전에 이 재도입된 자리를 다시 참조하는 경로가 있어야 합니다. Qualys는 이 마지막 연결 고리로 GLib의 오류 메시지 출력 함수(문자 인코딩 변환을 위해 내부적으로 공유 라이브러리를 로드하는 경로)를 지목했습니다 — 이 부분 역시 구체적 트리거 조건은 무해화 원칙에 따라 이 글에서 재현하지 않습니다.

흥미로운 점은, Qualys 원문이 이 취약점이 로그에 흔적을 남기는 경로와 남기지 않는 경로가 둘 다 있다고 명시한다는 것입니다 확인 — 탐지 관점에서 중요한 단서라 §10에서 다시 다룹니다.

5.3 미흡점 ↔ 공격 흐름 매핑

06취약점 패치

07대응방안

가장 확실한 조치는 사용 중인 배포판이 배포한 polkit 보안 업데이트를 적용하는 것입니다(§5 표). polkit을 직접 빌드해 쓰는 경우에는 업스트림 커밋 a2bf5c9c 이후 소스, 또는 정식 릴리스 0.121 이상을 씁니다. '패키지 버전 번호가 0.121 이상인가'만으로 안전 여부를 판단하지 말 것 — 대부분의 배포판은 이보다 훨씬 낮은 자기 버전 번호에 이 패치만 백포트했습니다.

• 패치를 당장 적용할 수 없다면, 발견자 Qualys의 원 어드바이저리는 chmod 0755 /usr/bin/pkexec로 SUID 비트를 임시로 제거하는 것을 권고했습니다. 다만 Red Hat은 이 방법을 권장하지 않습니다 — 공식 문서(RHSB-2022-001)에서 'SUID 제거는 pkexec에 의존하는 정상적인 애플리케이션을 깨뜨릴 수 있어, 자사 고객 환경에는 적합한 완화책이 아니라고 판단했다'고 명시하고 있습니다. 어느 쪽을 택할지는 해당 시스템에서 pkexec가 실제로 필요한지(그래픽 데스크톱·PolicyKit 연동 애플리케이션 사용 여부)에 달려 있습니다. 확인 — 두 벤더 문서 직접 대조
• Red Hat은 그 대신 SystemTap 기반의 커널 모듈로 pkexec의 main() 진입 시 첫 인자가 빈 문자열인 호출을 차단하는 완화책을 제공했습니다(argc=0 호출을 직접 거부). 다만 이 방법은 Secure Boot가 켜진 시스템에서는 동작하지 않고, 커널 모듈에 서명할 수 있는 별도 빌드 환경이 필요합니다 — 임시방편의 조건이 결코 가볍지 않다는 뜻입니다.
• 더 아래 계층에서는, 이 CVE가 계기가 되어 리눅스 커널 자체가 argc=0인 execve() 호출을 더 이상 그대로 허용하지 않도록 바뀌었습니다(커밋 dcd46d897adb70d63e025f175a00a89797d31a43, "exec: Force single empty string when argv is empty", Kees Cook, 작성 2022-02-01·mainline 반영 2022-03-02로 Linux 5.18에 포함·5.17엔 미포함) — 커널이 빈 argv를 받으면 강제로 빈 문자열 하나를 채워 넣어 argc가 항상 최소 1이 되게 합니다. 이는 pkexec 하나만이 아니라 이 가정에 의존하는 모든 SUID 프로그램을 보호하는 시스템 차원의 방어층입니다. 다만 이 커널 하드닝은 폴백일 뿐, 개별 애플리케이션의 패치를 대체하지 않습니다. 확인 — GitHub 커밋 직접 대조
• 탐지 관점. 커널 감사 로그(auditd)에서 pkexec 실행 시 인자 개수가 0인 execve 호출(정상적인 셸 사용에서는 나타나지 않는 형태)을 관찰 규칙으로 둘 수 있습니다. 이 취약점의 트리거 방식에 따라 "The value for the SHELL variable was not found the /etc/shells file" 또는 "The value for environment variable [...] contains suscipious content"(원문 오탈자 그대로) 같은 오류 메시지가 시스템 로그(syslog/journal)에 남는 경로가 있습니다 — 다만 로그를 전혀 남기지 않는 트리거 경로도 존재하므로, 이 로그의 부재를 '공격이 없었다'는 근거로 쓸 수는 없습니다. 확인

08왜 이게 반복되는가

이 사건이 남기는 질문은 '왜 argc<1을 안 봤나'보다 한 단계 더 큽니다. C 언어에서 배열 인덱스의 유효성은 언어가 보장해주지 않고, 그 배열이 어떤 조건에서 만들어졌는지(여기선 execve() 시스템 호출)까지 알아야 판단할 수 있습니다. pkexec는 자신을 부르는 쪽이 항상 셸의 관례(argc≥1)를 지킬 거라 가정했지만, 커널은 그 관례를 강제하지 않았습니다 — 애플리케이션 레벨의 '으레 그럴 것'과 시스템 콜 레벨의 '실제로 허용되는 것' 사이의 간극이 13년 동안 조용히 남아 있었던 셈입니다.

패치완전성 관점에서 이 CVE를 세 질문으로 정리하면 이렇습니다. ① 근본원인을 막았나. 예 — argc < 1 가드는 §7 W1이 성립하는 정확한 조건을 원천 차단해, 증상(경계 밖 읽기·쓰기)이 아니라 그 전제(검증 누락)를 겨냥합니다. 같은 코드 패턴을 가진 pkcheck.c에도 같은 커밋에서 동일 가드가 함께 들어갔다는 점도, 이 패치가 '한 파일의 증상 봉합'이 아니라 '패턴 단위의 수정'이었음을 보여줍니다. 확인

② variant가 남았나. polkit 코드 자체에서 같은 취약점의 재발 사례는 확인하지 못했습니다. 흥미로운 건 그 대신 더 아래 계층(리눅스 커널)이 이 취약점 클래스 전체를 겨냥한 일반화된 방어를 추가했다는 점입니다 — 커밋 dcd46d8는 argc=0 호출을 커널 단에서 봉쇄해, 앞으로 pkexec와 똑같은 실수를 하는 다른 어떤 SUID 프로그램이 나오더라도 이 특정 경로로는 뚫리지 않게 만들었습니다. 개별 프로그램 패치(polkit)와 시스템 차원의 클래스 봉쇄(커널)가 같은 CVE에서 함께 나온, 방어 계층화의 좋은 사례입니다. 확인

③ silent patch인가. 전혀 아닙니다. 2021-11-18 Red Hat 보안팀 신고 → 2022-01-11 distros@openwall 조율 공개 → 2022-01-25 협정된 공개일에 Qualys 상세 어드바이저리·다수 배포판 동시 패치·패치 커밋이 함께 나왔고(NVD 공식 등재는 사흘 뒤인 2022-01-28), 이후 CISA KEV 등재(2022-06-27)까지 이어진, 책임 있는 공개 절차의 정석에 가까운 사례입니다. 확인

이 패턴은 저희가 다룬 다른 사건들과도 결이 닿아 있습니다 — Jenkins CLI 인자 파서 취약점(CVE-2024-23897)에서는 '로컬 신뢰를 전제로 한 라이브러리 기본값을 원격 컨텍스트로 그대로 가져온 것'이 문제였고, 여기서는 '항상 성립한다고 믿은 관례(argc≥1)를 시스템 콜이 강제하지 않는다는 것'이 문제였습니다. 둘 다 코드 자체는 각자 정상인데, 그 코드가 전제하는 경계 조건이 실제 실행 환경과 어긋난 지점에서 사고가 났습니다.

이 틈은 patch 한 줄과 커널 하드닝 한 커밋으로 닫혔지만, 'C로 짠 권한 있는 프로그램이 자신의 입력이 만들어진 방식(시스템 콜의 실제 허용 범위)까지 검증하고 있는가'라는 질문은 다른 SUID·SGID 바이너리에서 또 나올 수 있습니다 — 그래서 저희는 이 CVE 번호가 아니라 이 검증 습관을 기록으로 남깁니다.

09결론

CVE-2021-4034(PwnKit)는 polkit의 SUID-root 프로그램 pkexec가 argc=0인 호출을 검증하지 않아, argv 배열 경계를 벗어나 envp[0]을 읽고(out-of-bounds read) 다시 그 자리에 되쓰는(out-of-bounds write) 취약점입니다. CVSS 7.8(High), CWE-787/CWE-125로 등록됐고, 커밋 a2bf5c9c의 argc<1 가드로 패치됐습니다. 2009년부터 존재했던 이 결함은 2022년 공개 직후 실제 악용이 확인돼 CISA KEV에 올랐으며, 이후 리눅스 커널 자체가 argc=0 실행을 봉쇄하는 시스템 차원의 방어를 추가했습니다.