libuser가 /etc/passwd를 다시 쓰던 그 0.1초 (CVE-2015-3246)

이미지 출처: CISA KEV

2015년 여름에 공개된 리눅스 로컬 권한 상승 이슈 중 하나는 화려한 메모리 손상이 아니라 "파일을 어떻게 저장하느냐"에 관한 것이었음. 셸코드도, ROP 체인도 없이 그냥 사용자 계정 정보를 담은 텍스트 파일 하나가 쓰다 만 상태로 남는 것, 그게 전부였음. 그런데 그 파일이 하필 /etc/passwd였다는 게 문제였음.

핵심 요약

• libuser는 /etc/passwd를 수정할 때 파일을 통째로 잘라내고 다시 쓰는 방식을 썼고, 그 중간에 프로세스가 죽으면 파일이 반 토막 난 채로 남았음
• 잘려나간 지점이 운 나쁘게(공격자 입장에선 운 좋게) 잡히면 루트 계정의 암호 필드가 비어버릴 수 있어 로컬 권한 상승으로 이어짐
• 방어는 패치가 1순위, 그 다음이 userhelper 같은 setuid 진입점 축소와 /etc/passwd 무결성 감시임

1. libuser는 무슨 물건인가

libuser는 레드햇 계열에서 사용자·그룹 계정을 다루는 공용 라이브러리임. 우리가 직접 부를 일은 거의 없지만, userhelper(consolehelper를 통해 일반 사용자가 chfn/chsh 같은 작업을 하도록 중개해 주는 setuid 프로그램)가 내부적으로 이 라이브러리를 씀. 즉 일반 계정이 "내 실명 정보 좀 바꿀게요" 하고 요청하면, 실제로 /etc/passwd를 손대는 주체는 루트 권한으로 돌아가는 libuser임.

여기서 신뢰 경계가 하나 생김. 입력은 일반 사용자, 쓰기 권한은 루트. 이런 구조는 언제나 조심스럽게 다뤄야 하는 자리임.

2. 문제의 본질 — 비원자적 쓰기

계정 파일을 안전하게 고치는 정석은 이런 흐름임.

• 임시 파일을 새로 만들고 거기에 전체 내용을 씀
• 제대로 다 써졌는지 확인하고 디스크에 반영함
• 마지막에 rename()으로 원본 자리에 갈아끼움

rename은 원자적이라, 중간에 뭐가 터져도 파일은 "예전 것" 아니면 "새 것" 둘 중 하나로만 존재함. 반쯤 쓰인 상태가 나올 수 없음.

그런데 libuser는 원본 파일을 열어서 truncate 후 처음부터 다시 쓰는 방식을 택했음. 이러면 쓰기가 진행되는 짧은 순간 동안 /etc/passwd는 물리적으로 불완전한 상태로 존재함. 평소엔 눈 깜짝할 사이라 아무도 신경 안 쓰지만, 공격자 입장에서 그 찰나는 노려볼 만한 창이 됨.

3. 창을 억지로 벌리는 방법 (개념 수준)

여기서 재밌는 건, 공격자가 굳이 정교한 타이밍 싸움을 할 필요가 없었다는 점임. 리소스 제한이라는 훨씬 얌전한 수단이 있었음.

• 자식 프로세스는 부모의 RLIMIT_FSIZE(파일 크기 상한)를 물려받음
• 이 상한을 아주 작게 걸어두고 userhelper를 실행하면, 루트 권한으로 /etc/passwd를 다시 쓰던 도중 상한에 걸려 프로세스가 그대로 종료됨
• 결과적으로 /etc/passwd는 지정한 크기에서 정확히 잘린 상태로 남음

즉 "언제 죽일까"가 아니라 "몇 바이트에서 자를까"의 문제로 바뀜. 경합 조건이지만 승률이 사실상 100%에 가까운 경합이었던 셈임. 여기에 같은 시기 공개된 짝꿍 이슈인 CVE-2015-3245(GECOS 필드에 개행 문자가 걸러지지 않던 문제)를 얹으면, 공격자는 자기 계정 정보 안에 원하는 형태의 줄을 미리 심어두고 절단 위치까지 조정할 수 있었음. 그렇게 해서 루트 항목의 암호 필드가 비어버리는 상태를 만들면, 그 다음은 설명이 필요 없음.

이 글에서는 여기까지만 개념적으로 정리함. 재현 스크립트는 다루지 않음. 중요한 건 절차가 아니라 "부분적으로 쓰인 설정 파일은 그 자체로 권한 상승 경로가 된다"는 사실임.

4. 방어자 관점 — 무엇을 봐야 하나

이미 오래전에 패치된 사안이지만, 탐지 관점은 지금도 그대로 재활용됨.

• 계정 파일 무결성 감시: AIDE나 유사 도구로 /etc/passwd, /etc/shadow, /etc/group의 해시 변화를 추적함. 정상적인 계정 생성과 달리, 공격 흔적은 보통 파일 크기가 갑자기 줄어드는 형태로 나타남
• 빈 암호 필드 점검: 두 번째 필드가 비어 있는 항목이 있는지 주기적으로 확인함. 특히 UID 0 계정은 무조건 봐야 함
• auditd 규칙: /etc/passwd에 대한 write/truncate 이벤트를 감시하고, 어떤 실행 파일이 그 변경을 일으켰는지 함께 기록함. 정상 관리 작업(useradd, usermod)이 아닌 경로에서 변경이 발생하면 그게 신호임
• setuid 프로그램 실행 로그: 일반 사용자가 userhelper 계열을 반복 호출하는 패턴은 흔한 일이 아님. 짧은 시간에 여러 번 실행되고 그때마다 계정 파일이 바뀌었다면 들여다볼 가치가 충분함
• 비정상 종료 흔적: 루트 권한 프로세스가 파일 크기 제한이나 시그널로 중도 종료된 기록은 그 자체로 이상 징후임

5. 완화 — 순서대로

• 패치가 먼저임. 배포판 벤더가 제공하는 libuser 및 관련 패키지 업데이트를 적용하면 근본 원인이 사라짐. 라이브러리 갱신이라 이미 떠 있는 프로세스 정리도 같이 챙겨야 함
• 불필요한 진입점을 줄임. 서버 용도의 시스템에서 일반 사용자가 chfn/chsh로 자기 정보를 바꿀 일이 거의 없다면, 해당 consolehelper 연동이나 setuid 비트를 정책에 맞게 정리하는 게 합리적임. 개인적으로는 데스크톱이 아닌 시스템에서 이런 setuid 중개 도구를 그대로 두는 걸 별로 좋아하지 않음
• 백업과 복구 경로를 준비함. /etc/passwd가 깨졌을 때 되돌릴 수 있는 스냅샷이 있으면 사고가 사건으로 번지지 않음. pwck 같은 검증 도구를 정기 점검에 넣어두는 것도 추천함
• 같은 패턴을 자체 코드에서도 찾아봄. 설정 파일을 직접 열어 truncate하고 다시 쓰는 코드가 사내 스크립트나 자체 데몬에 남아 있다면, 그건 libuser와 똑같은 실수임. 임시 파일 + rename 패턴으로 바꾸는 데 오래 걸리지 않음

6. 이 사건에서 챙길 것

취약점이라고 하면 보통 파싱 오류나 메모리 손상을 떠올리게 되는데, 이 건은 정상적인 코드가 중간에 멈췄을 때 남는 상태가 문제였음. 논리에 버그가 없어도, 실패 시나리오를 설계하지 않으면 그 자리가 공격면이 됨. 그리고 그 실패를 유발하는 수단이 꼭 대단할 필요도 없었음. 리눅스가 원래부터 제공하던 리소스 제한 기능 하나면 충분했음.

10년 전 이야기지만, "권한 있는 프로세스가 신뢰 경계 너머의 입력으로 중요한 파일을 다시 쓴다"는 구조는 지금도 사방에 있음. 내가 관리하는 시스템에도 그런 코드가 남아 있는지 한 번쯤 뒤져보면 좋겠음. 혹시 비슷한 패턴 발견한 적 있으면 댓글로 공유해 주세요. 같이 정리해 봐요.