Validate identifiers when creating decoders and encoders in LibWebRTCCodecsProxy

Component: WebKit GPU Process WebRTC | 2feb5ed

Source/WebKit/GPUProcess/webrtc/LibWebRTCCodecsProxy.mm

LibWebRTCCodecsProxy는 GPU 프로세스에서 실행되며, 상대적으로 신뢰도가 낮은 WebProcess를 대신해 하드웨어 기반 WebRTC 비디오 decoder와 encoder를 관리합니다. 이때 사용되는 식별자는 WebProcess 스스로가 선택합니다. WebKit의 IPC 보안 모델은 수신 측이 신뢰할 수 없는 입력을 처리하기 전에 그 형식이 올바른지 검증하도록 요구하며, MESSAGE_CHECK가 이를 위한 표준 메커니즘입니다. 즉 손상된 sender가 위반할 수 있는 invariant가 감지되면, 연결을 종료하거나 completion handler를 통해 처리를 중단합니다. 이번 patch는 정확히 이 방어를 추가합니다. 이미 활성 상태인 identifier를 재사용하는 createDecoder/createEncoder 메시지는 codec 생성으로 진행되어 기존 map entry를 덮어쓰는 대신, callback을 실패로 종료합니다.

Significance

손상된 WebProcess는 더 이상 GPU 프로세스 내 기존 codec identifier를 재등록하여 proxy의 map에 기록된 identifier별 상태를 덮어쓸 수 없습니다.

Audit directions

앞으로 살펴볼 방향은, 다른 identifier 기반 진입점들에서 동일한 duplicate-identifier 허점이 있는지 확인하는 작업입니다. 좁게 보면, 이 proxy의 release 및 destroy 경로와 이에 대응하는 audio codec proxy들에서, 기존 key 존재 여부를 확인하지 않고 map에 바로 insert하는 create 계열 handler가 있는지 점검할 필요가 있습니다. 코드 리뷰 단서는 contains(identifier)에 대한 선행 MESSAGE_CHECK 없이 message handler 안에서 m_map.add(identifier, ...)나 m_map.set(...)이 호출되는 패턴입니다. 넓게 보면, renderer가 선택한 identifier로 키가 지정되는 GPU 프로세스나 Networking 프로세스의 모든 object registry가 같은 형태를 가지고 있으므로, IPC handler에서 도달 가능한 ObjectIdentifier 기반 map을 모두 나열하고 각 생성 경로를 점검하는 편이 좋습니다. 아울러 패치 이전에 overwrite 시 실제로 어떤 결과가 발생했는지도 확인할 가치가 있습니다. Use-after-free였는지, dangling completion handler였는지, 아니면 단순히 덮어써진 entry의 resource leak이었는지에 따라, 다른 지점에 남아있는 동일한 허점의 긴급도가 달라지기 때문입니다.