WebKit – Universal XSS in HTMLFrameElementBase::isURLAllowed

• Exploit Database
• 108 阅读

• 作者： Google Security Research
  日期： 2019-10-28
• 类别：

  • dos
  平台：

  • multiple
• 来源：https://www.exploit-db.com/exploits/47552/
• 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

  VULNERABILITY DETAILS HTMLFrameElementBase.cpp: </code><code> bool HTMLFrameElementBase::isURLAllowed() const { if (m_URL.isEmpty()) // ***4*** return true;   return isURLAllowed(document().completeURL(m_URL)); }   bool HTMLFrameElementBase::isURLAllowed(const URL& completeURL) const { if (document().page() && document().page()->subframeCount() >= Page::maxNumberOfFrames) // ***3*** return false;   if (completeURL.isEmpty()) return true;   if (WTF::protocolIsJavaScript(completeURL)) { RefPtr<Document> contentDoc = this->contentDocument(); if (contentDoc && !ScriptController::canAccessFromCurrentOrigin(contentDoc->frame(), document())) return false; }   RefPtr<Frame> parentFrame = document().frame(); if (parentFrame) return parentFrame->isURLAllowed(completeURL);   return true; }   void HTMLFrameElementBase::openURL(LockHistory lockHistory, LockBackForwardList lockBackForwardList) { if (!isURLAllowed()) return;   [...]   parentFrame->loader().subframeLoader().requestFrame(*this, m_URL, frameName, lockHistory, lockBackForwardList); </code><code> NodeRarData.h: </code><code> class NodeRareData : public NodeRareDataBase { [...] private: unsigned m_connectedFrameCount : 10; // Must fit Page::maxNumberOfFrames. ***1*** </code><code> Page.h: </code><code> class Page : public Supplementable<Page>, public CanMakeWeakPtr<Page> { [...] // Don&apos;t allow more than a certain number of frames in a page. // This seems like a reasonable upper bound, and otherwise mutually // recursive frameset pages can quickly bring the program to its knees // with exponential growth in the number of frames. static const int maxNumberOfFrames = 1000; // ***2*** </code><code> Every DOM node stores the number of child frames currently attached to the subtree to speed up the disconnectSubframes</code> algorithm; more specifically, when the number of connected frames for a given node is zero, its subtree won&apos;t be traversed. The value is stored as a 10-bit integer[1], so, to protect it from overflowing, an upper bound for the total count of attached subframes has been introduced[2]. It&apos;s enforced inside <code>isURLAllowed</code>[3] along with some other URL-specific checks. The problem is if the current URL is empty, all the checks will be skipped[4].   Therefore, an attacker can insert exactly 1024 frame elements with an empty URL into a node, so its connected subframe counter will overflow and become zero. Later, when the node is removed from the document tree, the subframes won&apos;t be detached.   The attacker can also abuse the flaw to make a subframe "survive" a cross-origin page load because disconnectDescendantFrames</code>, which is called during the document replacement, only processes iframe</code> elements inside the document tree. Then, if the subframe is navigated to the <code>about:srcdoc URL, the new document will inherit the security context from its parent document, which can be an arbitrary cross-origin page, while the contents will be attacker-controlled.   Moving the check closer to the actual frame creation in <code>SubframeLoader::loadSubframe</code> should fix the issue. Besides, since the <code>srcdoc</code> technique can be reused in other UXSS bugs, I think it&apos;s reasonable to try to break it. One way to achieve that is to replace the disconnectDescendantFrames</code> call in <code>Document::prepareForDestruction</code> with a call to FrameLoader::detachChildren</code>, which detaches subframes regardless of whether their associated elements are attached to the document tree. However, I&apos;m not sure if this change would be safe. The attached patch just adds a release assertion after <code>disconnectDescendantFrames</code> to ensure that all subframes have been detached. The solution is not too elegant, but a similar fix in Blink (https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/dom/document.cc?rcl=a34380189132e826108a71d9f6024b863ce1dcaf&l=3115) has proved to be effective.     VERSION WebKit revision 247430 Safari version 12.1.1 (14607.2.6.1.1)     REPRODUCTION CASE The minimal test case that demonstrates the issue is as follows: </code><code> <body> <script> const FRAME_COUNT = 1024;   let container = document.body.appendChild(document.createElement(&apos;div&apos;)); for (let i = 0; i < FRAME_COUNT; ++i) { let frame = container.appendChild(document.createElement(&apos;iframe&apos;)); frame.style.display = &apos;none&apos;; } container.remove();   frame = container.firstChild; alert( <iframe> is not attached to the document tree, but still has a content frame! frame.parentNode.parentNode: ${frame.parentNode.parentNode} frame.contentWindow: ${frame.contentWindow} ); </script> </body> </code><code> The full UXSS exploit is in the attached archive.     CREDIT INFORMATION Sergei Glazunov of Google Project Zero     Proof of Concept: https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/47552.zip