5.8에서 들어와 5.17에서 막힌 구멍: 리눅스 watch_queue OOB Write

이미지 출처: CISA KEV

리눅스 커널 5.8에 watch_queue라는 조용한 기능이 하나 들어왔음. 키링(keyring)이나 장치 상태가 바뀔 때 커널이 사용자 공간으로 알림을 밀어 넣어주는 통로인데, 일반 파이프를 특수한 플래그로 열어서 만드는 구조라 눈에 잘 띄지도 않았음. 그런데 이 통로에 붙는 필터 설정 코드가 같은 값을 두 번 검사하면서 기준을 서로 다르게 잡아버렸고, 그 어긋남이 2022년 3월 CVE-2022-0995로 정리됐음.

핵심 요약

• 리눅스 커널 watch_queue 알림 서브시스템의 필터 설정 경로에서 힙 경계 밖 쓰기(OOB Write)가 발생함. 로컬 일반 사용자가 root 권한 상승까지 노릴 수 있는 유형임.
• 원인은 "필터 개수를 세는 검사"와 "필터를 실제로 채우는 검사"가 서로 다른 상한을 쓴 것. 세는 쪽이 작게 세니 할당은 작게 되고, 쓰는 쪽은 그보다 많이 씀.
• 정답은 패치. 당장 못 올리면 CONFIG_WATCH_QUEUE 비활성화나 seccomp로 알림 파이프 생성 자체를 막고, pipe2 플래그와 'W' 계열 ioctl을 로깅해두면 탐지 신호가 꽤 선명함.

1. watch_queue가 하는 일

사용자 공간에서 pipe2()를 호출할 때 O_NOTIFICATION_PIPE 플래그를 주면 평범한 파이프가 아니라 알림 큐가 만들어짐. 그다음 이 fd에 ioctl을 걸어서 큐 크기를 정하고, 어떤 종류의 알림만 받을지 필터를 등록함. 특권이 필요 없음. 커널 옵션만 켜져 있으면 아무 일반 사용자나 이 경로를 그대로 탄다는 점이 이 취약점의 전제 조건이자 위험 요소였음.

2. 버그의 정체 — 같은 값, 다른 자

결과는 뻔함. 첫 루프에서 "이건 범위 밖이니 안 셀게"라고 건너뛴 항목을, 두 번째 루프는 "이 정도면 범위 안이네"라며 그대로 기록함. 할당된 배열은 작은데 쓰기 커서는 계속 전진하니 힙 경계 너머로 사용자가 고른 값이 새어나감. 덤으로 타입 비트맵을 세팅하는 비트 연산도 같이 범위를 벗어남. 개념적으로는 "세는 코드와 쓰는 코드가 서로 다른 자를 들고 있었다" 딱 그 한 줄임.

공격자 입장에서 좋은(=방어자 입장에서 나쁜) 점은, 넘어가는 값이 사용자가 상당 부분 제어 가능한 데이터라는 것. 커널 힙 할당자의 객체 배치를 다듬어 인접 슬랩에 의미 있는 구조체를 놓을 수만 있으면 단순 크래시에서 끝나지 않고 권한 상승 시나리오로 이어짐. 실제로 공개된 연구에서도 로컬 사용자가 root 셸을 얻는 데까지 도달했음. 자세한 익스플로잇 절차는 여기서 다루지 않겠음. 방어에 필요한 건 "이게 왜 터지는가"까지고, 그다음은 패치가 답이기 때문임.

3. 어디까지 영향이 가나

• 로컬 권한 상승이 핵심임. 원격 단독 공격은 아니지만, 웹셸이나 탈취된 서비스 계정 같은 발판이 이미 있는 상황에서 root로 올라서는 두 번째 단계로 딱 맞음.
• 컨테이너 안에서도 문제가 됨. 커널은 호스트와 공유하니, 컨테이너 내부 사용자가 커널 힙을 건드리면 격리 경계 자체가 흔들림.
• 단, CONFIG_WATCH_QUEUE가 켜진 커널에서만 성립함. 배포판마다 갈렸고, 이 옵션을 켜둔 데스크톱·서버 배포판이 주된 표적이 됐음.

4. 내 시스템은 해당되는가

• 커널 빌드 설정에서 grep WATCH_QUEUE /boot/config-$(uname -r)로 옵션이 y인지 확인. n이면 이 경로 자체가 없음.
• 배포판 커널이면 버전 숫자만 보고 판단하지 말 것. 백포트 패치가 들어가 있는 경우가 많아서, 배포사 보안 공지의 패키지 버전과 실제 설치본을 대조하는 게 정확함.
• 업스트림 기준으로는 5.17 계열에서 정리됐고, 그 이전 안정화 브랜치들로 수정이 내려갔음.

5. 탐지 — 무엇을 봐야 하나

이 취약점의 고마운 점은 정상 워크로드에서 거의 안 쓰이는 API를 지난다는 것임. 즉 신호 대비 잡음이 낮음.

• 알림 파이프 생성 감시: pipe2() 호출 중 O_NOTIFICATION_PIPE 플래그가 붙은 건을 audit이나 eBPF 기반 센서(Falco, Tetragon 등)로 잡음. 일반 애플리케이션에서 이 플래그가 뜨는 경우는 사실상 없다고 봐도 됨.
• watch_queue 계열 ioctl: 큐 크기 설정과 필터 설정 ioctl은 'W' 매직 계열임. auditd의 syscall 인자 필터로 ioctl 명령 값을 좁혀 규칙을 걸어두면, 시도 자체가 로그에 남음.
• 실패의 흔적: 익스플로잇은 한 번에 성공하지 않음. 힙 그루밍이 어긋나면 dmesg에 slab 손상 경고, general protection fault, kernel oops가 남음. 커널 크래시 로그를 SIEM으로 안 보내고 있었다면 이번 기회에 파이프라인을 하나 붙여두길 개인적으로는 추천함.
• 사후 신호: setuid 바이너리 실행 없이 프로세스의 uid가 0으로 바뀌는 순간, 또는 컨테이너 프로세스가 호스트 네임스페이스 자원을 건드리는 순간. 커널 LPE 전반에 공통으로 쓰이는 탐지 축이라 이 CVE 하나 지나가도 계속 값어치를 함.

6. 완화 — 우선순위대로

• 패치가 1순위. 커널 업데이트 후 재부팅까지 해야 적용됨. livepatch를 쓴다면 해당 CVE가 패치 세트에 포함됐는지 확인이 필요함.
• 당장 재부팅 창을 못 잡는 서버라면 공격면 제거가 차선. 자체 빌드 커널을 쓴다면 CONFIG_WATCH_QUEUE를 끄는 게 가장 확실함. 이 기능을 실제로 쓰는 워크로드는 드묾.
• seccomp 프로파일로 알림 파이프 생성 플래그와 해당 ioctl을 거부. 컨테이너 워크로드라면 기본 프로파일을 그대로 쓰지 말고 필요한 syscall만 남기는 방향으로 조여두는 게 이런 종류의 커널 버그 전체에 대한 보험이 됨.
• 커널 하드닝 옵션(슬랩 프리리스트 랜덤화·강화), kernel.dmesg_restrict=1, kernel.kptr_restrict=2 같은 설정은 익스플로잇 안정성을 떨어뜨리는 역할을 함. 근본 해결은 아니지만 공격자 비용을 올려줌.

마무리하며

이 사건에서 남는 교훈은 취약점 이름보다 패턴 쪽인 것 같음. "검증하는 루프"와 "사용하는 루프"가 분리돼 있으면 언젠가 두 기준이 어긋난다는 것. 커널이든 우리가 짜는 파서든 똑같이 적용되는 이야기라, 코드 리뷰할 때 "이 상한값, 아래쪽에서 또 계산하고 있지 않나?" 한 번만 되짚어보면 꽤 많은 걸 미리 잡을 수 있음.

오늘은 여기까지. 운영 중인 서버에 grep WATCH_QUEUE /boot/config-$(uname -r) 한 줄 돌려보는 것부터 시작해보시고, 커널 크래시 로그를 SIEM으로 보내고 계신 분들은 어떤 규칙으로 정리하셨는지 댓글로 공유해주시면 저도 배우겠음. 같이 조금씩 단단하게 만들어가요.