▲

Rust를 대규모 서비스에서 사용하기: WhatsApp을 위한 추가 보안 계층

 (engineering.fb.com)
6P by GN⁺ 19시간전 | ★ favorite | 댓글 1개
  • 30억명 이상의 사용자를 가진 WhatsApp이 Rust 기반 보안 계층을 도입해 악성코드 위협에 대한 방어력을 강화함
  • 미디어 일관성 라이브러리를 Rust로 재작성해 수십억 대의 기기와 브라우저에 배포, 글로벌 규모의 실사용 검증을 완료
  • 기존 C++ 코드 16만 줄을 Rust 9만 줄로 대체하며 성능과 메모리 효율 모두 개선됨
  • 2015년 Stagefright 취약점 이후 미디어 파일 처리 과정의 안전성을 높이기 위해 Rust같은 메모리 안전 언어 도입을 추진해왔음
  • 이 변화는 WhatsApp·Messenger·Instagram 전반의 보안 전략에서 메모리 안전 언어의 비중을 확대하는 전환점

WhatsApp의 미디어 처리 전략

  • WhatsApp은 30억 명 이상이 사용하는 종단간 암호화 메시징 서비스로, 지속적인 보안 위협 대응을 위해 전략을 발전시켜 옴
    • 사용자가 이미지·영상 등 미디어를 공유할 때 악성코드가 포함될 가능성이 존재
    • 일부 파일은 운영체제나 앱의 패치되지 않은 취약점을 악용할 수 있음
  • 이를 방지하기 위해 Rust 언어를 미디어 공유 기능에 도입, 메모리 안전성을 확보함
    • 이는 전 세계적으로 가장 큰 규모의 Rust 기반 라이브러리 배포 사례로 언급됨

2015년 Android Stagefright 취약점과 대응

  • 2015년 Android의 Stagefright 취약점은 OS 수준의 미디어 처리 라이브러리에 존재해 앱 차원에서 수정이 불가능했음
  • WhatsApp은 자체 C++ 라이브러리 “wamedia” 를 수정해 MP4 표준을 따르지 않는 파일을 탐지하도록 개선
    • 이를 통해 OS 업데이트 없이도 사용자 보호 가능
  • 그러나 wamedia가 신뢰할 수 없는 입력을 자동 처리한다는 점에서, 메모리 안전 언어로의 전환 필요성이 제기됨

Rust로의 전환: 대규모 재작성과 성과

  • WhatsApp은 기존 C++ 버전과 병행해 Rust 버전의 wamedia를 개발
    • 차등 퍼징(differential fuzzing) , 통합 테스트, 단위 테스트로 두 구현 간 호환성을 검증
  • 초기에는 Rust 표준 라이브러리로 인한 바이너리 크기 증가와 빌드 시스템 호환성 문제가 있었으나 장기적 지원 체계를 구축
  • 결과적으로 C++ 16만 줄 → Rust 9만 줄로 대체, 성능과 메모리 사용 효율 모두 개선
  • Android, iOS, Mac, Web, 웨어러블 등 모든 플랫폼에 Rust 버전 완전 배포 완료
  • 이후 “Kaleidoscope” 시스템을 도입해 PDF, 실행 파일 등 위험 파일 유형을 탐지하고, 확장자 위조나 MIME 스푸핑을 식별함

WhatsApp의 보안 접근 방식

  • WhatsApp은 종단간 암호화, 암호화된 백업, 키 투명성, 통화 보호 기능 등 다양한 보안 계층을 운영
  • CVE 공개, 내·외부 보안 감사, 퍼징 및 정적 분석, 공급망 관리, 공격면 분석을 통해 위험을 식별
  • Bug Bounty 프로그램을 확장해 연구자들이 WhatsApp 네트워크 프로토콜을 분석할 수 있는 Research Proxy를 제공
  • 주요 취약점의 다수가 C/C++ 메모리 안전 문제에서 비롯됨을 확인하고, 세 가지 전략을 병행함
    1. 불필요한 공격면 최소화
    2. 남은 C/C++ 코드의 보안 보증 강화
    3. 신규 코드의 기본 언어를 메모리 안전 언어로 전환

Rust 도입 가속화와 향후 방향

  • Rust는 WhatsApp의 고성능·크로스플랫폼 보안 라이브러리 개발을 가능하게 함
  • 이 변화는 사용자에게 보이지 않는 추가 보안 계층을 제공하며, 심층 방어(defense-in-depth) 전략의 일환
  • WhatsApp과 Meta의 보안팀은 Rust의 고효과 적용 영역을 확대 중이며, 향후 Rust 채택을 가속화할 계획
▲
GN⁺ 19시간전  [-]
Hacker News 의견들

  • WhatsApp은 하루 30억 명이 사용하는 메신저임
    미국에서는 잘 안 쓰이지만, 전 세계적으로는 기본적인 커뮤니케이션 인프라로 자리 잡았음
    글로벌 시장을 대상으로 제품을 만들고 싶다면, 이 사용자들의 사고방식과 습관을 이해해야 함

    • 유럽인으로서 나는 여전히 WhatsApp 설치를 거부하고 있음
      이런 독립적인 사람들이 아직 수십 명은 있음
      제발 WhatsApp을 더 피할 수 없게 만드는 일에는 참여하지 말았으면 함
    • 내가 사는 말라위에서는 WhatsApp이 이메일보다 훨씬 더 널리 쓰임
      대부분의 사람들은 이메일을 거의 확인하지 않음
      개발자 커뮤니티를 운영하는데, 그룹 인원 제한(1024명)에 자주 걸림
      Discord나 Slack으로 옮기려 해도 결국 다시 WhatsApp으로 돌아오게 됨
      통신사 데이터 번들 덕분에 WhatsApp이 사실상 무료이기 때문임
    • WhatsApp이 자리 잡은 시장에서는 이미 광고와 스팸이 늘어나며 품질이 떨어지고 있음
      기업 메시지 스팸 관련 기사들이 TechCrunch에 여러 번 실렸지만, 실제로는 거의 변한 게 없음
      커뮤니티 기능의 UX도 별로임
      결국 Facebook 생태계 종속이 심화되는 게 문제라고 생각함
    • 솔직히 30억 명이라는 수치는 과장된 것 같음
      나는 10년째 WhatsApp을 안 쓰고, 내 친구나 가족도 대부분 Signal로 옮겼음
      유럽에서는 여전히 Viber가 쓰이는 지역도 있음
    • 북미나 유럽 사용자 중 실제로 수익을 내는 사람은 2억 명 정도일 것 같음

  • Rust로 작성된 라이브러리 중 가장 큰 규모의 배포라고 했지만, 실제로는 Fontations가 더 클 수도 있음
    Chromium에 포함되어 있고, 그 의존성까지 보면 설치 기반이 더 넓을 가능성이 있음
    인용문을 보면 WhatsApp은 libsignal을 직접 사용하지 않은 듯함

    • 참고로 Wamedia는 Meta 주요 앱들에 포함되어 iOS, Android, Desktop, Web 전반에 배포됨
    • Chromium에는 이미 여러 Rust 라이브러리가 포함되어 있음
      예: image-png, CrabbyAvif, qr_code, icu4x

  • 코드가 16만 줄에서 9만 줄로 줄어든 것도 좋지만, 병렬 롤아웃 전략이 더 흥미로움
    Rust와 C++ 버전을 동시에 돌리며 differential fuzzing으로 동등성을 검증한 점이 현실적임
    모바일 클라이언트에서는 바이너리 크기가 중요한데, 빌드 툴링에 투자한 점이 인상적임

    • 혹시 no_std를 썼거나 표준 라이브러리를 재구성했는지 궁금함
      nightly 빌드에서만 가능한 최적화일 수도 있음

  • 이런 리라이트에서 가장 어려운 부분은 Rust 구현 자체보다 기존 파서의 버그 호환성 유지임
    실제 미디어 파일은 형식이 잘못된 경우가 많아, 너무 엄격하게 파싱하면 사용자 데이터가 깨짐
    differential fuzzing이 사실상 유일한 실용적 접근법임

    • Wamedia는 일부러 버그 호환성 유지를 목표로 하지 않은 설계로 보임
    • 이건 혹시 AI가 쓴 댓글 같다는 생각이 듦

  • WhatsApp이 Rust로 가장 큰 배포를 했다는 말은, Windows 11보다 많은 기기에서 돌아가기 때문일 것임
    다만 WhatsApp이 libsignal을 직접 쓰는지는 의문임

    • WhatsApp은 libsignal을 쓰지 않음
      Android 자체가 이미 Rust 기반 코드를 많이 포함하고 있고, 임베디드 기기에서도 광범위하게 사용됨
    • Microsoft is Getting Rusty 영상을 보면, Rust 도입은 주로 Azure 쪽에서 진행 중이고
      Windows는 여전히 C/C++ 중심임

  • Rust 표준 라이브러리 도입으로 바이너리 크기 증가가 있었다고 하는데, 어떻게 해결했는지는 명시되지 않음

    • 아마도 가능한 곳에서는 no_std를 사용했을 것 같음
      관련 커밋: commit1, commit2
    • 약 300KB 정도의 오버헤드는 감수했을 가능성이 큼
      문제는 크기 자체보다 중복된 Rust 의존성임
      C++과 Rust가 섞인 빌드에서는 각자 libstd를 포함하므로, Bazel 같은 통합 빌드 시스템이 필요함
    • 실제로는 빌드 시스템 최적화에 많은 투자를 했음
      초기에는 약 200KiB 오버헤드를 감수했지만, Buck2 전환으로 크기와 빌드 시간을 모두 줄였음
      최신 clang 최적화와 LTO 개선 덕분임
    • 참고용으로 min-sized-rust 같은 접근도 있음
    • 전체적으로 기술적 세부보다는 PR 성격이 강한 글로 느껴졌음

  • Signal도 비슷한 시도를 하는지 궁금함
    libsignal은 Rust로 구현되어 있지만, 나머지 부분은 잘 모르겠음

  • “30억 명에게 기본적으로 종단 간 암호화를 제공한다”는 문구가 있었는데, 실제로는 메시지를 읽을 수 있다는 뉴스도 있었음

    • “기본(default)”이라는 단어가 핵심일 듯함
      Skype도 기본적으로는 암호화되지만, 서버 설정에 따라 해제될 수 있었음
    • 모든 암호화는 결국 누가 끝단인지에 따라 달라짐
      Meta가 데이터를 엿보지 않는다고 신뢰할 수 있느냐가 문제임

  • Meta는 피싱이나 선불 카드 사기는 막지 않으면서, 다른 일엔 열심인 게 아이러니함

  • Rust 도입으로 버그가 많이 줄었다는 점이 인상적임

    • Rust의 안정성은 단순히 메모리 오류 방지 때문만이 아님
      C++에는 수많은 정의되지 않은 동작(UB) 이 존재하지만, Rust는 이를 구조적으로 차단함
      강력한 타입 시스템 덕분에 신뢰성이 크게 향상됨
답변달기