[Vulnerability][Chrome Stable 85] SVG and HTML loaded in <object>, <embed> elements bypass Service Worker

[t2ym]

[Vulnerability][Chrome Stable 85] SVG images and HTML documents loaded in <object>, <embed> elements bypass Service Worker

The issue is reproducible even with Chrome 85 Stable

Recommendation: hook.parameters.hangUpOnEmbedAndObjectElement = true

Block all <embed> and <object> element activities

<embed> and <object> become unusable with this configuration

Root Cause

• Chrome Stable issue on Service Worker (I have not identified any related issues in the Chromium issue list)
• This behavior may be as designed by the following reasons:
  • If an <embed> tag streams a video via HTTPS, the controlling Service Worker cannot handle a large streaming file properly as Service Workers are not designed to handle streaming contents via HTTPS.
  • If the <embed> tag bypasses the Service Worker, the embedded video can be streamed via HTTPS
  • Speculations:
    • Is a <video> tag feasible for streaming contents via HTTPS?
    • If the video streaming plug-in issues multiple HTTPS requests for partial downloads of target streaming contents, the Service Worker may be able to handle them but latency will become longer significantly
• Is this old open and neglected issue related? This may ambiguate the behavior of embed/object elements
  • object/embed w3c/ServiceWorker#249

Reproducibility

• Reproducible Chrome Stable Version:

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36

• Non-Reproducible Chrome Old Version

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.89 Safari/537.36

• Even with non-reproducible Chrome versions, THE FIRST LOAD still bypasses Service Worker, which has been mitigated by using hook.parameters.emptySvg for loading the target document/image
• Non-Reproducible element
  • <iframe>

Vulnerability even with double encryption

• MITM attackers can inject any code at an MITM proxy
• I have noticed another potential hacking scheme detectable only via Validation Console
  • I do not describe it here but I hope Validation Console of your own implementation works well.

Vulnerability without double encryption

• Embedded scripts in SVG images can bypass hooking and execute any inline code

Malfunction with double encryption

• The server-side integrityService.js responds with 403: Forbidden for the bypassed SVG requests
• The SVG documents fail to load

Workarounds

• Avoid using <object>, <embed> for SVG images
• Avoid using inline scripts in SVG images
• Reject HTTPS requests from the reproducible Chrome Canary versions
  • Via Validation Console (sorry for the missing implementation)
  • Via edge HTTP servers

Potential Fix (Under Investigation)

• How to detect the issue on Chrome Canary 86 --- IT IS A CHICKEN-AND-EGG PROBLEM TO DETECT IT BY THESE METHODS
  • When <embed> tag contains an HTML document, navigator.serviceWorker.controller is null
  • When <object> tag contains an HTML document, navigator.serviceWorker.ready is resolved to null
  • When <object> tag contains an HTML document, navigator.serviceWorker.getRegistration() is rejected with "the document is in an invalid state"

Trade-Off Mitigation available since 0.4.0-alpha.22

• hook.parameters.hangUpOnEmbedAndObjectElement = true to block all <embed> and <object> element activities
• The application hangs up to about:blank when their activities are detected
  • The reason why the application hangs up instead of just blocking the document URLs is that IT IS TOO LATE TO BLOCK THEM by setting null URLs just after the application detects the activities
  • Such a behavior can be validated by the situation that the application does NOT use any <embed> or <object> elements and thus the elements are obviously malicious and definitely indicate DOM INTRUSION by a hacker

[t2ym]

The issue is reproducible with Chrome Stable 85