IT

CVE-2026-25506: Munge(뮤지) 20년 묵은 버퍼 오버플로우로 HPC/Slurm 클러스터 인증키 유출 위험 — 지금 점검할 것

작성자:

작성시각: 2026-02-14 14:00 KST

요약(TL;DR) — CVE-2026-25506 한눈에 보기

CVE-2026-25506은 HPC(슈퍼컴퓨터/클러스터) 환경에서 널리 쓰이는 인증 서비스 MUNGE의 데몬(munged)에 존재하는 버퍼 오버플로우 취약점입니다. Lexfo의 분석에 따르면 해당 버그는 약 20년간 코드베이스에 존재했고, 0.5.17 이하 모든 버전이 영향을 받습니다.

이 취약점이 악용되면 로컬 공격자가 프로세스 메모리에서 암호학적 키 소재(key material)를 유출할 수 있으며, 그 결과 MUNGE 자격증명(credential)을 위조해 Slurm 등 MUNGE 기반 인증에 의존하는 서비스에서 다른 사용자(잠재적으로 root 포함)를 사칭할 수 있습니다. GitHub 보안 권고는 0.5.18에서 수정되었다고 밝히며, 패치 후 클러스터 전체 키 재생성(키 롤오버)을 권고합니다.

  • 영향 범위: MUNGE 0.5 ~ 0.5.17 (업스트림 기준)
  • 공격 난이도/전제: 로컬(클러스터 내부 사용자 계정 등)에서 munged와 통신 가능한 경우가 핵심
  • 핵심 대응: MUNGE 0.5.18(또는 벤더 패치 포함 버전)로 업데이트 → 클러스터 전체 MUNGE 키 재발급 → 인증/잡 실행 로그 점검

배경: Munge와 Slurm/HPC에서 “인증키 1개”가 갖는 의미

HPC 클러스터는 여러 대의 리눅스 노드(컴퓨팅 노드)로 구성되며, 사용자는 보통 제출 노드(submit node)에서 작업을 제출하고 스케줄러(예: Slurm)가 작업을 적절한 노드에 배치합니다. Lexfo 글은 Slurm이 HPC 세계에서 널리 쓰이며(출처로 SchedMD의 인용을 소개), 이런 환경에서 노드 간 사용자 신원(UID/GID)을 검증하기 위해 MUNGE가 기본적으로 사용되는 경우가 많다고 설명합니다.

MUNGE는 각 노드에 munged가 동작하고, 동일한 비밀 키가 전체 노드에 배포되는 방식으로 “보안 영역(realm)”을 구성합니다. 즉, 한 노드에서 키 소재가 유출되면 클러스터 전체에서 통용되는 인증 토큰을 위조할 수 있어 영향이 노드 단위가 아니라 클러스터 단위로 확대될 수 있습니다(설계 특성상).

핵심 포인트(왜 중요한가): CVE-2026-25506이 ‘클러스터 권한 상승’으로 이어질 수 있는 이유

GitHub 보안 권고는 CVE-2026-25506의 임팩트를 다음과 같이 정리합니다. 로컬 공격자가 munged의 버퍼 오버플로우를 악용해 프로세스 메모리에서 키 소재를 유출할 수 있고, 그 키 소재로 임의의 MUNGE 자격증명을 위조하여 MUNGE 인증을 신뢰하는 서비스에서 사용자 사칭이 가능해질 수 있다는 것입니다.

Lexfo 원문은 이 취약점이 MUNGE 비밀키(토큰 생성/검증에 사용되는 키 소재) 유출로 이어져, 공격자가 클러스터 전역에서 유효한 토큰을 만들 수 있다고 설명합니다. 이 맥락에서 이는 “HPC 환경에서의 로컬 권한 상승(Local Privilege Escalation)”에 준하는 효과를 가질 수 있습니다(단, 실제로 어떤 권한이 가능한지는 클러스터 운영 정책/서비스 구성에 좌우).

또한 GitHub 권고는 PoC가 현대적 보호기법(ASLR, PIE, NX, RELRO) 하에서도 키 소재 추출을 보여줬다고 언급하지만, 현재까지 실제 야생(실환경) 악용 징후는 없다고 밝힙니다. 다만 HPC는 다중 사용자 환경인 경우가 많아 “로컬” 전제가 현실적으로 성립하기 쉬우므로, 패치 우선순위를 높게 잡는 것이 합리적입니다.

영향/리스크: 무엇이 어떻게 위험해지나

영향받는 버전/컴포넌트

  • 영향 버전: MUNGE 0.5 ~ 0.5.17 (Lexfo 및 GitHub 권고 기준)
  • 수정 버전: MUNGE 0.5.18 (GitHub 보안 권고 및 0.5.18 릴리즈 노트 기준)
  • 영향 컴포넌트: munged(MUNGE 인증 데몬). 또한 Lexfo는 취약 코드가 공용 라이브러리 영역에 있어 서버/클라이언트 양측 맥락을 논의하지만, 운영 관점에서는 우선 서버 데몬(munged) 구동 노드 전체를 영향 자산으로 보는 것이 안전합니다.

공격이 가능해지는 조건(개념 수준)

  • 공격 벡터: GitHub 권고는 로컬 공격자(Local attacker)를 전제로 합니다.
  • 필요 조건: 공격자가 munged와 통신하여 취약한 메시지 언패킹 경로를 트리거할 수 있어야 합니다(일반적으로 munged는 UNIX 소켓을 통해 요청을 처리). HPC 환경에서는 사용자 작업 실행/인증을 위해 해당 소켓 접근이 사용자에게 열려 있는 구성도 존재할 수 있어, 운영자는 소켓 권한/그룹 정책을 반드시 확인해야 합니다.
  • 결과: 프로세스 메모리에서 키 소재가 유출되면, 그 키로 임의 사용자(UID/GID)의 MUNGE 자격증명 위조 가능성이 생깁니다. 이는 Slurm 등의 인증 신뢰 체인에 직접 영향을 줍니다.

운영/비즈니스 리스크(보안 실무 관점)

  • 클러스터 전역 사칭: “한 노드의 키 유출 → 전체 노드에서 통용되는 자격증명 위조”로 확산 가능
  • 잡 실행/데이터 접근 위험: 사용자 사칭이 가능해지면, 스케줄러가 실행하는 작업 주체가 왜곡될 수 있고(잡 제출·실행), UID/GID 기반 접근제어(NFS 등) 환경에서는 연구 데이터/결과물 접근 통제에 영향이 생길 수 있습니다(구체적 피해 범위는 환경 구성에 따라 달라짐).
  • 사후 리스크: GitHub 권고는 “패치 이전에 이미 유출됐다면, 패치 이후에도 위조가 가능할 수 있다”는 취지로 패치 후 키 재발급을 권장합니다. 즉, 단순 업데이트만으로는 ‘이미 탈취된 키’ 위험을 제거하기 어렵습니다.

대응 체크리스트(SOC/IR/보안운영팀용) — 우선순위 순

1) 즉시: 영향 자산 식별(인벤토리)

  • MUNGE 설치/구동 여부 확인: Slurm 클러스터(제출 노드, 스케줄러 노드, 컴퓨팅 노드) 및 인증 연동 서버에서 munged 실행 여부를 확인
  • 버전 확인: munge --version 또는 배포판 패키지 버전으로 0.5.17 이하 여부 식별
  • 노드 전수 확인: MUNGE 키는 노드 간 공유되므로, “일부 노드만 패치”는 운영상 위험이 남을 수 있습니다. 클러스터 전체를 범위로 잡으세요.

2) 최우선: 패치 적용(업스트림 0.5.18 또는 벤더 패치)

  • 업그레이드: GitHub 권고 및 릴리즈 노트 기준, MUNGE 0.5.18로 업데이트
  • 벤더 공지 확인: RHEL 계열, Debian/Ubuntu, SUSE 등은 자체 보안 업데이트로 백포팅할 수 있으므로 “패키지 버전 숫자만”으로 단정하지 말고, 배포판 보안 권고/패치 포함 여부를 근거로 판단
  • 변경 관리: HPC는 작업 중단 영향이 크므로, 유지보수 창(maintenance window)에서 수행 계획 수립

3) 매우 중요: 패치 후 MUNGE 키 재발급(클러스터 전체)

GitHub 보안 권고는 예방 조치로 패치 후 키 재생성을 권장합니다. 이는 “이전 키가 유출됐을 가능성”을 제거하기 위한 조치입니다. 단, 키 재발급은 클러스터 전역에서 munged를 중지해야 하며, 인증이 필요한 작업에 운영 영향이 있을 수 있으니 반드시 유지보수 창에서 진행하세요.

  • 전 노드에서 munged 중지 (클러스터-wide)
  • 새 키 생성 (권고 예시): sudo -u munge /usr/sbin/mungekey --force --verbose
  • 새 키를 모든 노드에 안전하게 배포 (권한/소유자/퍼미션 유지)
  • 전 노드에서 munged 재시작

4) 탐지/헌팅 포인트: “키 유출 시도” 및 “사칭 징후” 점검

이 취약점은 로컬 기반이며, GitHub 권고는 야생 악용 징후가 없다고 말합니다. 그럼에도 운영자는 아래 신호를 점검해 “이미 시도됐는지”를 확인할 가치가 있습니다(환경별 로그 위치/포맷은 다를 수 있음).

  • 서비스 안정성: munged 프로세스의 비정상 종료/재시작 증가(예: systemd/journald에서 반복 재시작, 코어덤프 생성)
  • MUNGE 로그: 메시지 언패킹/디코딩 오류가 급증하는지(예: 실패/예외/세그폴트 관련 메시지). Lexfo 분석은 메시지 언패킹 실패가 오류 문자열로 이어질 수 있음을 코드 레벨로 보여줍니다.
  • Slurm 관제: 특정 사용자가 제출하지 않았는데도 잡이 생성되거나, 잡 실행 주체(UID/GID)가 비정상적으로 변하는지(회계/감사 로그, job accounting, 제출 노드의 인증/실행 로그)
  • 권한 상승 간접 징후: 관리자 계정/그룹을 사칭한 작업 실행 정황, sudo 로그의 비정상 사용(단, 이것만으로 CVE 악용을 단정할 수는 없음)

5) 하드닝(가능하면): 공격 표면 축소

  • UNIX 소켓 권한/그룹 점검: munged 소켓에 불필요한 사용자까지 접근 가능하지 않은지 확인(운영 요구사항과 충돌할 수 있으므로, 변경 전 영향 분석 필요)
  • 노드 접근 통제: 제출 노드/로그인 노드의 계정 관리 강화(최소권한, MFA/SSH 정책), 불필요한 로컬 쉘 계정 축소
  • 모니터링 표준화: munged/Slurm 주요 로그를 중앙 수집하고, 재시작·코어덤프·인증 오류 급증에 경보 룰 구성

FAQ

Q1. 원격(RCE) 취약점인가요?

GitHub 보안 권고는 로컬 공격자를 전제로 설명합니다. 즉 기본 전제는 “해당 시스템에 로컬로 접근 가능한 사용자”입니다. 다만 HPC는 다중 사용자 환경이 흔해 로컬 전제가 현실적으로 성립할 수 있다는 점이 리스크를 키웁니다.

Q2. 우리 환경이 Slurm이 아니면 영향이 없나요?

취약점 자체는 MUNGE(munged)에 있습니다. Slurm은 대표적인 의존 서비스일 뿐이며, MUNGE 인증을 신뢰하는 다른 서비스가 있다면 동일하게 영향 평가가 필요합니다(GitHub 권고의 표현).

Q3. 패치만 하면 끝인가요?

권장 대응은 “패치 + 키 재발급”입니다. GitHub 권고는 패치 이전에 키 소재가 유출됐을 가능성을 고려해, 패치 후에도 공격자가 기존 키로 위조할 수 있다는 취지에서 키 재생성을 예방 조치로 권합니다.

Q4. IOC(침해지표)가 있나요?

공개 자료 기준으로 “특정 파일 해시” 같은 고정 IOC가 제시되기보다는, munged 비정상 종료/재시작, 언패킹/디코딩 오류 급증, 잡 제출/실행 주체 이상 같은 운영 지표 중심의 점검이 현실적입니다. 또한 GitHub 권고는 현재 야생 악용 징후가 없다고 명시합니다.

Q5. 어떤 버전으로 올려야 하나요?

업스트림 기준 MUNGE 0.5.18에서 수정되었다고 GitHub 보안 권고와 0.5.18 릴리즈 노트가 밝힙니다. 다만 배포판은 백포팅이 있을 수 있으니, 최종 판단은 배포판 보안 공지(해당 CVE 패치 포함 여부)로 확인하세요.

참고 링크(출처)

댓글 남기기

이 사이트는 Akismet을 사용하여 스팸을 줄입니다. 댓글 데이터가 어떻게 처리되는지 알아보세요.