// Memory needed for lookup tables of one Huffman tree group. Red, blue, alpha// and distance alphabets are constant (256 for red, blue and alpha, 40 for// distance) and lookup table sizes for them in worst case are 630 and 410// respectively. Size of green alphabet depends on color cache size and is equal// to 256 (green component values) + 24 (length prefix values)// + color_cache_size (between 0 and 2048).// All values computed for 8-bit first level lookup with Mark Adler's tool:// https://github.com/madler/zlib/blob/v1.2.5/examples/enough.c#define FIXED_TABLE_SIZE (630 * 3 + 410)static const uint16_t kTableSize[12] = {  FIXED_TABLE_SIZE + 654,  FIXED_TABLE_SIZE + 656,  FIXED_TABLE_SIZE + 658,  FIXED_TABLE_SIZE + 662,  FIXED_TABLE_SIZE + 670,  FIXED_TABLE_SIZE + 686,  FIXED_TABLE_SIZE + 718,  FIXED_TABLE_SIZE + 782,  FIXED_TABLE_SIZE + 912,  FIXED_TABLE_SIZE + 1168,  FIXED_TABLE_SIZE + 1680,  FIXED_TABLE_SIZE + 2704};
const int table_size = kTableSize[color_cache_bits];huffman_tables = (HuffmanCode*)WebPSafeMalloc(num_htree_groups * table_size, sizeof(*huffman_tables));

    Len  Code range                            #         Root entry         Overhead  #    ---  ------------------------------------  ---       -----------------  --------  ---    1    0                                     1         0xxxxxxx           0         128    9    10000000:0 .. 11110110:1              238       10000000-11110110  2^1       119         11110111:0                            1         11110111           2^2       1    10   11110111:10 .. 11110111:11            2         11111000:00 .. 11111110:11            28        11111000-11111110  2^2       7         11111111:00 .. 11111111:10            3         11111111           2^7       1    11   11111111:110                          1    12   11111111:1110                         1    13   11111111:11110                        1    15   11111111:1111100 .. 11111111:1111111  4

    Len  Code range                            #         Root entry         Overhead  #    ---  ------------------------------------  ---       -----------------  --------  ---    9    00000000:0                            1         00000000           2^7       1    10   00000000:10                           1    11   00000000:110                          1    12   00000000:1110                         1    13   00000000:11110                        1    14   00000000:111110                       1    15   00000000:1111110 .. 00000000:1111111  2         00000001:0000000 .. 00000010:1111111  256       00000001-00000010  2^7       2         00000011:0000000 .. 00000011:0001111  1         00000011           2^7       1

    // Fill in 2nd level tables and add pointers to root table.    for (len = root_bits + 1, step = 2; len <= MAX_ALLOWED_CODE_LENGTH;         ++len, step <<= 1) {      // ... snip ...      for (; count[len] > 0; --count[len]) {        // ... snip ...        code.bits = (uint8_t)(len - root_bits);        code.value = (uint16_t)sorted[symbol++];        ReplicateValue(&table[key >> root_bits], step, table_size, code); // overflow here        key = GetNextKey(key, len);      }    }

    // Check if tree is full.    if (num_nodes != 2 * offset[MAX_ALLOWED_CODE_LENGTH] - 1) {      return 0;    }

typedef struct {  uint8_t bits;     // number of bits used for this symbol  uint16_t value;   // symbol value or table offset} HuffmanCode;

| bits (1 byte) | padding (1 byte) | value (2 bytes) |

// Returns reverse(reverse(key, len) + 1, len), where reverse(key, len) is the// bit-wise reversal of the len least significant bits of key.static WEBP_INLINE uint32_t GetNextKey(uint32_t key, int len) {  uint32_t step = 1 << (len - 1);  while (key & step) {    step >>= 1;  }  return step ? (key & (step - 1)) + step : key;}

code.bits = (uint8_t)(len - root_bits);code.value = (uint16_t)sorted[symbol++];ReplicateValue(&table[key >> root_bits], step, table_size, code);

0x0 0x40 0x20 0x60 0x10 0x50 0x30 0x70 0x8 0x48 0x28 0x68 0x18 0x58 0x38 0x780x4 0x44 0x24 0x64 0x14 0x54 0x34 0x74 0xc 0x4c 0x2c 0x6c 0x1c 0x5c 0x3c 0x7c0x2 0x42 0x22 0x62 0x12 0x52 0x32 0x72 0xa 0x4a 0x2a 0x6a 0x1a 0x5a 0x3a 0x7a0x6 0x46 0x26 0x66 0x16 0x56 0x36 0x76 0xe 0x4e 0x2e 0x6e 0x1e 0x5e 0x3e 0x7e0x1 0x41 0x21 0x61 0x11 0x51 0x31 0x71 0x9 0x49 0x29 0x69 0x19 0x59 0x39 0x790x5 0x45 0x25 0x65 0x15 0x55 0x35 0x75 0xd 0x4d 0x2d 0x6d 0x1d 0x5d 0x3d 0x7d0x3 0x43 0x23 0x63 0x13 0x53 0x33 0x73 0xb 0x4b 0x2b 0x6b 0x1b 0x5b 0x3b 0x7b0x7 0x47 0x27 0x67 0x17 0x57 0x37 0x77 0xf 0x4f 0x2f 0x6f 0x1f 0x5f 0x3f 0x7f

01 前言

当我们把这样一个在三方库中的漏洞放到真实的环境中再看时，会发现漏洞所处的环境往往有很多复杂的变量，想要利用这个漏洞并非想象般那么容易。

我们所已知的信息有：

Chrome中不同大小的堆块被存储在不同的bucket当中，不同大小的对象因为这个机制被安全地隔离开。通常来说，在chrome中的堆利用需要找到同样大小的对象进行布局，再通过UAF或是OOB篡改其他的对象，从而造成信息泄露或者控制流劫持。接下来我们会分享我们所发现的对象，同时试图去绕过这个机制。

02 信息泄露

2.1 寻找对象

我们首先想要寻找的是一个合适的对象能够被OOB所改写，由于我们的越界写并不能很好地控制值，所以写指针基本被排除，最好的情况是能够改掉类似length这样的字段，对于值没有精确的要求，但是能够引发进一步更好利用的内存问题。

HuffmanCode在libwebp中是用malloc分配的，在chrome中实际是被PartitionAlloc最终接管分配。在renderer中一共有四个partition[5]，LayoutObject partition, Buffer partition, ArrayBuffer partition, FastMalloc partition。FastMalloc实际上最终调用的就是malloc，因此我们想要找的对象可以用FastMalloc来分配。

我们首先用了Man Yue Mo在博客[6]中提到的codeql查询，由于溢出在0x3000的bucket当中，可以选择的对象大小范围为0x2800 - 0x3000。但非常遗憾的是，查询结果为空，这个size下的对象几乎完全不存在。另一个思路是用溢出对象本身，但是这个对象被改掉后不会产生特别的破坏效果，libwebp中也没有其他好的候选对象。到了这里似乎令人觉得有些绝望，利用的第一步就被卡住了。

那么我们还有什么思路呢，一个想法是使用可变长的对象，如Man Yue Mo提到过的AudioArray，但是这个对象是纯数据，被改掉也没有用。查看所有FastMalloc的调用，最终我们发现了这个对象[7]：

class CORE_EXPORT CSSVariableData : public RefCounted<CSSVariableData> {  USING_FAST_MALLOC(CSSVariableData);

此对象的大小为动态的：

    wtf_size_t bytes_needed =        sizeof(CSSVariableData) + (original_text.Is8Bit()                                       ? original_text.length()                                       : 2 * original_text.length());    // ... snip ...    void* buf = WTF::Partitions::FastMalloc(        bytes_needed, WTF::GetStringWithTypeName<CSSVariableData>());

该对象代表了CSS中的变量[8]，可以通过以下方式来定义：

element {  foo: var(--my-var, bar);}

blink会根据CSS变量的内容动态分配CSSVariableData的内存。还有一个好消息是，JavaScript中也可以便捷地操作CSS变量。

// add a CSS variableelement.style.setProperty('foo', 'bar');// remove a CSS variableelement.style.removeProperty('foo');// get the value of a CSS variablegetComputedStyle(element).getPropertyValue('foo');

2.2 Cross-Thread堆占位

我们可以控制CSSVariableData的大小，使其分配至与HuffmanCode同样大小的bucket中。一个自然而然的计划是，分配一堆CSSVariableData，然后free其中一个，再用HuffmanCode占位，如下图所示。

然而设想很美好，实际上PartitionAlloc中使用了ThreadCache[9]，对象的分配和释放都会优先在ThreadCache中进行。由于两个对象不在同一个线程中分配，我们需要想办法将CSSVariableData从ThreadCache中移出。阅读ThreadCache的源码[10]，我们找到了一个途径：

  uint8_t limit = bucket.limit.load(std::memory_order_relaxed);  // Batched deallocation, amortizing lock acquisitions.  if (PA_UNLIKELY(bucket.count > limit)) {    ClearBucket(bucket, limit / 2);  }

当bucket被填满时，有一半的slot会被移出至原来的SlotSpan中。对于0x3000大小的bucket，limit为16。因此我们在释放16个CSSVariableData触发ClearBucket后，再分配HuffmanCode即可占到CSSVariableData的空位，为了保证HuffmanCode后面为想要改的CSSVariableData，需要隔几个释放一次，示意图如下（实际利用中为每7个释放一个）。

2.3 从OOB到UAF

至此我们可以成功分配HuffmanCode至被free的CSSVariableData处，我们需要探究该对象有什么值得更改的字段。

CSSVariableData的内存布局：

回想一下我们漏洞的原语——以8字节倍数的偏移写入4字节。对象中的string改掉也没有意义，那么我们能改的东西就只剩下ref_count_字段了。围绕ref_count_能做的文章有什么？一个自然的想法就是将此原语转化为UAF来进行后续利用。通过OOB将ref_count_改小，再触发减少ref_count_的操作，即可造出一个UAF的对象。

但是OOB写入的值并非完全可控，我们需要先用某种方式增大CSSVariableData的ref_count_至某个特定的值：

  let rs = getComputedStyle(div0);  // add ref_count with kOverwriteRef  for (let i = 0; i < kOverwriteRef; i++) {    rs.getPropertyValue(kTargetCSSVar);  }

测试发现，调用getPropertyValue即可临时增加CSSVariableData的ref_count_。而经过GC之后，临时增加的ref_count_会被恢复。因此造出一个UAF的对象需要以下步骤：

1. 分配CSSVariableData，其初始的ref_count_为2

2. 调用getPropertyValue kOverwriteRef次，此时ref_count_为kOverwriteRef + 2。

3. 触发webp的漏洞，将ref_count_改为kOverwriteRef 。

4. 触发GC，CSSVariableData被free。

5. 再次调用getPropertyValue即可触发UAF。

在getPropertyValue时，blink会根据length_构造string返回到js中。因此我们只需分配一个数据完全可控的对象（AudioArray[11]），伪造CSSVariableData的length_字段，即可达到在堆上越界读的效果。

03 Cross-Bucket分配

我们将OOB转化成了UAF，但是这个UAF的对象仅能造成堆上越界读的效果，假设这样可以解决信息泄露的问题（其实此时还并未解决），但仍无法完成进一步的利用。

在以往的blink堆利用中，占位后往往将目光聚焦于同样大小的对象，因为他们天生被分配在一起。但是此刻，0x3000的bucket内已经没有其他更好的对象能够利用，那么我们能否攻击其他大小的对象？经过我们的研究，答案是肯定的。

PartitionAlloc将堆的metadata（SlotSpanMetadata）放在被隔离开的页上，在用户分配的堆块上唯一剩下的管理信息就是freelist指针，如果我们可以将此指针更改，即可达到任意地址分配的效果。在常规的SlotSpan中free时，有double free的检查：

PA_ALWAYS_INLINE void SlotSpanMetadata::Free(uintptr_t slot_start,                                             PartitionRoot* root)  // ... snip ...  auto* entry = static_cast<internal::EncodedNextFreelistEntry*>(      SlotStartAddr2Ptr(slot_start));  // Catches an immediate double free.  PA_CHECK(entry != freelist_head);

在ThreadCache中，没有double free的检查，我们可以任意多次free相同地址。而分配时有检查，注释中说得很清楚：

  PA_ALWAYS_INLINE static bool IsSane(const EncodedNextFreelistEntry* here,                                      const EncodedNextFreelistEntry* next,                                      bool for_thread_cache) {    // Don't allow the freelist to be blindly followed to any location.    // Checks two constraints:    // - here and next must belong to the same superpage, unless this is in the    //   thread cache (they even always belong to the same slot span).    // - next cannot point inside the metadata area.    //    // Also, the lightweight UaF detection (pointer shadow) is checked.

我们想要任意分配的地方不能属于metadata（曾经用此手段可获得任意地址读写的能力，参考[12]），且要和原来的slot处于同一个superpage内，而这两点都可以轻易满足。

因此，我们假设CSSVariableData为A，占位的AudioArray为B（A和B实际为相同的地址），我们做一个类似经典的fastbin attack，即可做到任意地址分配。

1. free(A)

2. free(B)

3. malloc(C)，修改freelist为地址0xdeadbeef

4. malloc(D)

5. malloc(E)，此时分配到的E即为地址0xdeadbeef

那么要分配到哪里呢？

PartitionAlloc不同大小的对象通过bucket来管理，bucket通过SlotSpan来管理同样大小的slot，SlotSpan的单位为partition page，具体的概念及策略可参考官方文档[13]，如0x3000 slot size的SlotSpan由3个partition page组成，总大小0xc000，共可以分配4个0x3000的slot。

在内存中管理不同slot大小的SlotSpan实际可能是相邻的。那么我们只需要将我们感兴趣的对象所在的SlotSpan分配到0x3000 slot size的SlotSpan附近，即可完成信息泄露+对象劫持。我们参考Man Yue Mo的博客，最终选取了HRTFPanner（slot size为0x500）作为我们要攻击的对象。

我们在内存中以如下方式喷对象，更改freelist指针即可做到从0x3000的slot分配到0x500的slot上。

04 RCE

结合之前所有的知识，我们串联一下最终的步骤

1. 堆喷大量0x3000和0x500的SlotSpan。

2. 触发webp漏洞，转化为CSSVariableData的UAF。

3. 使用AudioArray占上被free的CSSVariableData，利用UAF获得信息泄露。

4. Cross-Bucket分配到HRTFPanner上，伪造HRTFPanner对象。

5. 触发HRTFPanner的析构获得任意代码执行。

05 结论

在本篇博客中，我们详细讨论了如何在Chrome中利用一个品相并非那么好的OOB写漏洞。本次测试仅为了展示该漏洞的可利用性，并未对成功率做过多优化。这个漏洞如何在iOS环境下转化并在PAC等缓解机制下利用仍然是一个开放问题。

点击“阅读原文”

直达 DARKNAVY 技术博客