Don't register WebM / MSE-AVF media players for GPU-process playback under MediaContainment
WebKit은 미디어 처리를 세 계층으로 분리합니다. WebContent process(JS, demuxing), GPU process(decoding, rendering), WebContent 측 remote proxy(MediaPlayerPrivateRemote)가 각각의 역할을 맡습니다. MediaContainment가 활성화된 상태에서는 WebM과 MSE-AVF 엔진이 WebContent에서 demux를 수행하고, renderer만 GPU process에서 실행됩니다. 이런 구조에서 GPU에 MediaPlayerPrivate 전체를 인스턴스화하는 것은 불필요한 데다, defense-in-depth 관점에서도 취약점으로 남게 됩니다. 이전에는 createMediaPlayer 내부의 단일 MESSAGE_CHECK가 이러한 인스턴스화를 명시적으로 차단하는 IPC guard 역할을 했습니다. 다만 codec 지원 여부를 조회하는 canDecodeExtendedType은 같은 engine registry를 공유하고 있었습니다. "쿼리에 응답 가능한 엔진"과 "재생을 위해 인스턴스화 가능한 엔진"을 구분할 방법이 없었던 것입니다.
Source/WebCore/platform/graphics/MediaPlayerEnums.h
Source/WebKit/GPUProcess/media/RemoteMediaPlayerManagerProxy.cpp
이 commit은 수동으로 관리되던 allowlist를 registry 기반의 scope 필터링으로 대체했습니다. 각 MediaPlayerPrivate는 이제 자체적으로 MediaPlayerScope(Playback 또는 Supports)를 선언합니다. 새로 추가된 playbackEngineForConnection 헬퍼는 scope와 MediaContainmentEnabled 상태를 함께 고려해 GPU process의 engine 조회를 필터링합니다. 결과적으로 MediaContainment가 활성화된 상태에서는 WebM과 MSE-AVF 엔진이 GPU 재생용으로 인스턴스화되지 않으면서도, codec 쿼리에는 계속 응답할 수 있습니다.
Significance
이 변경은 GPU process의 권한 경계 자체를 재구성합니다. 명시적 MESSAGE_CHECK IPC guard는 제거되었고, 모든 호출 지점에서 올바르게 준수되어야 하는 암묵적 registry 계약으로 대체되었습니다. 이로 인해 공격 표면은 더 넓고 파악하기 까다로운 형태로 바뀌었습니다.
Audit directions
MediaContainmentEnabled 값은 connection에 저장된 preference에서 가져옵니다. 이 값이 WebContent와 GPU 사이에서 일관되지 않게 설정되거나 읽히는 경우, scope 필터링은 잘못된 결과를 조용히 반환하게 됩니다. connection 설정 중 TOCTOU가 발생하거나, engine 등록 이후 containment 상태가 변경되는 경우가 이에 해당합니다.
playbackEngineForConnection은 현재 GPU 측의 모든 재생 engine 조회를 처리하는 유일한 지점입니다. 이 함수를 우회하거나 잘못된 scope로 조회하는 호출 지점이 있다면, 기존 MESSAGE_CHECK의 보호가 완전히 사라지게 됩니다. getSupportedTypes, supportsTypeAndCodecs, supportsKeySystem이 모두 이 경로를 거치는지 살펴봐야 합니다.
canDecodeExtendedType은 이제 Supports scope로 쿼리를 수행합니다. GPU에서 codec 쿼리에는 응답하면서 인스턴스화는 제한된 engine이 fuzz 가능한 code path를 노출할 가능성이 있습니다.
마지막으로 MockMSE 등록 분기의 조건 로직이 변경되었습니다. mock 모드에서 production 모드가 금지하는 engine을 GPU에 등록하지 않는지 확인해야 합니다.