[22] [WebKit] MessagePort lifecycle on NetworkProcess restart

Severity: Low | Component: MessagePort lifecycle | 67117c4

diff에 MessagePort 서브시스템의 networkProcessCrashed 대칭 처리와 takeAllMessagesForPort의 late-arrival guard가 추가되었습니다. 패치 이전에는 Networking 재시작 후 고립된 port가 anti-spoof MESSAGE_CHECK를 발동시켜 WebContent process를 종료시킬 수 있었습니다. 다만 영향 범위가 가용성에 그치며, 메모리 corruption이나 trust-boundary primitive에는 해당하지 않으므로 Severity는 Low로 평가합니다.

WebMessagePortChannelProvider::networkProcessCrashed는 로컬에서 추적 중인 모든 port를 강제로 detach하고 m_inProcessPortMessages를 비웁니다. takeAllMessagesForPort에는 detachment와 경쟁하는 worker thread 완료 상황에 대비한 방어적 late-arrival guard가 추가되었습니다.

Source/WebCore/dom/messageports/WebMessagePortChannelProvider.cpp

+void WebMessagePortChannelProvider::networkProcessCrashed()
+{
+    for (auto& port : m_localPorts)
+        port.detach();
+    m_inProcessPortMessages.clear();
+}

Networking 재시작 후 정상적으로 고립된 port에서 anti-spoof MESSAGE_CHECK가 발동되어 WebContent process가 종료되는 문제.

Patch Details

새로 추가된 networkProcessCrashed 진입점을 통해 WebContent 측의 상태 관리가 Networking 측과 대칭적인 구조를 갖추게 되었습니다. takeAllMessagesForPort는 늦게 도착하는 완료 요청을 정상적으로 거부합니다.

Background

MessagePort의 상태는 WebContent와 Networking에 분산되어 관리됩니다. 이전의 hardening commit(305413.547)에서는 훼손된 WebContent로부터의 spoofing을 차단하기 위해 Networking process에 MESSAGE_CHECK가 추가되었습니다. 다만 이 CHECK는 "훼손된 renderer의 spoofed 요청"과 "이전 Networking process 종료 후 정상적으로 고립된 요청"을 구별하지 못합니다.

Analysis

패치 이전 동작을 살펴보면, MessageChannel이 생성될 때 양쪽 endpoint는 CreateNewMessagePortChannel / EntangleLocalPortInThisProcessToRemote를 통해 실행 중인 Networking process에 등록됩니다. 이후 Networking process가 crash 또는 jetsam으로 종료되면, WebContent process는 새로 생성된 Networking process에 재연결합니다. 그러나 기존 MessagePort JS 객체는 여전히 entangle 상태로 접근 가능한 상태입니다. 이 상태에서 port.postMessage IPC가 발생하면 새 Networking process가 알지 못하는 port 식별자를 참조하게 됩니다. 결과적으로 MESSAGE_CHECK가 발동하여 WebContent process가 종료됩니다.

수정 후에는 lifecycle이 대칭적으로 동작합니다. 연결이 끊어지면 로컬에서 추적하던 port가 강제로 detach되고, provider가 관리하는 known-to-network 목록이 초기화됩니다. takeAllMessagesForPort의 방어적 late-arrival guard는 detachment와 경쟁하는 worker thread 완료 상황을 처리합니다.

이 문제는 Networking 재시작에 대한 WebContent process의 가용성을 저하시키지만, security primitive에는 해당하지 않습니다.

Audit directions

WebContent 측의 Networking process 의존 상태: 대칭적인 networkProcessCrashed 핸들러가 구현되어 있는지 확인이 필요합니다. Storage quota, IDB, ServiceWorker 등록 정보 등이 해당합니다.
MESSAGE_CHECK 기반 hardening: 정상적으로 오래된 상태에 대한 false-positive 발생 여부를 점검해야 합니다.