[17] SpeechRecognition ASSERT instead of MESSAGE_CHECK for duplicate client

Severity: Medium | Component: WebKit UIProcess | 5db4d93

IPC로 공급된 identifier에 걸린 assertion이 release 빌드에서 제거되는 문제를 MESSAGE_CHECK로 교체하여 해결합니다. 패치 이전 release 빌드에서는 충돌 시 HashMap::add가 기존 항목을 반환하면서 attacker가 공급한 파라미터가 무시됩니다. 이로 인해 requestPermissionForRequest가 잘못된 origin context를 대상으로 실행되는 상태 divergence가 조용히 발생합니다.

SpeechRecognitionServer::start는 identifier 고유성을 ASSERT로 검증했으나, 이 코드는 release 빌드에서 제거됩니다. m_requests.add는 insert-if-absent 방식으로 동작합니다. 충돌이 발생하면 기존 항목이 반환되면서 attacker가 공급한 lang, continuous, origin, mainFrameIdentifier 등이 모두 무시됩니다.

Source/WebKit/UIProcess/SpeechRecognitionServer.cpp

Release 빌드에서도 반드시 유지되어야 하는 attacker 제어 IPC invariant에 debug-only ASSERT가 사용된 패턴.

Web Speech Recognition API는 마이크 기반의 speech-to-text 기능을 web content에 제공합니다. 접근은 origin별 권한 요청을 통해 제어됩니다. SpeechRecognitionServer는 UIProcess에서 실행되며, m_requests는 SpeechRecognitionConnectionClientIdentifier를 key로 사용하는 HashMap입니다.

침해된 renderer는 이미 존재하는 clientIdentifier를 다시 전송할 수 있습니다. 이 경우 m_requests.add가 기존 항목을 조용히 반환합니다. requestPermissionForRequest는 새로 공급된 값 대신 stale한 (origin, frameIdentifier) tuple을 기반으로 실행됩니다. 결과적으로 더 높은 권한을 가진 UI process의 privacy에 민감한 code path에서 논리적 혼란이 발생합니다.

이 vulnerability는 speech recognition에 대한 WebContent→UIProcess IPC 신뢰 경계를 약화시킵니다. MESSAGE_CHECK가 필요한 위치에 ASSERT를 사용하는 패턴은 WebKit에서 반복적으로 등장하는 취약점 유형입니다.

Audit directions

• ASSERT(...) on attacker-controlled IPC fields. Source/WebKit/UIProcess/와 NetworkProcess/에서 handler 파라미터로부터 파생된 인자를 사용하는 ASSERT(를 검색합니다. 특히 ASSERT(!.*contains.*identifier 패턴 뒤에 m_*.add(가 이어지는 경우를 중점적으로 확인합니다.
• HashMap::add after ASSERT(!map.contains(id)). ASSERT가 컴파일 시 제거되면 조용한 상태 혼란이 발생하는 지점입니다.
• Privacy-sensitive permission flows keyed by renderer-supplied identifiers. SpeechRecognitionServer::start, UserMediaProcessManager, WebPageProxy media-permission 진입점에서 (clientIdentifier, origin, frameIdentifier) tuple이 여러 요청 간에 혼용되지 않는지 확인합니다.