[Site Isolation] Web Inspector: add ProxyingPageAgent and PageAgentProxy stubs for cross-process Page domain
Web Inspector는 domain-agent 모델을 사용합니다. 각 프로토콜 도메인에 해당 서브시스템을 계측하는 agent가 대응됩니다. Site Isolation 환경에서는 cross-origin iframe이 별도의 WebContent process에서 실행되므로, 단일 InspectorPageAgent는 로컬에서 호스팅하는 frame만 관찰할 수 있습니다. "octopus pattern"은 각 WebContent process에 경량 proxy agent를 두고 계측 이벤트를 IPC를 통해 UIProcess의 ProxyingAgent로 전달하는데, ProxyingAgent가 이를 받아 protocol 이벤트를 frontend로 분배합니다. 이 commit은 해당 패턴을 Network 도메인에서 Page 도메인으로 이식했습니다.
Source/WebCore/inspector/InstrumentingAgents.h
renderer에서 UIProcess로 전달되는 IPC 메시지는 FrameNavigated, DomContentEventFired, LoadEventFired, FrameDetached 네 가지입니다. m_pinnedInstrumentedProcesses는 계측이 활성화된 동안 Ref<WebProcessProxy>를 고정하여, IPC receiver가 항상 안전하게 제거될 수 있도록 보장합니다. Page 백엔드 명령(getResourceTree, reload, getCookies)은 후속 버그 처리를 위해 오류 응답으로 stub 처리되었습니다.
Significance
침해 가능성이 있는 renderer process에서 inspector의 UIProcess 측 agent로 이어지는 새로운 IPC attack surface를 생성합니다. 권한 있는 UIProcess에서 attacker가 제어할 수 있는 파라미터를 포함한 네 가지 메시지가 처리됩니다.
Audit directions
ProxyingPageAgent.cpp의 네 가지 IPC handler 전체를 살펴봐야 합니다. 특히 frame/loader ID로 프로토콜 객체를 생성하는 frameNavigated에 주목해야 하는데, commit에서 loaderId에 placeholder를 사용한다고 인정한 만큼 해당 전달 경로가 아직 검토되지 않은 상태입니다. m_pinnedInstrumentedProcesses의 lifetime도 점검이 필요합니다. enableInstrumentationForProcess가 이중 등록을 방지하는지, disableInstrumentationForProcess가 등록된 적 없는 receiver를 제거하도록 유도될 수 있는지 확인해야 합니다. WebPageInspectorController의 다섯 가지 lifecycle hook도 살펴봐야 합니다. 특히 didCommitProvisionalFrame과 didCommitProvisionalPage는 disable(기존)/enable(신규) 전환을 수행합니다. navigation commit과 frontend 연결 해제 사이에서 race condition이 발생하면, dangling receiver가 남거나 removeMessageReceiver가 두 번 호출될 가능성이 있습니다. EnablePageInstrumentation/DisablePageInstrumentation은 UIProcess에서 WebContent로 전달되며 PageAgentProxy의 연결 여부를 제어합니다. process 종료 순서와 어긋나면 stale instrumentation hook이 남을 가능성이 있습니다.