모든 리눅스를 뚫는다는 'Dirtyfrag' — 서버 관리자가 지금 점검해야 할 것들

리눅스 보안 커뮤니티에서 ‘Dirtyfrag’라는 이름이 돌고 있습니다. 거의 모든 배포판의 일반 사용자 계정에서 root 권한을 따낼 수 있다는 주장이 붙어 있는데요. 클라우드 인프라부터 사내 빌드 서버까지, 멀티유저 환경을 굴리는 사람이라면 무시하기 어려운 이슈입니다.

먼저 한 가지는 솔직하게 말씀드리겠습니다. 지난 30일간의 커뮤니티 논의가 충분히 쌓이지 않은 상태이고, 공개된 권위 있는 어드바이저리도 제한적입니다. 그래서 이 글은 ‘Dirtyfrag’라는 이름의 LPE(Local Privilege Escalation) 류 이슈를 어떻게 바라봐야 하는지, 그리고 이런 패턴의 취약점이 떴을 때 운영자가 따라야 할 표준 플레이북을 함께 짚는 형태로 진행하겠습니다.

‘Dirtyfrag’가 뭘 노린다는 건가요

이름이 암시하듯 메모리 단편화(fragmentation) 처리 경로를 공격 표면으로 삼는다고 알려져 있습니다. 과거의 Dirty COW(CVE-2016-5195)나 Dirty Pipe(CVE-2022-0847)와 비슷한 작명 컨벤션입니다. 두 사건 모두 커널의 메모리·파이프 처리 로직에 있던 race condition을 이용해, 일반 사용자가 읽기 전용 파일을 덮어쓰거나 root 권한을 획득하는 식이었죠.

이런 류의 취약점이 무서운 이유는 명확합니다.

• 원격 코드 실행이 아니라 이미 셸을 가진 사용자가 권한을 올리는 시나리오라, 공유 호스팅·CI 러너·컨테이너 호스트가 직격탄을 맞습니다
• 커널 핵심 경로에 있는 코드라 거의 모든 배포판·커널 버전에 영향을 줍니다
• 익스플로잇 코드가 한번 공개되면 스크립트 키디 수준에서도 재현이 가능합니다

왜 ‘보편적’이라는 말이 붙을까요

리눅스 커널은 메모리 할당기(slab/slub), 페이지 캐시, 파이프 버퍼처럼 모든 프로세스가 공유하는 자료구조를 가지고 있습니다. 단편화 관련 로직은 이 모든 곳에 깔려 있고, 한 번 버그가 발견되면 특정 드라이버가 아니라 커널 코어가 영향을 받습니다. 그래서 우분투든 RHEL이든 데비안이든 Alpine이든 똑같이 패치를 받아야 합니다.

컨테이너 환경도 안전지대가 아닙니다. 컨테이너는 호스트 커널을 공유하기 때문에, 컨테이너 안의 비특권 프로세스가 호스트 커널의 권한 상승 버그를 트리거하면 그대로 호스트로 탈출할 수 있습니다. 도커나 쿠버네티스 노드를 운영한다면 더 신경 써야 한다는 뜻입니다.

지금 당장 해야 할 점검 5가지

거창한 대응책보다 기본기가 먼저입니다.

1. 커널 버전 인벤토리를 만드세요. uname -r을 모든 노드에서 수집해 어떤 버전이 어디에 깔려 있는지 한눈에 보이게 하세요
2. 배포판 보안 메일링 리스트(USN, RHSA, DSA)를 구독하고, CVE 번호가 확정되면 즉시 패치 윈도우를 잡으세요
3. 비특권 사용자의 셸 접근을 다시 살펴보세요. CI 러너에 직접 SSH가 열려 있거나, 빌드 컨테이너가 호스트 네트워크를 공유하고 있다면 줄이세요
4. seccomp, AppArmor, SELinux 프로파일을 점검해서, 익스플로잇이 흔히 쓰는 시스템 콜(userfaultfd, unshare, keyctl 등)을 차단할 수 있는지 확인하세요
5. 커널 라이브 패치(kpatch, kernelcare 등)를 도입해 두면, 재부팅 없이 긴급 패치를 적용할 수 있어 대응 시간이 크게 줄어듭니다

패치만 기다리면 되나요

아닙니다. 진짜 위험은 패치가 나오기까지의 며칠과 패치를 적용하기까지의 몇 주입니다. 많은 조직이 이 갭에서 뚫립니다.

그래서 단기적으로는 공격 표면을 좁히는 게 핵심입니다. 임시 사용자의 셸 권한을 회수하고, 의심스러운 프로세스의 권한 상승 시도를 감지하는 EDR/auditd 룰을 켜두세요. execve 호출 중에서 /tmp나 /dev/shm에서 실행되는 바이너리, 짧은 시간 안에 일어나는 setuid 호출 같은 패턴은 LPE 익스플로잇의 전형적인 신호입니다.

마무리하며

Dirty COW가 8년 전, Dirty Pipe가 4년 전이었습니다. 비슷한 이름이 또 등장한다는 건, 커널 메모리 처리 로직이 여전히 매력적인 공격 표면이라는 뜻이기도 합니다. 패치를 빨리 붙이는 조직과 그렇지 않은 조직의 차이는 다음 사고 때 더 크게 벌어질 겁니다.

여러분의 인프라에서 가장 늦게 업데이트되는 리눅스 호스트는 어디인가요? 그 한 대가 다음 사고의 진원지가 될 가능성이 가장 높습니다. 지금이 그 목록을 한번 훑어볼 좋은 타이밍입니다.