Invalid IPC WebResourceLoader_WillSendRequestReply crash + cookie-leak merge-back

5243996

WebKit의 multi-process 모델에서는 NetworkProcess가 실제 네트워크 I/O를 담당하고, renderer exploit을 통해 공격자가 제어할 수 있는 WebContent process는 요청을 제안하는 역할만 수행합니다. continueWillSendRedirectedRequest는 web process가 redirect 도중 요청을 수정할 수 있는 유일한 callsite로, CFNetwork로 전달되기 전 firstPartyForCookies 필드까지 포함해 값을 바꿀 수 있습니다. 이 필드는 어느 origin의 쿠키가 첨부될지를 결정합니다. MESSAGE_CHECK_COMPLETION_BASE는 IPC로 전달된 데이터를 검증하고, protocol invariant를 위반하면 송신측 process를 종료시키는 WebKit의 메커니즘입니다.

Source/WebKit/NetworkProcess/NetworkResourceLoader.cpp

 Ref connection = protectedThis->m_connection;
+if (!connection->connection().isValid())
+    return completionHandler({ });
+
+if (newRequest.isNull())
+    return completionHandler({ });
+
 if (newRequest.firstPartyForCookies() != firstPartyForCookiesFromRedirectRequest) {
     auto allowCookieAccess = connection->networkProcess().allowsFirstPartyForCookies(connection->webProcessIdentifier(), newRequest.firstPartyForCookies());
     MESSAGE_CHECK_COMPLETION_BASE(allowCookieAccess == NetworkProcess::AllowCookieAccess::Allow, connection->connection(), completionHandler({ }));
 }

이번 변경은 continueWillSendRedirectedRequest에서 message check보다 앞서 validity/null 체크를 추가하고, firstPartyForCookies 체크를 mismatch branch 안에서만 실행되도록 순서를 조정합니다. Cross-origin 쿠키 유출을 막는 보안 fix(bug 313866)의 merge-back이며, 동시에 원래 fix가 유발한 crash에 대한 follow-up 수정이기도 합니다. 이 patch가 다루는 까다로운 지점은 실제 악의적인 변조와 정상적인 teardown을 구분하는 부분입니다. Keepalive 요청의 IPC connection이 진행 도중 끊기면 이전에는 기본 생성된(null) request가 만들어졌는데, 이 값이 체크를 잘못 통과시켜 정상적인 process를 종료시키는 결과로 이어질 수 있었습니다.

Significance

손상된 WebContent process가 redirect의 firstPartyForCookies를 재작성해 접근해서는 안 되는 origin의 쿠키를 획득할 수 있었던 경로를 차단하는 동시에, web process가 redirect 도중 종료될 때 발생하던 spurious process kill도 함께 막습니다. 이 두 가지가 함께 처리된다는 점이 중요합니다. 원래의 cookie-leak fix는 trust boundary를 강화했지만, 그 대가로 keepalive/teardown race 상황에서 crash surface가 넓어졌습니다. 이번 merge-back은 보안 속성은 그대로 유지하면서 이 availability regression만 제거합니다.

Audit directions

이 케이스는 cross-process trust boundary를 다루는 직접적인 사례에 해당합니다. WebContent process는 신뢰할 수 없는 주체이므로, redirect된 요청에서 이 process가 영향을 줄 수 있는 모든 필드는 NetworkProcess에서 사용되기 전에 검증되어야 합니다. 앞으로 살펴볼 만한 패턴은 같은 callsite에서 수정 가능한 다른 ResourceRequest 필드들입니다. Header, credentials policy, referrer 등이 여기 해당하며, 이들 역시 firstPartyForCookies에 이번에 적용된 것과 동일한 "이 값이 web process에게 허용된 집합 안에 있는가" 체크가 필요합니다. 각 필드가 실제로 검증되고 있는지, 아니면 그냥 신뢰되고 있는지 점검할 필요가 있습니다. Teardown race의 구조 역시 일반화됩니다. Connection teardown으로 생성된 기본값을 정상 입력처럼 취급하는 IPC completion handler라면 어디든 인접한 MESSAGE_CHECK를 잘못 트리거할 가능성이 있습니다. NetworkResourceLoader 내 다른 completion handler들과 GPUProcess의 유사한 reply 경로에서도 같은 패턴, 즉 protocol check 앞에 null/invalid-connection early-return이 빠져 있는 경우가 있는지 점검해야 합니다. 판별 기준은 decode된 IPC 값을 기준으로 하는 MESSAGE_CHECK* 앞에 connection이나 payload에 대한 isValid()/isNull() guard가 없는 경우입니다.