在PLAYSTATION 4中利用WebKit 0-DAY

 

简介

基于webkit的浏览器通常是全链攻击的入口点:从浏览器利用到内核利用。但是，由于浏览器引擎加固技术加上完全没有调试功能，使得成功利用最新PS4固件中的bug非常困难。在这篇文章中，我们将介绍这个bug的根本原因。bug提供了有限的利用原语。但是，由于我们在ASLR机制中发现了一个缺陷，因此我们能够利用这个bug。我们将重点讨论我们采用的利用策略，以及我们如何将一个Use-After-Free转换为一个R/W原语，从而导致代码的执行。

 

攻击 PS4

浏览器可能是攻击PS4最常见的入口点。该浏览器基于WebKit，并在沙箱中运行。与iOS设备不同，没有现代缓解机制，例如Gigacage或StructureID随机化，并且未启用JIT。

典型的漏洞利用链以WebKit漏洞开始，以在渲染器进程中执行代码，然后绕过沙箱来运行内核exploit。

过去有几个WebKit漏洞被成功利用。@Fire30_创建的bad-hoistexploit是PS4上最后一个已知公开的exploit。它利用@lokihardt发现的漏洞CVE-2018-4386，并提供读/写原语。该exploit可在高达6.72的固件上使用。@lokihardt(CVE-2018-4441)发现的另一个漏洞也被@SpecterDev在PS4上利用。该exploit还提供了读/写原语，并在固件6.20上工作。

关于内核漏洞利用，@theflow0发布了最新的exploit。该exploit在内核中提供了读/写原语，可以从WebKit沙箱中访问。这个bug出现在7.02的固件上，最近又与bad-hoist的exploit一起出现在6.xx固件中。

最后，@qwertyoruiopz发现并利用了BPF上的一些漏洞。我们强烈建议读者看看@SpecterDev的write-up和@CTurt关于攻击PS4的系列文章。

 

WebKit堆

WebKit有许多堆分配器：

• FastMalloc是标准分配器。它被许多WebKit组件使用;
• DOM引擎使用的是IsoHeap。其目的是使用类型来排序每个分配以缓解UAF漏洞;
• JavaScript引擎使用垃圾回收器分配JavaScript对象；
• JavaScript引擎也使用IsoSubspace。它的目的与IsoHeap相同，但用于一些对象;
• Gigacage实现了缓解机制，以防止对特定对象进行超出范围的读/写。如上所述，它在PS4上被禁用。

主分配器

主堆由分成smallpages(4 KB)的块组成。small page为存储在smalllines(256字节)中的相同大小的对象提供分配。

主分配器本质上是一个bump分配器。使用fastMalloc原语分配对象时，该原语在使用快路径提供分配服务时仅执行以下操作。

--m_remaining;
char* result = m_ptr;
m_ptr += m_size;
return result;

当bump分配器的可用空闲对象slots用完时，将触发fastMalloc的慢路径以重新填充bump分配器。分配器从缓存(fast path)—即bumpRangeCache—或从新分配的page(慢路径)重新填充。从缓存中获取page——即lineCache，或者从为每个块维护的空闲页面列表中获取页面。如果页面有碎片（例如，从lineCache分配的页），则连续的空闲lines用于重新填充分配器。其余的空闲lines用于填充bumpRangeCache。

释放对象后，它不会立即用于后续分配。它被插入到一个专用的vector m_objectLog中，在Deallocator::processObjectLog中处理，当它达到最大容量(512)或通过慢路径填充bump分配器时将对其进行处理。processObjectLog的作用是在refcount达到0时释放一个smallLine(例如，没有使用smallLine中的所有slot对象)。当smallLine被释放时，它的相关页面推入cacheLine。请注意，smallPages和chunks也被计数，因此当它们各自的计数达到0时被释放。

 

bug

该bug已由我们的内部fuzzer触发。它存在于WebKit DOM引擎中。更准确地说，该bug存在于WebCore::ValidationMessage::buildBubbleTree方法中：

void ValidationMessage::buildBubbleTree()
{
    /* ... */
    auto weakElement = makeWeakPtr(*m_element); // [1] flawed weak pointer

    document.updateLayout();                    // [2] call user registered JS events

    if (!weakElement || !m_element->renderer())
        return;

    adjustBubblePosition(m_element->renderer()->absoluteBoundingBoxRect(), m_bubble.get());

    /* ... */
}

方法buildBubbleTree调用更新布局，在此期间执行所有用户注册的JS处理程序。如果ValidationMessage在一个JS回调中被销毁，当我们返回到buildBubbleTree代码时，这可能会导致后无使用的情况。WebKit开发人员已经发现，在更新样式或布局时可能会出现问题。然而，由于在生成弱指针时产生了额外的解引用，他们未能修复代码。也就是说，我们仍然可以在布局更新期间销毁ValidationMessage实例。

以下是漏洞报告后的修复程序：

void ValidationMessage::buildBubbleTree()
{
    /* ... */
-
-   auto weakElement = makeWeakPtr(*m_element);
-
-   document.updateLayout();
-
-   if (!weakElement || !m_element->renderer())
-       return;
-
-   adjustBubblePosition(m_element->renderer()->absoluteBoundingBoxRect(), m_bubble.get());

    /* ... */


+   if (!document.view())
+       return;
+   document.view()->queuePostLayoutCallback([weakThis = makeWeakPtr(*this)] {
+       if (!weakThis)
+           return;
+       weakThis->adjustBubblePosition();
+   });
}

触发bug

下图总结了易受攻击的路径。我们可以通过调用一些HTML输入字段上的reportValidity实例化ValidationMessage对象。我们在那个输入字段上注册一个JS处理程序。例如，我们可以定义一个JS处理程序，只要在输入字段上设置了焦点，它就会执行。

reportValidity方法触发一个计时器来调用buildBubbleTree函数。如果我们在定时器到期之前将焦点设置在HTML输入字段上，buildBubbleTree将在布局更新期间执行我们的JS处理程序。如果ValidationMessage在JS回调中被销毁，这将在返回buildBubbleTree代码时导致UAF。

现在，如果我们设法以某种方式生存到由于对ValidationMessage字段的无效访问而导致的早期崩溃，我们最终会调用deleteBubbleTree，这将再次破坏ValidationMessage实例。

我们第一次尝试触发这个bug失败了。reportValidity将焦点设置在过早触发JS回调的输入字段上。作为一种解决方案，我们使用了两个输入字段:input1和input2。首先，我们在焦点事件的第一个输入上注册一个JS处理程序。然后，我们reportVality在上调用input1。这将触发我们的JS处理程序执行，该处理程序将简单地将焦点设置在其他位置（例如input2）。最后，在buildBubbleTree执行之前，我们在input1上定义了一个新的处理程序，该处理程序将销毁 ValidationMessage实例。

调试bug

触发PS4上的bug会导致浏览器崩溃，没有任何调试信息。为了克服此限制，我们有两种选择：

• 设置一个调试环境，尽可能接近PlayStation环境。也就是说，安装一个FreeBSD box，然后从从doc.dl.playstation.net下载的源代码构建WebKit。这是很有帮助的，但有时在我们的环境中有效的exploit并不意味着在PS4上也能有效。
• 使用1-day漏洞调试0-day漏洞。为此，我们可以使用bad-hoist exploit，因为它提供了有用的原语，比如读/写原语，还提供了经典的addrof/fakeobj原语。然而，这个exploit是不稳定的，并且只能在固件6.xx上使用。此外，在我们之前运行这个exploit会给堆带来一些干扰。

漏洞解析

ValidationMessage对象是由reportValidity创建的，主要由buildBubbleTree访问。该对象是fastmalloc’ed的，由以下字段组成。

在布局更新之后，黄色的字段被实例化(m_messageBody, m_messageHeading)或者被重新实例化(m_timer)。绿色的字段(m_element和m_bubble)每个指向一个HTMLElement实例，在布局更新后被访问。

ValidationMessage的销毁是通过deleteBubbleTree方法完成的:

void ValidationMessage::deleteBubbleTree()
{
    if (m_bubble) {
        m_messageHeading = nullptr;
        m_messageBody = nullptr;
        m_element->userAgentShadowRoot()->removeChild(*m_bubble);
        m_bubble = nullptr;
    }
    m_message = String();
}

这个方法清除了大多数ValidationMessage字段(包括m_bubble)，如果它在布局更新期间被调用，会导致浏览器崩溃。更准确地说，渲染器进程在试图解引用m_bubble.get()时在函数adjustBubblePosition中崩溃。

为了利用此漏洞，我们需要内存泄漏或绕过ASLR。事实证明，我们可以通过堆喷射在可预测的位置分配一些对象。但是，利用此漏洞需要对早期的内存映射有一定了解。由于bad-hoist的exploit，我们已经将其用于固件6.xx。理论上，预测的地址在7.xx固件上是可以强制执行的（稍后会详细介绍）。

以下是避免过早崩溃的方法：

• 喷射HTMLElement对象(如HTMLTextAreaElement)→分配在固定位置的对象。
• 混淆ValidationMessage和受控对象(例如ArrayBuffer的内容)。
• 修复m_bubble和m_element值，以便它们指向我们预测的地址。

 

Exploitation

重用目标对象

为了重用我们的目标对象，我们如下图所示进行操作：

• 我们在分配目标对象之前和之后向堆中喷射对象O——其大小与ValidationMessage相同(48字节)。
• 我们删除ValidationMessage实例以及周围的O对象，从而使包含这些对象的smallLine被释放，相关的smallPage被缓存。

我们再次向堆中喷射与目标对象大小相同的对象。在我们的exploit中，我们喷洒了ArrayBuffer(48)，以便用ArrayBuffer的内容覆盖ValidationMessage内容。

初始化内存泄漏

如前所述，一些ValidationMessage在布局更新之后被实例化，因此它们的内容可能会泄漏。更准确地说，通过简单地dump ArrayBuffer的内容，我们可以泄漏m_messageBody、m_messageHeading和m_timer的值。m_timer特别有趣，因为它是fast的，因此允许我们推断分配在同一smallPage上的对象的地址。

任意递减原语

现在，如果我们正确地使用目标对象，我们最终会调用deleteBubbleTree方法，该方法将大多数ValidationMessage字段设置为空指针值。需要注意的是，在refcount类上重载空指针赋值会导致refcount递减。这意味着我们在多个受控制的ValidationMessage的字段上有一个refcount递减:m_messageBody, m_messageHeading和m_bubble。

我们可以通过破坏例如m_messageHeading指针并将其refcount字段与某些对象的length字段混淆来利用refcount递减。通过将对象指定为具有length和data字段的StringImpl对象，在length字段上未对齐的写入将使我们能够读取超出数据限制的内容。

下面，我们将两次利用任意递减原语：

• 1.第一次运行的目的是建立一个相对读取的原语，以泄漏a的地址JSArrayBufferView。
• 2.第二次运行的目标是通过破坏先前泄漏的JSArrayBufferView地址的length字段来建立相对的读/写原语。

下图总结了工作流程：

相对读原语

这一部分的目标是泄漏JSArrayBufferView对象的地址。从我们的角度来看，这个对象很有趣，因为它有一个length字段，并且它允许读/写数据缓冲区中的任意数据。如果我们可以控制length字段，那么我们可以读/写超出数据缓冲区的限制。此对象是使用垃圾回收器分配的。由于我们没有这个堆的任何泄漏，所以无法使用任意的递减原语到达它。

这是我们覆盖一个StringImpl对象的length的方法：

• 在m_timer实例化之前和之后喷射多个StringImpl对象。我们分配StringImpl，这样他们有相同的大小作为一个定时器对象，以确保m_timer和StringImpl驻留在相同的smallPage。
• 利用喷过的StringImpl length字段上的任意递减原语。
• 遍历StringImpl对象，并检查哪个对象的length已损坏(例如，length较大的对象是正确的)。

一旦我们通过损坏的StringImpl的length字段获得了相对原语，让我们看看如何在FastMalloc堆上获得JSArrayBufferView引用。

defineproperties是一个内置的JavaScript，允许定义JavaScript对象属性。

static JSValue defineProperties(ExecState* exec, JSObject* object, JSObject* properties)
{
    Vector<PropertyDescriptor> descriptors;
    MarkedArgumentBuffer markBuffer;

    /* ... */
    JSValue prop = properties->get(exec, propertyNames[i]);
    /* ... */
    PropertyDescriptor descriptor;
    toPropertyDescriptor(exec, prop, descriptor);
    /* ... */
    descriptors.append(descriptor);        // [1] store JSValue reference on fastMalloc
    /* ... */
    markBuffer.append(descriptor.value()); // [2] store one more JSValue reference on fastMalloc
}

在其实现中，此方法使用两个对象：

• Vector<PropertyDescriptor>
• MarkedArgumentBuffer

这两个对象都有一个使用fastMalloc分配的backing缓冲区，defineProperties使用这两个对象来存储JSValue引用。JavaScript引擎使用JSValue来表示许多JavaScript值。我们对这个对象很感兴趣，因为它可以是一个JSObject引用(例如JSArrayBufferView)。从而允许我们将JSObject引用推入FastMalloc堆。使用我们的FastMalloc相对读取，我们可以找到这些引用。

这是@qwertyoruiopz用来在FastMalloc堆上获取JSObject引用的技术：

• 1.分配多个JSArrayBufferView对象。
• 2.使用Object.defineProperties在FastMalloc堆上推入引用。当离开Object.defineProperties时，引用被释放，但不会被清除。我们必须小心不要重用这些分配，以避免清除JSValue引用。
• 3.使用相对读取来扫描FastMalloc堆并搜索喷射出来的JSArrayBufferView引用。目标引用必须能够从相对读操作中访问到。

相对读/写原语

在JSArrayBufferView泄漏的情况下，我们可以通过以下步骤轻松获取相关读/写操作:

• 1.再次运行exploit程序以重新使用任意递减原语。
• 2.使用任意递减来覆盖JSArrayBufferView的length字段。可以通过检查每个喷射过的对象的length来找到覆盖的JSArrayBufferView。大的是正确的。

这个引用可以用于读/写超出fastMalloc支持的缓冲区的限制。

任意读写原语

JSArrayBufferView对象有一个到它的数据缓冲区的引用字段。破坏这个引用允许任意读/写原语。

我们仍然有一个相对读，相对读数据缓冲区的内存地址，我们知道泄漏的JSArrayBufferView可以从相对读数据缓冲区中访问。由于有了相对读，我们可以很容易地找到相对读/写backing缓冲区的内存位置。

现在，我们可以使用backing缓冲区引用来访问使用相对读/写操作喷出来的JSArrayBufferView，并破坏另一个JSArrayBufferView对象的backing缓冲区引用。这允许使用第二个JSArrayBufferView引用在任意地址读取和写入任意数据，如下图所示:

代码执行

PS4浏览器不允许分配RWX内存页面。但用任意的R/W，我们可以控制RIP寄存器。例如，我们可以覆盖先前喷射的HTMLTextAreaElement的虚表指针，使其指向我们控制的数据。在HTMLTextAreaElement上调用一个JavaScript方法将导致调用我们控制的一个地址。然后，我们可以进行代码重用(如ROP或JOP)来实现下一阶段。

这个exploit可以在Synacktiv的Github中找到。

在7.XX固件上移植这个exploit

由于ASLR机制方面的缺陷使我们能够预测HTML对象的地址，因此我们成功地咋6.xx固件上的利用了这个漏洞。可预测的地址在exploit程序中进行了硬编码，并且由于bad-hoist的exploit程序已被识别出来。但是，在不知道早期内存映射状况的情况下，确定已喷射的HTMLElement对象的地址的唯一方法是强制使用该地址。

由于浏览器需要用户交互才能重新启动，因此PS4上的暴力破解非常乏味。我们的想法是插入充当PS4键盘的Raspberry Pi。其主要目标是在崩溃后定期（5s）按下Enter键以重新启动浏览器。强制地址在每次尝试时更新并存储在一个cookie中。

不幸的是，到目前为止我们没有得到任何结果。我们可能没有足够长的时间来覆盖整个地址空间。