특권 헬퍼가 사용자 디렉터리를 믿을 때 생기는 일 (CVE-2015-5287, Red Hat ABRT)

이미지 출처: CISA KEV

2015년 가을, 레드햇 계열 서버를 돌리던 관리자들은 abrt 관련 보안 업데이트 공지를 한 번에 여러 건 받아야 했다. 그것도 원격 RCE가 아니라 전부 로컬 권한 상승이었다. "로컬이면 이미 들어온 거 아니냐"고 넘기기 쉬운데, 웹셸 하나로 www-data 권한만 잡은 공격자에게 로컬 루트 취약점은 사실상 게임의 후반부를 열어주는 열쇠라서 그렇게 가볍게 볼 물건이 아니었다. CVE-2015-5287은 그 묶음 중 하나다.

핵심 요약

• ABRT(Automatic Bug Reporting Tool)는 크래시가 나면 자동으로 코어덤프와 진단 정보를 모아주는 도구인데, 그 수집 과정 일부가 높은 권한으로 동작함
• CVE-2015-5287은 그 특권 동작이 일반 사용자가 손댈 수 있는 경로·파일을 충분히 의심하지 않아 로컬 사용자가 권한을 끌어올릴 수 있었던 사안임
• 방어는 패치가 1순위, 그다음이 심볼릭 링크 보호 커널 파라미터·코어덤프 정책 정리·abrt 관련 디렉터리 감사 규칙임

ABRT가 하는 일부터 짚고 가기

ABRT는 이름 그대로 "버그를 자동으로 신고해주는 도구"다. 프로세스가 죽으면 커널이 코어덤프를 넘겨주고, ABRT가 그걸 받아 크래시 정보를 정리해 스풀 디렉터리에 쌓아두고, 필요하면 디버그 심볼을 내려받거나 sosreport 같은 진단 자료까지 붙여 리포트를 만든다. RHEL·Fedora 계열에서는 기본으로 깔려 조용히 돌아가는 경우가 많다.

여기서 방어자가 눈여겨봐야 할 지점은 딱 하나임.

• 크래시를 일으키는 쪽은 아무 권한 없는 일반 사용자임
• 크래시를 처리하는 쪽은 root 혹은 그에 준하는 권한임
• 둘이 만나는 접점이 파일시스템 경로라는 것

권한이 낮은 쪽이 입력을 만들고 권한이 높은 쪽이 그걸 처리하는 구조는, 설계할 때 가장 조심해야 하는 형태인데도 "내부 도구니까 괜찮겠지" 하고 넘어가기 쉬운 곳이기도 하다.

문제의 구조 — 개념 수준으로만

CVE-2015-5287이 속한 abrt 계열 로컬 권한 상승들은 대체로 같은 뿌리를 공유함. 실행 가능한 재현 절차는 굳이 적지 않고, 어떤 조건이 겹치면 위험해지는지만 정리함.

• 예측 가능한 경로: 특권 프로세스가 /var/tmp나 스풀 하위처럼 일반 사용자도 이름을 미리 알 수 있는 위치에 파일·디렉터리를 만듦
• 검사와 사용 사이의 틈(TOCTOU): "이 경로가 안전한가" 확인한 시점과 실제로 열거나 쓰는 시점 사이에 아주 짧은 공백이 있고, 그 사이에 대상이 다른 것으로 바뀔 수 있음
• 심볼릭 링크·하드링크: 그 틈에 링크를 심어두면, 특권 프로세스가 원래 의도한 파일 대신 전혀 다른 시스템 파일을 향해 쓰기·소유권 변경을 수행하게 됨
• 소유권·권한의 애매한 인계: 사용자 소유로 만들어진 산출물을 나중에 root가 신뢰하고 다시 읽거나 실행 경로에 끼워 넣음

결과적으로 공격자는 자기 셸에서 프로그램 하나를 일부러 죽이는 정도의 평범한 행동으로 특권 처리 루틴을 발동시키고, 그 루틴의 손을 빌려 자기가 원하는 파일에 접근하게 만듦. 특별한 익스플로잇 코드보다 타이밍과 경로 조작이 본질인 유형임.

탐지 — 무엇을 로그로 남길 것인가

이 계열은 네트워크 IDS로는 거의 안 잡힘. 전부 호스트 안에서 벌어지는 일이라 파일시스템과 프로세스 관점의 관측이 필요함.

• 비정상적인 크래시 빈도: 이런 공격은 경쟁 조건을 이기려고 크래시를 수십, 수백 번 반복 유발하는 경우가 많음. 같은 사용자·같은 바이너리가 짧은 시간에 반복적으로 코어덤프를 남기면 그 자체가 신호임. abrt-cli list와 journald의 abrtd 로그를 함께 보면 패턴이 드러남
• abrt 관련 디렉터리 감사: /var/spool/abrt, /var/tmp/abrt 하위의 생성·이름변경·삭제를 auditd 규칙으로 걸어두면 링크 심기 시도를 관측할 수 있음. 예: -w /var/spool/abrt -p wa -k abrt_watch
• 거부된 심볼릭 링크 추적: 커널의 링크 보호 기능이 켜져 있으면 차단 시 로그가 남음. 이 로그가 뜬다는 건 누군가 그 트릭을 쓰려 했다는 뜻이므로 단순 노이즈로 넘기지 말 것
• 이상한 위치의 root 소유 파일: 사용자 홈이나 임시 디렉터리에 root 소유 파일이 새로 생기는 것은 대표적인 사후 흔적임. 주기적으로 스캔해두면 좋음
• SELinux denial: enforcing 상태라면 AVC 거부 로그가 공격 시도의 1차 증거가 되는 경우가 많음

완화 — 순서대로

• 패치가 1순위: 벤더 업데이트가 이미 나와 있는 사안임. abrt와 libreport 계열 패키지를 함께 올려야 함. 하나만 올리고 끝내면 다른 구성요소에 같은 구조가 남음
• 커널 링크 보호 활성화: fs.protected_symlinks=1, fs.protected_hardlinks=1을 sysctl에 박아둘 것. 이번 건뿐 아니라 같은 계열 취약점 상당수의 성공률을 크게 떨어뜨림
• 코어덤프 정책 정리: kernel.core_pattern이 어디로 파이프되고 있는지 확인하고, setuid 프로그램의 덤프를 허용할 이유가 없다면 fs.suid_dumpable=0을 유지할 것
• 필요 없으면 끄기: 다중 사용자 서버나 컨테이너 호스트에서 자동 버그 리포팅이 실제로 쓰이지 않는다면 abrt 서비스를 비활성화하거나 제거하는 편이 가장 확실함. 개인적으로는 사용자 계정이 여럿 붙는 서버라면 끄는 쪽을 추천함
• 마운트 옵션: /var/tmp, /tmp를 별도 파티션으로 두고 nosuid, nodev를 걸어두면 후속 단계의 선택지를 좁힐 수 있음

10년이 지나도 안 낡는 교훈

이 취약점이 지금도 읽을 가치가 있는 건, 똑같은 구조가 요즘 코드에도 계속 나오기 때문임. 백업 에이전트, 모니터링 데몬, 로그 수집기, 컨테이너 런타임 훅 — root로 돌면서 사용자 영역의 경로를 만지는 물건은 여전히 많음. 점검 질문은 세 개면 충분함.

• 이 특권 프로세스가 다루는 경로 중 낮은 권한 사용자가 만들거나 바꿀 수 있는 것이 있는가
• 경로를 검사한 뒤 실제로 여는 사이에 바뀔 수 있는 틈이 있는가 (디렉터리 핸들 기준의 *at 계열 호출을 쓰는가)
• 산출물의 소유권과 퍼미션을 누가 최종 결정하는가

사실 취약점 하나하나를 외우는 것보다 이 질문 세 개를 손에 익히는 게 훨씬 오래 갑니다. 오늘 여러분 서버에서 sysctl fs.protected_symlinks 한 줄만 쳐보시면 좋겠어요. 값이 0으로 나오면 그거 하나 바꾸는 데 1분도 안 걸리거든요. 혹시 운영 중인 환경에서 이런 특권 헬퍼 점검하다가 재미있는 걸 발견하셨다면 댓글로 공유해 주세요. 같이 보면서 배워보아요!