[9] [WebKit] Add origin validation to setAppBadge / setAppBadgeFromWorker
process의 소유 site set 외부 origin을 제공하는 renderer를 diff에서 종료합니다. 패치 이전에는 UIProcess가 UI client와 website data store에서 badge 업데이트를 spoofed origin에 귀속했습니다. 다만 IPC 자체로는 추가적인 확장 primitive가 확보되지 않아 Medium으로 평가되었습니다.
WebFrameProxy::setAppBadge와 WebProcessProxy::setAppBadgeFromWorker는 이제 allowsFirstPartyAccess를 참조합니다. 이 함수는 전달된 registrable domain을 m_site->domain()(또는 SharedProcess의 허용 set)과 비교합니다. 불일치하면 MESSAGE_CHECK가 발동되어 renderer가 종료됩니다. MultipleSites process 상태는 무시됩니다(이 상태는 실제로 존재하지 않으므로 무해합니다).
Source/WebKit/UIProcess/WebFrameProxy.cpp
Badging IPC에서의 origin spoofing: 침해된 renderer가 임의의 origin에 badge 업데이트를 귀속시키면, UI process는 spoofed origin을 website data store로 전달합니다.
Patch Details
두 IPC endpoint 모두 allowsFirstPartyAccess(origin) 검사를 추가했습니다. 이 matching logic은 process가 소유한 site를 허용하며, SharedProcess의 경우에는 허용 set을 대상으로 검사합니다. MultipleSites 상태는 no-op으로 처리됩니다.
Background
Badging API는 OS 앱 아이콘에 origin별 업데이트를 표시합니다. UIProcess는 각 WebContent process로부터 badge IPC를 수신합니다. 표준 process 모델에서는 하나의 process가 단일 site를 소유하므로, 다른 origin을 주장하는 IPC는 허용되지 않습니다.
Analysis
패치 이전에는 IPC handler가 전달받은 SecurityOriginData를 uiClient().updateAppBadge(...)와 workerUpdatedAppBadge(...)로 그대로 전달했습니다. 침해된 renderer는 메시지에 임의의 origin을 삽입할 수 있었고, UI process는 해당 origin에 badge를 귀속했습니다.
사용자에게 드러나는 영향은 임의 origin의 badge count를 대상으로 한 알림 형태의 spoof입니다. IPC 자체로는 추가적인 capability가 확보되지 않습니다. 패치는 mismatch 발생 시 renderer를 종료하는데, 이는 sandbox 경계에서의 표준 대응 방식입니다.
이 취약점은 WebContent ↔ UI 경계에서 Badging API의 origin별 귀속 불변성을 약화시킵니다.
Audit directions
- 다른 origin별 UIProcess IPC (
SecurityOriginData파라미터가 검증되지 않은 경우).allowsFirstPartyAccess또는 동등한 검사가 누락된 origin 필드를IPC::Connection/Messages::...handler에서 검색합니다. SharedProcess및MultipleSites상태 처리. origin이 포함된 모든 handler가 동일한 set 의미론을 수용하는지 확인합니다.MultipleSites에서의 silent drop은 실제 환경에서 이 상태의 process가 존재하지 않는 경우에만 올바른 처리입니다.- Service Worker IPC origin 주장. SW에서 시작되는 경로는 per-frame 검사를 우회하는 경우가 많습니다. 모든 경로에 동등한 검사가 적용되어 있는지 확인합니다.