Why — 왜 베이스밴드가 위험한가
셀룰러 모뎀은 스마트폰 안에서 가장 신뢰할 수 없는 입력을 받아들이는 부품이다. 기지국·이동통신망·상대 단말이 보내는 패킷은 사용자 개입 없이 자동으로 처리되고, 처리 실패가 곧 커널 이하 계층에서 임의 코드 실행으로 이어질 수 있다. 셀룰러 통신이 데이터 네트워크로 완전히 이관되면서 이 위험은 커졌다.
Google Pixel 팀의 Jiacheng Lu가 공식 블로그에 밝힌 표현으로는, 콜 포워딩 같은 기본 동작조차 DNS 서비스에 의존한다. DNS는 프로토콜 자체가 복잡하고, 파싱 대상이 늘 외부에서 오는 신뢰할 수 없는 데이터라 메모리 비안전 언어로 구현되면 취약점을 만들기 쉬운 표면이다.
Project Zero는 이전에 Pixel 모뎀에서 원격 코드 실행에 성공한 이력이 있다. 모뎀 코드는 수십 메가바이트 규모의 실행 파일이고, 그 안에는 아직 드러나지 않은 메모리 안전성 결함이 남아 있을 가능성이 크다는 것이 Google의 판단이다.
What — Pixel 10에 실제로 들어간 것
Pixel 10 시리즈는 셀룰러 모뎀에 메모리 안전 언어를 최초로 통합한 Pixel이다. 통합된 것은 완전한 모뎀 재작성이 아니라 DNS 파서 한 부품이다. Google이 선택한 라이브러리는 오픈소스 크레이트 hickory-proto, Rust 커뮤니티에서 널리 쓰이고 있고 테스트 커버리지 75% 이상을 확보한 프로젝트다.
왜 DNS부터인가
DNS 파서는 위험도와 도입 부담이 맞물리는 첫 진입점이다.
| 관점 | 판단 |
|---|
| 위험도 | 외부 입력 파싱 · 프로토콜 복잡 · 과거 취약점 다수 |
| 격리 난이도 | 단일 컴포넌트 · 인터페이스 명확 |
| 대체 라이브러리 존재 | hickory-proto 이미 성숙 |
| 성능 요구 | 파싱은 초당 몇 회 수준 · 오버헤드 여유 |
이 조건에 맞는 다른 컴포넌트가 후속 대상이 된다. Google은 이번 통합을 "메모리 안전 파서와 코드를 셀룰러 베이스밴드에 확장할 기반" 이라고 못 박았다.
How — no_std Rust를 펌웨어에 넣는 과정
일반적인 Rust 코드는 std 크레이트에 의존한다. 힙 할당·파일 I/O·스레드 등 운영체제가 제공하는 서비스를 전제로 만들어졌기 때문이다. 하지만 모뎀 펌웨어는 bare-metal 환경이다. 커널이 없고, malloc/free조차 자체 구현이거나 정적 할당 기반이다.
Google 팀은 hickory-proto와 그 의존성에 no_std 지원을 추가했다. 이 작업은 라이브러리 코드 자체 수정과 Google 쪽 shim 레이어 작성을 병행한 결과다.
371KB의 내역
Google 자신도 "다른 임베디드 시스템에는 이 크기가 도입 장애가 될 수 있다" 고 인정했다. 즉 모뎀에는 여유가 있었지만, 더 제약이 심한 IoT 장비에서는 같은 접근이 어렵다.
발견된 회귀
통합 중 성능 관련 회귀가 하나 관측됐다. Rust의 compiler_builtin이 제공하는 weak symbol이 모뎀에 미리 존재하던 최적화된 memset·memcpy 구현을 덮어썼다. 그 결과 파싱은 정상 동작했지만 특정 경로에서 속도가 떨어졌다. Google 팀은 빌드 후처리로 해당 심볼을 제거해 모뎀 최적화 구현이 그대로 유지되도록 했다.
Security — 이 조치가 실제로 무엇을 막나
메모리 안전 언어 도입의 핵심 효과는 취약점 계열 자체를 제거하는 데 있다.
봉쇄되는 취약점 계열
- 버퍼 오버플로 (스택·힙)
- Use-after-free
- 이중 해제 (double free)
- 언초기화 메모리 참조
- 정수 오버플로에 이은 잘못된 인덱싱
이 계열은 DNS 파서 같은 프로토콜 코드에서 반복적으로 등장했다. Rust의 소유권 모델과 컴파일러 검사는 개별 실수가 아니라 위 유형 전체를 컴파일 시점에 차단한다.
남는 위험
- 로직 오류 (파서가 잘못된 상태 전이를 허용)
- 다른 부분에 남아 있는 C/C++ 코드 (모뎀 대부분은 여전히 메모리 비안전)
- 사이드채널·시간 공격
- 하드웨어 취약점
즉 이번 도입은 DNS 파서 하나에 한정된 부분 방어다. 모뎀 전체가 안전해진 것이 아니다.
탐지 관점
베이스밴드 취약점은 사용자·SOC 관측이 어렵다. 커널 이하에서 발생하므로 EDR도 무력하다. 실무에서 참고할 지점은 다음이다.
- 모뎀 펌웨어 버전 관리: 벤더 보안 업데이트가 나오는 시점을 추적. Pixel 10 사용자는 이번 개선을 자동 반영, 이전 세대는 여전히 C 기반 파서
- 비정상 통신 로그: 셀 전환·DNS 응답 실패·특정 시각 반복 오류가 모뎀 익스플로잇 시도 신호일 수 있으나, 확정 판정은 벤더 telemetry 필요
- Project Zero·CERT 자문: 베이스밴드 취약점은 공개 지연이 길다. 벤더 advisory와 Project Zero 리서치의 시차를 좁혀 관찰하면 실무 판정 창이 나온다
Summary — 세 줄
- Pixel 10 = 첫 Rust 모뎀 통합. DNS 파서 371KB로 시작
- hickory-proto를 no_std로 이식. compiler_builtin symbol 충돌은 빌드 후처리로 해결
- 부분 방어. DNS 파서 계열 취약점은 봉쇄됐지만 모뎀 나머지·로직 오류는 별개
한국 관점
Samsung Exynos·MediaTek·Qualcomm 모뎀을 쓰는 국내 단말은 이번 조치의 직접 대상이 아니다. 다만 Google이 공개한 이식 절차와 371KB 실측 크기 자체가 다른 벤더의 참고 자료가 된다.
국내 3사가 2024~2025년 5G SA(Standalone) 상용화를 이어가면서 모뎀이 처리하는 프로토콜 표면이 넓어졌고, 그만큼 파서 계층 취약점의 파급 범위도 커졌다. 벤더가 유사한 부분 개선을 언제 도입하는지가 국내 단말 사용자와 통신 보안 담당자에게 참고할 만한 지표로 남는다.
임베디드·IoT 진영에서는 371KB가 실제 부담이라는 Google의 발언이 그대로 적용된다.
참고 자료
관련 글 더 보기
안내 및 법적 고지
AI 활용 안내
이 글은 AI(Claude)의 도움을 받아 작성되었습니다.
인용된 통계와 사례는 참고 자료에 명시된 출처에 근거하며, 설명을 위한 일부 표현은 각색되었습니다.
면책 조항
본 글은 보안 인식 제고를 위한 교육 목적으로 작성되었습니다.
언급된 공격 기법을 실제로 시도하는 행위는 「정보통신망법」, 「형법」 등에 따라
처벌받을 수 있으며, 본 블로그는 이에 대한 법적 책임을 지지 않습니다.