| CMASan: Custom Memory Allocator-aware Address Sanitizer | |
|---|---|
| Author | Junwha Hong, Wonil Jang, Mijung Kim, Lei Yu, Yonghwi Kwon, Yuseok Jeon |
| Conference | IEEE Symposium on Security and Privacy (S&P) |
| Year | 2025 |
개요
이 논문은 Custom memory allocator가 할당한 객체에서 AddressSanitizer(ASan)가 왜 메모리 버그를 놓치며, CMA를 표준 allocator로 교체하지 않고 객체의 경계와 수명을 추적하여 그 공백을 어떻게 줄일 수 있는지를 다룬다. 이를 통해서 CMASan은 CMA API의 반자동 식별과, 이를 통해서 새로운 CMASan이라는 디버깅 도구를 개발하였다.
Motivation
CMA는 cache 활용, 메모리 효율, 보안 등의 목적으로 사용된다. 논문이 GitHub star 순 상위 C/C++ 애플리케이션 100개를 조사한 결과, 44개에서 78개의 CMA를 발견했다. 문제는 ASan이 표준 allocator가 제공하는 객체 경계와 free를 추적하므로, 그 위에서 CMA가 정의한 더 작은 객체와 별도의 수명을 알지 못한다는 것이다. 즉, 메모리 접근 검사 코드가 존재하는 것과 올바른 객체 경계·수명을 검사하는 것은 별개라는 점이다. ASan이 load/store를 검사하더라도 CMA 내부 객체의 경계와 해제가 shadow memory에 반영되지 않으면 오류를 발견할 수 없다.
- Arena 패턴: 큰 chunk를 받아 작은 객체로 분할한다. ASan은 큰 chunk 외곽만 보호하므로 내부 객체 사이의 Buffer overflow를 놓칠 수 있다. 조사된 CMA의 69%가 이 패턴을 사용했다.
- Recycler 패턴: 반환된 객체를 내부 free-list 등에 저장하고 재사용한다. 표준 free가 호출되지 않으면 ASan은 CMA 수준의 해제를 인식하지 못해 Use-after-free(UAF)와 Double free(DF)를 놓친다. 조사된 CMA의 45%가 이 패턴을 사용했으며 Arena와 중첩될 수 있다.
Main Idea
CMA의 내부 할당기를 유지하면서 CMA가 애플리케이션에 제공하는 객체 단위의 경계와 수명을 ASan에 연결하였다. API를 식별한 뒤 요청 크기를 늘려 redzone 공간을 확보하고, 할당·해제에 맞추어 Shadow memory를 갱신하며, 표준 allocator의 메타데이터와 별개로 CMA 객체 정보를 관리한다.
Design
- CMA API 식별과 반자동 분류: CodeQL의 함수 이름·반환 포인터·size 인자 휴리스틱을 확장하고, size가 pointer arithmetic이나 내부 메타데이터 비교에 쓰이는지를 확인하여 후보를 추린다. 같은 source/header module의 함수를 family로 묶고, 규칙과 함수 본문을 사람이 검토하여 alloc/calloc/realloc/free/clear 및 보조 API, size·object·instance 인자를 분류한다. 평가에서 애플리케이션당 약 10분의 일회성 수작업이 필요했다. 소스의 수동 수정은 요구하지 않지만 API 인식 전체가 자동인 것은 아니다.
- 객체 경계와 수명 계측: alloc의 요청 크기에 redzone 크기를 추가하고 반환 객체 오른쪽을 poison한다. calloc/typed alloc은 개수와 granularity를 고려한다. 왼쪽에는 CMA 메타데이터가 있을 수 있어 별도의 redzone을 넣지 않으며, 인접 객체에서는 앞 객체의 오른쪽 redzone이 경계를 제공한다. free에서는 원래 객체 크기만큼 poison하고, 이미 FREED 상태이며 CMA ID가 같으면 DF를 보고한다. realloc은 반환 주소를 비교하여 제자리 resizing과 이동을 구분하고, 이동한 경우 이전 객체도 poison한다. redzone 확보를 위한 크기 증가는 CMA의 용량·최적화 판단에 영향을 줄 수 있다.
- Two-level 메타데이터: 주소로 객체 시작점, size, redzone size, 할당 상태, CMA ID, alloc/free trace를 찾는다. CMA가 좁은 주소 범위를 반복 사용하는 특성을 이용하여 2차 테이블을 필요할 때 할당한다. 구현의 1차 테이블은 64MB, 각 2차 테이블은 128MB이다. arena가 반환되면 관련 메타데이터를 제거하고, 재할당이 기존 기록과 겹치면 새 객체 영역은 갱신하되 겹치지 않는 freed 영역의 기록은 남겨 오래된 객체 접근을 추적한다.
- Quarantine: CMA free를 즉시 실행하지 않고 객체를 poison한 뒤 요청을 FIFO에 보관한다. 한도에 도달하면 오래된 요청을 해당 CMA에 전달한다. 서로 다른 CMA instance의 요청이 섞이지 않도록 분리하며, 기본 한도는 256KB와 8,192개 객체이다. 객체 재사용을 늦춰 UAF/DF 탐지 창을 늘리는 대신 메모리 사용량과 실제 해제 시점을 바꾼다. 내용 보존이 필요한 realloc에는 이 free 지연을 적용하지 않는다.
네 가지 오탐 회피: CMA 내부 동작과 계측 사이의 충돌을 아래 방법으로 처리한다. 정확도 개선에는 검사 억제와 추가 runtime 비용이라는 대가가 있다.
- Call stack-based suppression: 오류 검출 시 stack에 CMA 관련 함수가 있으면 보고를 억제하여, freed 객체에 저장된 내부 메타데이터 접근 등을 허용한다. 공용 함수를 통째로 검사에서 제외하는 ignore list보다 실행 문맥을 구분하지만 CMA 내부 버그도 가릴 수 있다.
- Call stack-based activation: 중첩된 CMA API에서는 가장 바깥 호출의 계측만 활성화한다. realloc 내부 alloc/free를 중복 처리하여 redzone을 거듭 늘리거나 DF를 잘못 보고하는 문제를 막는다.
- Size leakage avoidance: Size query API가 redzone을 포함한 확장 크기를 노출하지 않도록 원래 애플리케이션이 요청한 크기를 반환한다.
- Object-collecting API handling: GC 등 별도의 수거 API 호출 시 해당 quarantine을 비워, 수거된 객체를 나중에 다시 free하는 충돌을 피한다.
Result
비용
| 대상 | 실행시간 증가 | 메모리 증가 |
|---|---|---|
| 12개 애플리케이션 평균 | 9.63% | 14.83% |
| PHP | 21.76% | 7.85% |
| TensorFlow | 28.80% | 9.80% |
| ncnn | 22.44% | 99.09% |
| Redis | 9.50% | 33.46% |
오탐과 알려진 버그
네 가지 오탐 회피를 모두 끄면 12개 중 5개 애플리케이션에서 오탐이 발생했다. gRPC는 1,030개 workload 중 110개(10.68%), MicroPython은 922개 중 298개(32.32%)가 실패했고, Redis·PHP·TensorFlow는 테스트 전에 종료되었다. 기능을 활성화하면 이 평가의 오탐은 모두 제거되었다(Table 3). gRPC·PHP·RocksDB를 대상으로 한 추가 24시간 fuzzing에서도 오탐이 관측되지 않았다(Table 9).
신규 버그와 메커니즘의 효과
Table 5의 신규 버그는 7개 프로젝트에서 총 19건으로, BOF 11건과 UAF 8건이다. MicroPython 9건, qhull 2건, RapidJSON 3건, SQLite3 1건, PHP 2건, Taichi 1건, ncnn 1건이며, 평가 조건에서 ASan과 Goshawk는 이들을 검출하지 못했다.
Contribution
- 실제 CMA 사용 사례를 조사하여 Arena의 내부 객체 경계와 Recycler의 독립적인 객체 수명이 ASan의 주요 탐지 공백임을 설명했다.
- CMA를 표준 allocator로 대체하지 않고, API 계측과 별도 메타데이터로 CMA 객체의 공간·시간적 오류를 검사하는 sanitizer를 설계했다.
- Instance별 quarantine, clear용 allocation zone, 네 가지 오탐 회피로 CMA 특유의 수명 관리와 내부 접근을 처리했다.
- 12개 애플리케이션의 추가 비용·오탐 평가와 알려진 버그 10건 및 신규 버그 19건의 검출을 통해 실제 적용 가능성을 보였다.