우리는 사용자의 모든 비공개 Tor 신원을 연결하는 안정적인 Firefox 식별자를 발견했다

• indexedDB.databases()의 반환 순서만으로 Firefox 기반 브라우저에서 프로세스 수명 동안 유지되는 안정적 식별자 생성 가능
• 이 식별자는 origin 범위를 넘어서 공유되어, 관련 없는 사이트들도 같은 브라우저 런타임 안에서 동일한 값을 관측하며 cross-origin 추적에 활용 가능
• Firefox Private Browsing에서는 모든 프라이빗 창을 닫은 뒤에도 프로세스가 살아 있으면 식별자 유지되며, Tor Browser의 New Identity 이후에도 계속 남음
• 원인은 Gecko의 IndexedDB 구현에서 프라이빗 데이터베이스 이름을 UUID 기반 파일명으로 매핑하고, 그 결과를 정렬 없이 노출하는 동작에 있음
• Mozilla는 Firefox 150과 ESR 140.10.0에서 수정 배포했으며, 내부 저장소 순서를 외부에 드러내지 않는 설계가 프라이버시 보호에 중요함

---

취약점 개요

• 모든 Firefox 기반 브라우저에서 indexedDB.databases()가 반환하는 항목 순서를 통해 프로세스 수명 동안 유지되는 식별자 추출 가능
  • 웹사이트가 여러 IndexedDB 데이터베이스를 만든 뒤 반환 순서를 확인하면, 실행 중인 브라우저 프로세스의 고유하고 결정적인 식별자 생성 가능
  • 이 동작은 origin 범위가 아니라 프로세스 범위에서 나타나며, 서로 관련 없는 사이트도 같은 브라우저 런타임 안에서 동일한 식별자 관측 가능
• Firefox Private Browsing에서는 모든 프라이빗 창을 닫은 뒤에도 Firefox 프로세스가 계속 실행 중이면 식별자 유지
  • Tor Browser에서는 쿠키와 방문 기록을 지우고 새 Tor 회로를 사용하는 New Identity 이후에도 안정적 식별자 유지
  • 이후 브라우저 활동이 이전 활동과 연결되지 않아야 한다는 기대와 충돌하며, 사용자가 의존하는 비연결성 보장 약화
• Mozilla와 Tor Project에 책임 있는 공개 진행
  • Mozilla는 Firefox 150과 ESR 140.10.0에서 수정 배포
  • 패치는 Mozilla Bug 2024220에서 추적 중이며, 원인은 Gecko의 IndexedDB 구현에 있어 Tor Browser와 다른 Firefox 기반 브라우저에도 연관됨
• 수정 원리는 단순함
  • 브라우저가 프로세스 범위 내부 저장소 순서를 외부에 노출하지 않아야 함
  • 결과를 정규화하거나 정렬해 반환하면 엔트로피 제거와 안정적 식별자 악용 차단 가능

왜 중요한가

• 프라이빗 브라우징 모드와 개인정보 보호 중심 브라우저는 서로 다른 맥락에서 사용자를 식별하기 어렵게 만드는 목적 보유
  • 일반적 기대 1: 공유 저장소나 명시적 신원 메커니즘이 없는 한, 관련 없는 사이트가 같은 브라우저 인스턴스와 상호작용 중인지 알 수 없어야 함
  • 일반적 기대 2: 프라이빗 세션이 끝나면 해당 세션과 연결된 정보도 함께 사라져야 함
• 이번 동작은 두 기대를 모두 깨뜨림
  • 사이트는 쿠키, localStorage, 명시적 교차 사이트 채널 없이도 브라우저 내부 저장소 동작만으로 식별자 도출 가능
  • API가 반환하는 데이터베이스 이름 순서에서 고용량 식별 신호 획득 가능
• 개발자 관점의 교훈 존재
  • 개인정보 취약점은 식별 데이터에 대한 직접 접근에서만 발생하지 않음
  • 내부 구현 세부 사항이 결정적으로 노출될 때도 개인정보 누출 가능
• 보안 및 제품 관점의 핵심
  • 겉보기에는 무해한 API도 안정적인 프로세스 수준 상태를 누출하면 교차 사이트 추적 벡터로 전환 가능

IndexedDB와 indexedDB.databases()

• IndexedDB는 클라이언트 측 구조화 데이터 저장용 브라우저 API
  • 웹 애플리케이션이 오프라인 지원, 캐싱, 세션 상태, 기타 로컬 저장 목적으로 활용
  • 각 origin은 하나 이상의 이름 있는 데이터베이스를 만들 수 있으며, object store와 대용량 데이터 저장 가능
• indexedDB.databases()는 현재 origin에서 볼 수 있는 데이터베이스 메타데이터 반환
  • 개발자는 기존 데이터베이스 확인, 저장소 사용량 디버깅, 애플리케이션 상태 관리 등에 활용 가능
• 정상적인 개인정보 보호 기대 아래에서는 이 API의 반환 순서 자체가 식별 정보를 담아서는 안 됨
  • 중립적이거나 정규화된 형태의 데이터베이스 메타데이터 표현 필요
  • 실제 문제는 Firefox 기반 브라우저에서 반환 순서가 전혀 중립적이지 않았다는 점

indexedDB.databases()가 안정적 식별자가 된 방식

• Firefox Private Browsing에서 indexedDB.databases()는 데이터베이스 생성 순서가 아니라 내부 저장소 구조에서 파생된 순서로 메타데이터 반환
  • 관련 구현 위치는 dom/indexedDB/ActorsParent.cpp
• Private Browsing에서는 데이터베이스 이름을 디스크 식별자로 직접 사용하지 않음
  • 대신 전역 해시 테이블 StorageDatabaseNameHashtable = nsTHashMap<nsString, nsString>를 통해 UUID 기반 파일명 베이스로 매핑
  • 이 매핑은 OpenDatabaseOp::DoDatabaseWork() 내부 GetDatabaseFilenameBase()에서 수행
• aIsPrivate가 true일 때 사이트가 제공한 데이터베이스 이름은 생성된 UUID로 대체되어 전역 StorageDatabaseNameHashtable에 저장
  • 키는 데이터베이스 이름 문자열만 사용
  • IndexedDB QuotaClient 수명 동안 지속
  • 모든 origin 사이에서 공유
  • Firefox를 완전히 재시작할 때만 초기화
• 이후 indexedDB.databases() 호출 시 Firefox는 GetDatabasesOp::DoDatabaseWork()에서 QuotaClient::GetDatabaseFilenames(...)를 통해 데이터베이스 파일명 수집
  • 데이터베이스 베이스 이름은 nsTHashSet에 삽입
  • 반복 전에 어떠한 정렬도 수행하지 않음
• 최종 결과 순서는 해시 세트 내부 버킷 레이아웃 순회 결과로 결정
  • UUID 매핑이 Firefox 프로세스 수명 동안 안정적으로 유지되기 때문에, 반환 순서도 생성된 UUID 값, 해시 함수 동작, 해시 테이블 용량과 삽입 이력의 결정적 함수로 유지
  • 이 순서는 탭과 프라이빗 창을 가로질러 유지되며, 전체 Firefox 재시작 시에만 재설정
  • UUID 매핑과 해시 세트 순회 모두 origin 범위가 아니라 프로세스 범위

재현 방법

• 단순한 PoC만으로 동작 입증 가능
  • 서로 다른 두 origin이 동일한 스크립트 호스팅
  • 각 스크립트는 고정된 이름 집합의 데이터베이스 생성, indexedDB.databases() 호출, 반환 순서 추출 및 출력 수행
• 영향을 받는 Firefox Private Browsing과 Tor Browser 빌드에서 두 origin은 같은 브라우저 프로세스 수명 동안 동일한 순열 관측
  • 브라우저를 재시작하면 순열 변경
• 개념적 출력 예시 제시
  • 생성 순서: a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p
  • 반환 순서: g,c,p,a,l,f,n,d,j,b,o,h,e,m,i,k
• 핵심은 정확한 순서 자체가 아님
  • 원래 생성 순서와 다름
  • 관련 없는 origin들에서 같은 순서가 나타남
  • 새로고침, 새로운 프라이빗 창, 모든 프라이빗 창 종료 후에도 유지
  • 전체 브라우저 재시작에서만 새로운 순서 생성
  • 개인정보 보호 관점에서 원하지 않는 특성 직접 확인 가능

개인정보 영향

• 이 취약점은 하나의 브라우저 런타임 안에서 cross-origin 추적과 same-origin 추적 모두 가능하게 함

• cross-origin 영향

  • 관련 없는 웹사이트들이 같은 식별자를 독립적으로 도출해 동일한 실행 중 Firefox 또는 Tor Browser 프로세스와 상호작용 중임을 추론 가능
  • 쿠키나 다른 공유 저장소 없이도 도메인 간 활동 연결 가능

• same-origin 영향

  • Firefox Private Browsing에서는 Firefox 프로세스가 계속 실행 중이면 모든 프라이빗 창 종료 후에도 식별자 유지
  • 사이트가 겉보기에는 새로운 프라이빗 세션처럼 보이는 이후 방문을 다시 인식 가능
  • Tor Browser에서는 안정적 식별자가 실행 중 브라우저 프로세스 안에서 New Identity 격리를 사실상 무력화
  • 완전히 분리되어야 하는 세션들 사이의 연결 허용

• Tor Browser에서 특히 심각한 이유

  • Tor Browser는 교차 사이트 연결 가능성을 줄이고 브라우저 인스턴스 수준 식별을 최소화하도록 설계됨
  • 프로세스 수명 동안 유지되는 안정적 식별자는 이 설계 목표와 정면으로 충돌
  • 전체 프로세스 재시작 전까지만 살아남더라도 활발한 사용 중 비연결성 약화에 충분

엔트로피와 핑거프린팅 용량

• 이 신호는 안정적일 뿐 아니라 용량도 높음
  • 사이트가 N개의 데이터베이스 이름을 제어하면 관측 가능한 순열 수는 N!
  • 이론적 엔트로피는 log2(N!)
• 16개의 제어 가능한 이름이 있으면 이론적 공간은 약 44비트
  • 실제 환경의 동시 브라우저 인스턴스를 구분하기에 충분한 수준
• 내부 해시 테이블 동작 때문에 실제 도달 가능한 순열 수는 다소 낮을 수 있음
  • 그러나 보안 측면의 핵심은 바뀌지 않음
  • 노출된 순서는 여전히 강한 식별자로 작동하기에 충분한 엔트로피 제공

수정 방법

• 올바른 수정은 내부 저장소 레이아웃에서 파생된 엔트로피 노출 중단
  • 가장 깔끔한 완화책은 사전식 정렬 같은 정규 순서로 결과 반환
  • 개발자에게 API 유용성을 유지하면서 핑거프린팅 신호 제거 가능
• 호출마다 출력을 무작위화하는 방식도 안정적 순서 은닉 가능
  • 다만 정렬이 더 단순하고 예측 가능하며, 개발자가 이해하기 쉬운 선택지
• 보안 엔지니어링 관점의 이상적 수정 조건 명시
  • 개념적 복잡도 낮음
  • 호환성 위험 최소
  • 개인정보 누출 직접 제거

책임 있는 공개

• Mozilla와 Tor Project에 책임 있는 공개 진행
  • Mozilla는 Firefox 150과 ESR 140.10.0에서 수정 배포
  • 패치는 Mozilla Bug 2024220에서 추적 중
• 동작의 근원은 Gecko의 IndexedDB 구현
  • Tor Browser를 포함한 하위 Gecko 기반 브라우저도 자체 완화책이 없다면 영향권 포함

프라이버시 중심 설계

• 작은 구현 세부 사항도 의미 있는 개인정보 문제로 이어질 수 있음
  • 관련 없는 웹사이트가 같은 브라우저 런타임 동안 origin을 넘어서 활동 연결 가능
  • 식별자가 사용자 기대보다 오래 살아남아 프라이빗 세션 경계 약화
• 긍정적 요소는 수정이 단순하고 효과적이라는 점
  • 반환 전에 출력을 정규화하면 이 엔트로피 원천 제거 가능
  • 기대된 개인정보 경계 복원 가능
• 놓치기 쉽지만 영향이 크고, 프라이버시 민감 기능을 만드는 과정에서 주의할 가치가 큰 유형의 취약점

[GN⁺]

Hacker News 의견들

• 이 연구가 정말 인상적이고 글도 아주 잘 쓰였다고 느낌
  끝에 제품 광고가 나올 줄 알았는데 없어서 오히려 놀라움
  다만 이 회사 제품이 핑거프린팅을 한다면 왜 이 취약점을 Mozilla에 제보했는지는 궁금함
  비윤리적이더라도 경쟁사와 차별화하려면 비공개로 들고 있는 편이 사업적으로 더 낫지 않나 싶음
  위협 행위자들이 책임 있는 공개로 자기들 zero-day를 태우는 경우는 거의 못 봄

  • 나는 우리 제품에서 취약점을 사용하지 않음
  • 내 생각엔 애초에 그 취약점에 의존하지 않았고, 공개해버리면 다른 쪽도 못 쓰게 된다는 점이 중요함

• 기사에 나온 대로 식별자가 Firefox 프로세스가 살아 있는 동안 유지될 수 있으니, Tor Browser는 세션이 끝나면 꼭 완전히 종료해야 함
  한 세션 안에서 서로 다른 용도를 섞어 쓰지 않는 것도 중요함

• OP가 건 링크는 내 Tor 환경에서 타임아웃이 났지만, Wayback 버전은 문제없이 열렸음
  그리고 이 주제를 다루는 학계 연구자가 있는지도 궁금함
  EFF 같은 단체의 활동은 알고 있지만, 나는 NGO 활동가보다는 대학 교수나 MSR, PARC 같은 순수 연구소 쪽을 더 찾고 있음
  프라이버시에 관심이 많은 입장에서 noscript, ublock origin, firefox containers라는 개인적 holy trinity로 보안은 꽤 챙길 수 있어도, 익명성은 핑거프린팅 때문에 자꾸 손가락 사이로 빠져나가는 느낌임
  stylometry까지 넓게 핑거프린팅으로 보면 더 그렇다고 봄

  • 웹 fingerprint는 공격과 방어 양쪽 모두에서 활발히 연구되는 분야임
    예시로 PETS 같은 학회를 찾아보면 도움 됨

• 나는 웹사이트가 이런 정보를 사용자에게 묻거나 알리지도 않고 접근할 수 있다는 점 자체가 의문임
  왜 브라우저는 휴대폰처럼 서버나 앱이 이런 정보에 접근할 때 권한 허용을 받도록 만들지 않는지 궁금함

  • 브라우저 핑거프린팅은 브라우저가 제공하는 기능들의 부작용에 가깝다고 봄
    브라우저 버전을 알려주는 user agent도 그럭저럭 합리적이고, 시스템에 어떤 폰트가 있는지 묻는 기능도 글꼴 지원상 완전히 없애기 어려움
    시간대, 언어, 키보드 레이아웃, 화면 크기, 창 크기 역시 정상적인 웹 동작에 필요함
    비디오나 오디오 플레이어가 어떤 포맷을 지원하는지 알아야 적절한 미디어를 줄 수 있는 것도 당연함
    JavaScript가 시간을 읽을 수 있는 이상 서버 시간과 비교해 시스템 시계 오차를 알아내는 것도 쉬움
    이렇게 하나씩 쌓이다 보면 거의 모든 브라우저가 결국 고유하게 식별됨
  • 가장 많이 쓰는 브라우저를 만드는 곳이 광고 회사임
    게다가 그 회사가 최대 경쟁자의 자금도 상당 부분 댐
    그러니 이런 현실이 놀랍지 않다고 봄
  • 그래도 앱보다는 낫다고 느낌
    앱은 식별자와 디바이스 특성에 훨씬 더 많이 접근할 수 있음
    Google Play services가 없는 비교적 잘 보호된 시스템에서도 그렇다고 봄
  • 그 말은 Android 같은 폰을 떠올리게 함
    오히려 Apple 쪽은 세밀한 제어가 거의 없어서 아쉽다고 느낌
  • 웹 사용성을 유지하는 것과 핑거프린팅을 막는 것, 그리고 사용자에게 수십 수백 개의 권한 팝업을 뿌리지 않는 것 사이엔 아주 미묘한 선이 있다고 봄
    브라우저가 이미 OS에 맞먹는 복잡도를 가지는 만큼 시스템의 어느 부분이든 의도치 않게 노출되고 악용될 수 있음

• 글에 나온 process-scoped라는 표현이 조금 헷갈렸음
  Mozilla가 2021년에 Firefox용 실험적 one-process-per-site를 공개하면서, 데스크톱 Firefox에서 모든 사이트 사이에 운영체제 프로세스 수준 경계를 만든다고 설명했던 것으로 기억함
  관련 글은 Introducing Site Isolation in Firefox임
  그래서 이 기능이 아직 완전히 배포되지 않은 건지, 아니면 배포는 됐지만 IndexedDB가 그 격리 바깥에 있는 건지 궁금함

  • 이 댓글을 보고 나서야, 일부 전역 동작이 남아 있어서 그 틈으로 핑거프린팅이 가능하다는 뜻으로 이해하게 됨
    그렇다면 꽤 흥미로운 설명이라고 느낌

• 이 설명대로라면 브라우저를 재시작하면 유지되지 않는 것처럼 들리는데, 그렇다면 공격자 입장에서는 유용성이 꽤 줄어들지 않나 싶음

  • 기사에서 인용한 이 부분이 위험을 잘 설명해준다고 느낌
    Firefox Private Browsing에서는 모든 사설 창을 닫아도 Firefox 프로세스가 계속 살아 있으면 식별자가 유지될 수 있음
    Tor Browser에서는 쿠키와 방문 기록을 지우고 새 Tor 회선을 쓰는 완전 초기화를 의도한 New Identity를 써도 안정적인 식별자가 유지된다고 이해함
  • 이런 상황에서 쓰는 방식이 id bridging임
    먼저 웹사이트가 브라우저를 핑거프린팅하고 쿠키에 ID와 핑거프린트를 저장함
    다음 세션에서 다시 핑거프린팅해 쿠키와 비교하고, 값이 바뀌었으면 예전 핑거프린트와 새 핑거프린트를 서버에 함께 알려 연결하는 방식임
  • 많은 사용자는 브라우저를 몇 달씩 켜둔 채로 사용함
  • 정말 유용성이 크게 줄어드느냐는 의문이 있음
    국가기관은 이미 많은 노드를 알거나 추적할 수 있을 가능성이 있고, 여러 메타정보를 교차 연결하면 사람을 꽤 정확히 식별할 수 있다고 봄
    항상 100퍼센트 정확할 필요도 없고, 주변 지역 정보나 벽 너머에서 얻는 정보처럼 대상 자체 외의 간접 정보만 많이 모아도 된다는 생각임
    나는 이런 걸 일종의 proxy 정보로 식별하는 방식으로 느낌

• 솔직히 말해 Web Standards의 상당수는 실제 기능보다 핑거프린팅에 더 많이 쓰이는 것처럼 보임
  IndexedDB도 실제 저장 용도로 쓰는 사이트는 소수 같고, 누가 그걸 꼭 필요로 하나 싶음
  그래서 웹 표준을 계속 확장하는 방향 자체가 잘못됐다고 봄
  브라우저는 기기와 상호작용하는 최소한의 API만 제공하고, IndexedDB 같은 기능은 가치 있는 데이터를 새지 않게 하는 WebAssembly 라이브러리로 구현할 수도 있다고 생각함
  예를 들어 canvas가 플랫폼별 라이브러리를 호출하는 그리기 루틴 없이 그림 버퍼 접근만 제공했다면 핑거프린팅 가치가 크게 줄었을 것이라고 봄

  • "Local Storage Editor" 같은 브라우저 확장을 쓰면 사이트의 Local Storage 내용을 직접 볼 수 있음
    내가 지금까지 본 사례로는 gmail 같은 곳에서 오래가는 이미지를 캐시하거나, 쿠키 대신 로그인 상태를 유지하는 다른 방식으로 쓰는 경우가 있었음

• 나는 여기서 좀 헷갈렸음
  IndexedDB의 UUID가 모든 origin에 공유된다면, 순서가 아니라 데이터베이스 내용 자체로 브라우저를 식별하면 되지 않나 싶었음

  • 페이지에 이해하기 쉬운 예시가 있음
    어떤 페이지가 a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p라는 데이터베이스들을 만들고 순서를 조회하면, 전역적인 이름-UUID 매핑에 따라 예를 들어 g,c,p,a,l,f,n,d,j,b,o,h,e,m,i,k 같은 결과를 얻을 수 있음
    핵심 취약점은 Firefox 프로세스가 살아 있는 동안은 어떤 웹사이트가 같은 이름 집합의 데이터베이스를 만들더라도, 내용과 무관하게 정확히 같은 순서를 보게 된다는 점임
    그래서 이건 시간에 걸쳐 유지되는 안정적이고 엔트로피가 높은 식별자, 즉 fingerprint가 됨
    origin을 넘어 공유되고, 사이트 데이터를 삭제한 뒤에도 같은 이름으로 다시 만들기만 하면 순서를 통해 핑거프린트를 재획득할 수 있음
  • 데이터 내용은 당연히 origin 범위로 제한된다고 봄
    그렇지 않으면 IndexedDB는 너무 쉬운 evercookie가 됐을 것임
  • 브라우저에서 origin을 넘어 공유되는 건 데이터베이스 내용이 아니라 UUID 매핑임
    각 origin에는 그 origin과 연결된 데이터베이스 하위집합만 노출된다고 이해함

• Tor Browser가 아직도 기본으로 JavaScript를 허용하는지 궁금했음
  내가 이해한 바로는 JavaScript 실행을 막으면 이 취약점 영향도 받지 않을 것 같음

  • 실제로는 JavaScript를 끄면 핑거프린트가 크게 더 눈에 띄게 됨
    JS를 끄는 사용자가 많지 않아서 곧바로 훨씬 작은 집단으로 들어가고, 그 안에서 고유해지기 쉬워짐
    물론 JS가 없으면 세부 정보를 수집하는 선택지는 줄어들지만, 그만큼 적은 정보로도 구별되기 쉬워짐
    게다가 Tor Browser는 이상하게도 navigator.platform을 전혀 spoof하지 않아서 User-Agent가 Windows로 위장돼도 사이트는 여전히 Linux 사용 여부를 볼 수 있음