Avast 백신 샌드박스 진입과 탈출 2부 — CVE-2025-13032로 SYSTEM 권한 획득하기

AI 요약

이 글은 Avast 커널 드라이버의 이중 페치 취약점 CVE-2025-13032를 이용해 최신 Windows 11에서 로컬 권한 상승을 수행한 연구의 두 번째이자 마지막 편입니다. 공격자는 사용자 모드에서 전달한 _UNICODE_STRING의 Length 값을 커널이 여러 차례 읽는 틈을 노립니다. 한 스레드는 작은 값으로 메모리를 할당하게 하고, 다른 스레드는 복사 시점에 큰 값으로 바꿉니다. 할당 크기보다 많은 데이터를 복사해 paged pool 오버플로를 일으키는 방식입니다.

오버플로를 I/O Ring 손상으로 연결

Windows의 paged pool은 커널과 드라이버가 쓰는 메모리 영역입니다. 같은 크기 할당은 유사한 크기 구간에 모이는 경향이 있어 힙 스프레이를 이용할 수 있습니다. 연구진은 I/O Ring 객체의 RegBuffers 배열을 손상 대상으로 삼았습니다. 이 배열은 등록된 버퍼를 가리키는 포인터들을 담으며, 사용자 입력에 따라 할당 크기를 조절할 수 있습니다. 오버플로 버퍼와 같은 풀 버킷에 들어가도록 등록 버퍼 수를 정한 뒤, 다수의 배열을 할당하고 일부를 해제해 빈 공간을 만듭니다. 취약한 할당이 그 공간에 놓이도록 유도해 인접한 배열의 포인터를 덮어씁니다.

손상된 포인터를 연구진이 제어하는 사용자 메모리의 가짜 _IOP_MC_BUFFER_ENTRY를 가리키게 하면 임의 커널 읽기·쓰기 원시 기능을 얻습니다. IoRingReadFile은 파일에서 읽은 데이터를 등록 버퍼 주소에 기록하므로 커널 메모리 쓰기에 쓰입니다. 반대로 IoRingWriteFile은 등록 버퍼 주소에서 데이터를 읽어 파일에 기록하므로 커널 메모리를 읽는 데 쓸 수 있습니다. 가짜 버퍼 엔트리의 Address 값을 바꾸면 읽기·쓰기 대상을 바꿀 수 있습니다.

MDL에서 커널 주소 유출

커널 주소 공간 배치 난수화 때문에 다음 단계에는 유효한 커널 주소가 필요합니다. 연구진은 I/O 작업 중 만들어지는 MDL(Memory Descriptor List)을 이용해 현재 프로세스의 _EPROCESS 주소를 얻습니다. MDL은 버퍼의 물리 페이지를 고정해 I/O에 쓰며, 소유 프로세스를 가리키는 Process 필드를 포함합니다. 손상된 버퍼 엔트리가 사용자 메모리에 있으므로, 엔트리에 기록된 MDL 포인터를 사용자 모드에서 확인할 수 있습니다. 이어 임의 읽기로 MDL의 Process 필드를 읽어 _EPROCESS 주소를 알아냅니다.

정리 과정의 충돌 방지와 권한 상승

오버플로는 풀 청크 헤더의 ProcessBilled 값도 손상합니다. 이를 그대로 두면 I/O Ring 객체를 해제할 때 블루스크린이 발생합니다. 연구진은 정상 I/O Ring의 풀 헤더 값과 자신이 이미 얻은 _EPROCESS 주소를 이용해 풀 할당량 쿠키를 계산한 뒤, 손상된 헤더에 올바른 값을 복원합니다. 또한 가짜 버퍼 엔트리를 정리하는 과정에서 커널이 사용자 포인터를 해제하지 않도록 참조 횟수를 조정하고, 등록된 버퍼를 해제해 MDL 참조를 정리합니다.

마지막으로 _EPROCESS의 연결 목록을 따라 SYSTEM 프로세스를 찾고 토큰 값을 읽습니다. 그 값을 현재 프로세스의 토큰 필드에 기록하면 SYSTEM 권한을 얻습니다. 연구진은 CVE-2025-13032가 패치됐으며 Avast를 최신 버전으로 업데이트하라고 안내합니다. 글은 최신 Windows 커널과 드라이버에서 사용자 메모리 접근마다 사용자 모드 주소인지 확인하는 접근자(user-mode accessors)를 사용해 여기 설명한 기법을 막는다고 덧붙입니다.

Hacker News 반응

• @x-complexity — 백신이 해결하는 문제보다 더 많은 문제를 일으킨다는 사례가 또 하나 늘었습니다. 백신은 처음에 알려진 악성 서명과 파일만 검사할 때는 쓸모가 있었습니다. 이제는 온갖 기능을 덧붙여 벽을 부수는 쇠망치와 다를 바 없습니다. 실행 중 보안을 진지하게 생각한다면 남은 방법은 애플리케이션 허용 목록과 모든 접근 지점을 최소 권한으로 잠그는 일입니다.
  • @oblio — 가까운 미래에는 애플리케이션, 포트, URL, 경로 조각을 포함한 URL, 파일 시스템 계층까지 모든 항목에 허용 목록이 필요하다고 봅니다. 다만 현재 OS 구조로 구현할 수 있을지는 모르겠습니다.
  • @ulimn — AppArmor나 SELinux 모델이 이 문제를 다루는 좋은 방법 아닌가요?
  • @codedokode — 아닙니다. 이 용도에는 맞지 않습니다. 애플리케이션을 실행하기 전에 규칙을 정해야 하는데, 프로그램이 무엇을 할지 어떻게 미리 알 수 있나요? 올바른 규칙을 찾는 데 시간이 많이 들고 프로그래머가 아니면 불가능합니다. 하루에 앱 10개를 설치하면서 모두 제대로 작동하게 하려면 규칙 작성에 얼마나 시간을 써야 할까요? 실행 중 카메라 접근을 1분만 허용하는 식으로 규칙을 바꿀 수도 없습니다. 파일 접근은 제한해도 DBus, 오디오, 비디오, GPU, /proc, DNS 도메인 접근을 제한할 수 있나요? 규칙이 1970년대 타자기 시대 컴퓨터를 위해 만들어진 것처럼 느껴집니다. 사용자는 설정 파일을 쓰지 않고도 위험 없이 무엇이든 실행하고 싶어 합니다. 그런 OS를 만들 실력이 Linux 배포판 제작자들에게 부족합니다. curl + sudo bash로 설치하는 시스템은 안전한 OS와 정반대입니다.
• @codedokode — 백신 자체가 나쁜 것은 아닙니다. 직원 100명이 링크를 전부 누르고 첨부 파일을 모두 여는 회사를 운영한다고 생각해 보세요. 백신을 쓰는 편이 확실히 안전합니다.
  • @r_lee — 어떻게요? 수백 명 중 한 명이 탐지 가능한 악성 파일을 내려받았을 때 재앙을 막았다면 백신이 제 역할을 한 겁니다.
  • @fn-mote — 로컬 권한 상승 취약점이 전혀 없다고 가정하는 건가요? 일반적으로 심각도가 낮더라도 누군가 사용자가 실행하도록 유도하면 끝입니다. 로컬 컴퓨터에 발판을 잡으면 네트워크 안에서 옆으로 퍼지는 건 시간문제입니다. 실시간 AI 공격과 싸울 준비를 하세요. 아직 대부분의 사이트가 그런 공격을 겪지 않았을 뿐입니다. 백신도 공격자가 침투하는 발판이 될 수 있습니다.
• @Batman8675309 — 하드웨어 가상화가 보안의 미래라고 믿습니다. Qubes OS가 올바른 방향을 잡았지만 앱마다 전체 OS를 실행하면 부담이 큽니다. Android의 Microdroid처럼 앱마다 축소된 VM을 실행하는 편이 낫습니다. Windows 10의 Microsoft Defender Application Guard는 Edge 보안 면에서 요새 같았습니다. 단종됐고 성능도 아쉬웠지만, 아이디어를 더 발전시키길 바랐습니다.
  • @stingraycharles — OS의 프로세스 격리 책임을 CPU로 옮기는 것뿐 아닌가요? 프로세스끼리 상호작용해야 하는 현실도 문제가 되지 않나요? 비밀번호 관리자나 클립보드는 사용자 불편을 키우지 않고 어떻게 처리하나요?
  • @j16sdiz — 모든 것을 샌드박스에 넣거나 가상화해도 데이터 공유 문제는 사라지지 않습니다. 누군가는 권한을 통제해야 하고, 그 지점이 가장 약한 고리가 됩니다. 결국 작동하지 않거나, 권한이 너무 느슨하거나, 사용자에게 권한 대화상자를 끊임없이 띄우게 됩니다.
• @conception — 허용 목록은 공급망 공격을 막지 못합니다. 행동 분석 같은 방법이 필요합니다.
• @wzdd — 정말 아슬아슬한 TOCTOU 공격입니다.
• @fathermarz — 서명 기반 백신과 CVE 피드 모두 신뢰를 잃었습니다. 공격자는 스캐너에 걸리지 않을 때까지 검사하고 알려진 지문을 피합니다. 정적 분석을 통해 행동 차이를 잡는 방법이 유일하다고 봅니다. 참고로 저는 이런 분석을 하는 Vigilance를 만들고 있습니다.
  • @nikanj — 백신의 목적은 악성코드를 잡는 게 아니라 PCI DSS 승인 도장을 받는 일입니다. 규제 포획이 최고의 마케팅 전략입니다.

원문: Safa Team / 번역·요약: Trawling