v8 exploit

v8的知识结构

环境搭建

预先准备

  1. 各种依赖

    1
    apt-get install binutils python2.7 perl socat git build-essential gdb gdbserver
  2. gdb-peda

    1
    2
    3
    git clone https://github.com/scwuaptx/peda.git ~/peda
    git clone https://github.com/scwuaptx/Pwngdb.git ~/Pwngdb
    cp ~/Pwngdb/.gdbinit ~/
  3. 环境设置
    ubuntu16.04 x64

使用make的方式去编译v8(2016年当时)

  1. depot_tools准备

    1
    2
    $ git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
    $ echo 'export PATH=$PATH:"/path/to/depot_tools"' >> ~/.bashrc
  2. v8编译

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    $ fetch v8 && cd v8$ git reset --hard 6ff5881b1def45b35384572f61327e42563a89c3
    $ gclient sync
    $ make x64.debug -j 8 # 如果这一步出现问题,就按照下面的方式重新编译
    ...
    ...
    $ mv ./third_party/binutils/Linux_x64/Release/bin/ld.gold{,.old}
    $ ln -s {/usr,./third_party/binutils/Linux_x64/Release}/bin/ld.gold
    $ make x64.debug -j 8

    # instead of using symbloic link, you can use the following line (thank ishita for helping
    $ GYP_DEFINES="werror= linux_use_bundled_binutils=0 linux_use_bundled_gold=0" make x64.debug -j8

/path/to/根据你自己的环境替换。

  1. 启动
    1
    2
    $ ./out/x64.debug/d8
    $ ./out/x64.debug/shell

使用ninja的方式去编译v8(2018现在)

  1. depot_tools准备
    1
    2
    $ git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
    $ echo 'export PATH=$PATH:"/path/to/depot_tools"' >> ~/.bashrc

/path/to/根据你自己的环境替换。

  1. ninja准备

    1
    2
    3
    $ git clone https://github.com/ninja-build/ninja.git
    $ cd ninja && ./configure.py --bootstrap && cd ..
    $ echo 'export PATH=$PATH:"/path/to/ninja"' >> ~/.bashrc
  2. v8编译

    1
    2
    3
    $ fetch v8 && cd v8&& gclient sync
    $ tools/dev/v8gen.py x64.debug
    $ ninja -C out.gn/x64.debug
  3. 启动

    1
    2
    $ ./out/x64.debug/d8
    $ ./out/x64.debug/shell

关于js的问题

js引擎

世界上有各类的js引擎,比较有名的有下面这几种。

浏览器 渲染引擎 js引擎


其他的js引擎介绍可以在这里找到:
https://blog.sessionstack.com/how-javascript-works-inside-the-v8-engine-5-tips-on-how-to-write-optimized-code-ac089e62b12e

js的pattern分为两类

  1. 由patch引入的更多pattern
    了解如何利用由patch所引发的新漏洞,用js来编写exp
  2. 过去的CVE
    编译有漏洞的源码
    在上一次和下一次commit之间找到正确的patch
    有些情况下,PoC(attack code)会随着commit一起发布。
    从修补程序中找出漏洞,并参考公开可用的PoC进行编写exp

今天我们将解决pattern 1,但是它和解决pattern 2要做的是相似的。

攻略方法

  1. 创建一个用于调试的js环境版本
    如果有一个包含漏洞的patch,hit和build它。
  2. 分析patch以确定哪个patch适用于哪个进程
    Full-Codegen, Crankshaft, TurboFan, Ignition, AST, IC, …
    Full-Codegen and Crankshaft do not exist in V8 as of 2018 (see below)
  3. 编写利用漏洞的js代码段
    Think JavaScript code that causes patched parts to pass and causes bugs
  4. 创建一个任意地址读/写的原语
    主要使用ArrayBuffer和TypedArray
  5. getshell
    由于这是Pwn类别的问题,getshell是第一目标。
    在JIT区域嵌入shell代码经常被使用

今天的主题1是如何阅读v8和给出一些编写js exp的建议。
今天的主题2是我将介绍getshell的通用技术。

目标


问题出现在当时的v8,已经和现在大不相同。

  • 当时: Full-Codegen(JIT生成) + Crankshaft(优化1) + TurboFan(优化2)
  • 现在: Ignition(JIT生成) + TurboFan(优化)

然而对这个bug的学习依然有用。

要完成这个目标,我们需要掌握以下知识:

  1. 编译器优化
    触发optimize的条件
  2. GC(垃圾回收)
    GC的实现和触发条件
  3. 了解V8的内存结构和类型表示
    Integer value, double value, pointer, character string, special value, array, ArrayBuffer, etc.

供参考的exp:
https://gist.github.com/sroettger/d077d3907999aaa0f89d11d956b438ea
https://rzhou.org/~ricky/pctf2016/js_sandbox.js

什么是v8?

解释和执行js的引擎
由c++实现,parse js代码,构造AST
基于AST,JIT将其编译成汇编执行。

AST:a+b

在做v8 exp之前,首先我们需要知道v8的结构(你不需要知道所有的结构,因为它更新很快……)
但是你必须了解基本的概念。

在了解了这些之后,你就可以从Exploit的观点去深入

  • 如何实现任意地址读写?
  • 如何稳定的利用?

注意,我们主要讲解2016年4月的v8的结构,如果你想了解现在的v8,下面这些资料是十分有用的。
https://www.slideshare.net/ssuser6f246f/v8-javascript-engine-for
https://speakerdeck.com/brn/source-to-binary-journey-of-v8-javascript-engine

v8的编译器和优化

编译器的种类

要理解v8,其中最重要的组件就是编译器。
内部大概分成四个编译器
旧的baseline编译器:Full-Codegen
旧的优化编译器:Crankshaft
新的优化编译器:TurboFan
新的baseline编译器:Ignition

下面这些资料可以用于参考:
An overview of the TurboFan compiler
TurboFan: A new code generation architecture for V8

编译器的历史

最初,Full-Codegen直接生成和执行汇编语言
从AST直接生成汇编语言代码(JIT)相对较快,但是生成的汇编语言代码有很多冗杂部分,还有优化空间。

2010年,用于优化hot-code的Crankshaft被引入。

2015年,又引入了TurboFan,为了更好的适应新的javascript规范。

2017年,引入了生成中间语言(bytecode)的Ignition

2018年至今,Full-Codegen和Crankshaft已经被从v8中移除。


今天的问题~

2016年当时的latest
Hidden Class和Inline Caching也用作优化。

编译器和优化

  • baseline编译器
    1.Full-Codegen 重要度低—>对于理解这个exp的重要性
  • 优化机制
    2.Hidden Class 重要度中—>更准确的说,Hidden Class是一种有助于自身加速的机制,而Inline Caching是一种基于Hidden Class信息进行优化的机制。
    3.Inline Caching 重要度中
  • 优化编译器
    4.Crankshaft 重要度低
    5.TurboFan 重要度高


(顺便说一下)你应该知道的其他部分

api.cc、api.h:如果你想集成v8到你自己的程序,可以使用这里的API。
compiler/、compiler.cc、compiler.hh:编译起点是src/compiler.cc(从src/api.cc调用)
globals.h:常量和其他的定义
heap:GC
ic:Inline Caching
objects-ini.h、objects.cc、objects.h、type.cc、type.h: V8中使用的对象和类型的定义

Full-Codegen

Full-Codegen中存在的机制:

  • 将AST转换为汇编语言
    • 它是一个JIT编译器
      • JIT编译器:一种在软件执行时进行编译并提高执行速度的机制
      • 通过它,v8把要执行的JavaScript代码转换为机器语言
    • 机器语言输出位于JIT区域(= RWX区域)
      • 将EIP寄存器移到这个JIT区域并按原样继续执行
    • 它尚未优化

它是一种与当前问题没有太大关系,并且不存在于最新代码中的机制,因此省略了细节

优化

  • Full-Codegen生成的机器语言特性(半优化代码)
    • 生成速度快,但执行速度慢(造成浪费)
  • 因此,使用了根据需要来进行优化的机制

    • 优化1:缓存使用情况

      • 使用Hidden Class和Inline Caching
        • 缓存要调用的地址和要引用的偏移量
    • 优化2:重新编译为更高效的JIT代码

      • 优化目标是在运行时确定的
        • 在主线程中,正常执行机器语言
        • 在另一个线程中,Runtime-Profiler测量使用状态
          • Runtime-Profiler:在程序执行时测量和统计执行状态的机制
          • 根据测量结果判断是否优化
      • 使用Crankshaft进行优化编译
        • 再次将源编译为机器语言,并将正在运行的机器语言替换掉
      • 使用TurboFan优化编译
        • 再次将源编译为机器语言,并将正在运行的机器语言替换掉


Hiddern Class

  1. 每个property的值都以数组的形式进行管理。
  2. 通过偏移值访问数组里的property值

偏移值被分开管理
将属性名称和偏移量的依赖关系保留给另一个类(Map类)
这个Map类被称作Hidden Class

Map生成


①创建object的时刻(还没有property时),obj1内部指向C0
②创建一个没有property的map,type+offset管理,通常被称作C0

①当你添加obj1.x的时候,改变obj1内部指向C1
②通过向C0添加x的offset信息来创建新的map C1(map也有类型信息)
③在C0中添加转换条件
Map:C0
条件:当x加入时转移到C1

当访问obj1.x的值时,跟踪obj1所持有的指针,并引用C1以获取“x的偏移量为0”的信息。之后,通过访问obj 1的偏移量0处的值,可以高速的获得x的值。在C1内部,有必要寻找“x”,尽管我个人觉得它与哈希表似乎没有多大区别,但是这会让它更快。


①当你添加obj1.y的时候,obj1在内部更改为指向C2
②通过向C1添加y的offset信息来创建新的map C2
③在C1中添加转换条件
条件:添加y时,转换到C2

此时C0和C1不再使用,但它们不会被移除,因为它们可能在将来被重新使用。

对于具有完全相同属性的对象,如果你创建类似的对象,自然存在“x”和“y”,你可以使用创建的Map。
创建obj 2的时刻指向C0,但通过以与obj 1相同的方式按x和y的顺序添加属性,它遵循转换条件以完成C0->C1->C2

注意:如果属性添加顺序不同,即使具有相同名称的属性的对象也将具有不同的转换条件。 因此,最终创建的map也会变成不同的map,并且无法获得加速的好处。
有关详细信息,请参阅
http://richardartoul.github.io/jekyll/update/2015/04/26/hidden-classes.html
另外,如果property添加/删除次数增加太多,Hidden Class的管理会减慢。
因此,此时它不使用Hidden Class,而使用字典类型来管理
https://v8project.blogspot.jp/2017/08/fast-properties.html

property的管理方法

1.默认情况下,object的内部管理是通过array实现的

  • In-Object property(这次的解说就是用这种方法)

2.当property增加到11个以上,使用外部的array来管理。

  • Fast property

3.如果再进一步增加property,那么就用object外的dictory来管理

  • slow/dict properties
    • 它也被称为self-contained,因为没有使用map且使用外部的dictory保存所有的信息
    • 尽管实体是一个FixedArray的数组,但它被用作如下所示的字典

参考资料:https://v8project.blogspot.jp/2017/08/fast-properties.html

我想在这里说的

  1. 一个object(javascript中)有一个指向Map的指针
    • 正如我们稍后会看到的,object的前8个字节是一个指向Map的指针
  2. (JavaScript)object指向的map将根据状况改变
    • 在漏洞利用中,这不是一个可靠的指针
  3. 相同的类型=Map的地址是相同的
    • 比较map的地址即可确定类型是否一致

Inline Caching

参考资料:

附注:其中部分我做了翻译,可以在这里找到

对于各个action,对类型进行缓存和优化的机制

  1. 这里所说的action可以表示下列任意一种
    - 参照,代入(LoadIC, StoreIC)
    - 数组访问(KeyedLoadIC,KeyedStoreIC)
    - 二项演算 (BinaryOpIC)**最近的V8中被去掉了?**
    - 函数调用(CallIC)
    - 比较(CompareIC)
    - 布尔化(ToBooleanIC) **最近的V8中被去掉了?**
    
  2. 某些action的jit code被多次调用时需要考虑的
    • 循环和函数多次传递相同的JIT code
  3. 在执行JIT代码时着眼于操作目标的类型(≒参数)
    • JIT code很可能与上次通过时的操作类型相同
    • 例如,以下JavaScript代码显示重复相同类型的操作
      • 即使对应每个JIT代码,这个推断也应该保持不变
        1
        2
        3
        4
        5
        6
        7
        for (var i=0;
        i<10000; // 也许一个integer被从i载入,它是很可能去进行integer和integer的比较
        i++) // 进行整数相加的可能性很大,i可能用一个整数去代替
        {
        var j = // j可能是被赋值为整数
        100*i; // 也许一个整数会从i加载,它是很可能去进行整数相乘
        }

  1. JavaScript类型=map地址

    • 从Hidden Class实现中可以看到,如果是相同类型,那么Map地址是相同的。
    • 缓存类型意味着将map地址嵌入到JIT code中
    • 例如,加载obj.x时的IC具有以下image
      • 将x的偏移值一起缓存
      • 当map匹配时,直接由缓存的x的偏移值得到property x的值,并返回。
        1
        2
        3
        4
        5
        6
        7
        8
        9
        10
            mov  ecx, "x"
        mov eax, obj
        cmp [eax + kMapOffset], <被缓存的map地址>
        jne MISS
        mov eax, [eax + kPropertiesOffset]
        mov eax, [eax + 被缓存的"x"(通过hidden class获得)的offset]
        jmp DONE
        MISS:
        call IC_Miss// 抄近路失败,根据本来的code来获得"x"的offset
        DONE:
  2. 实际上,由于有多个Map被注册的情况,所以需要进行函数化

    箭头1:当第二个map被注册时
    箭头2:当第三个map被注册时

  3. IC[存储了/持有]State

    • UNINITIALIZED(0): 未初始化
    • PREMONOMORPHIC(.): 只被执行一次的情况,还没进行IC
    • MONOMORPHIC(1): IC注册一个的状态(快速)
    • POLYMORPHIC(P): IC注册两个以上的状态(一般的快)
    • MEGAMORPHIC(N): IC注册多个的状态
    • GENERIC(G):IC已停止的状态
      括号里是对于之后所说的debug输出(–trace-ic)的省略的标注
    • 基本上是从上到下进行迁移的(0->.->1->P->N->G)
      • 有些直接从0→1,如CallIC等
  4. Inline Caching可通过-trace-ic进行确认
  5. 使用–use-ic启用IC(默认),使用–no-use-ic禁用

关于inline caching

到目前为止说过的东西:

  • 它与Hidden Class配对,对hign speed有很大的贡献
  • 但是在exploit观点,只需缓存在JIT中的地址和偏移量即可
  • 由于很难创建任意地址读/写的原语,因此与exploit的兼容性不是很好
  • 但是,有些情况下应该部分简化IC检查(例如边界检查)
    • 因此,在非IC下不会引发的漏洞可能会在IC下触发

优化

Crankshaft和TurboFan

两种编译器都可以用于优化

  • 如何调用优化

    • hot-code,也就是说,它是一个多次调用的函数或循环
      • 优化由函数单元或循环单元执行
      • 与主线程中并行执行,runtime-profiler在另一个线程中计数并作出判断
      • 它也取决于函数和循环的代码段大小,但如果调用大约1000次或10000次左右,它将成为优化目标
        1
        2
        3
        4
        5
        6
        function f() {
        return 1;// hot-code(都有成为hot-code的可能性)
        }
        for (var i=0; i<10000; i++) {
        func(); // hot-code(都有成为hot-code的可能性)
        }
  • 被判断为hot-code的话

    • turbofan/crankshart会在其他线程里再次编译(hot-code的)所属区域(的代码)
      • 但是,hot-code不被最优化的情况也是存在的
    • 通过替换机器语言的jmp目标地址(在主线程中执行)来切换以执行优化的机器语言,
1
2
3
4
5
6
7
8
9
将函数切换为优化代码时,可以将指针更新为函数对象的JIT区域
function f() {
return 1;// hot-code(都有成为hot-code的可能性)
}
for (var i=0; i<10000; i++) {
func(); // hot-code(都有成为hot-code的可能性)
}
在循环中,当从中间切换到优化代码时,可以将jmp目标切换到循环的顶部,但仍然存在名为OSR(On-Stack-Replacement)的切换方法。
但这里省略,参考这篇文章:https://wingolog.org/archives/2011/06/20/on-stack-replacement-in-v8)
  • 最优化编译器的使用条件(主要的)
    1. 未优化的语法不在函数/循环中使用
      • debugger语句,eval语句,等等
    2. 如果有“use asm”语句,则使用TurboFan
      • 只有TurboFan可以优化asm.js
    3. 如果有Crankshaft不支持的语法,则将使用TurboFan
      • try catch,with等
    4. Crankshaft被默认使用
      • 这是2016年的情况,现在Crankshaft被移除。

Crankshaft

Crankshaft的特点

  • Type-feeback
    • 通过使用runtime-profiler收集的信息,确定类型来加快速度
    • 最终生成的优化代码包含一个类型检查
    • 当它不能确定类型时,它将返回到优化前的代码。
  • Hydrogen (optimization by high-level intermediate representation (HIR))
    • AST以SSA格式表示
    • 各种优化,比如将loop内部不变的变量移到loop外。
  • lithium(Optimization by Low-Level Intermediate Representation (LIR))
    • 快速的寄存器分配算法
    • 依赖CPU的优化,code生成

因为,它是一种与当前问题没有太大关系并且不存在于最新代码中的机制,因此省略了细节。
如果需要了解细节,可以参考这篇文章:http://nothingcosmos.github.io/V8Crankshaft/src/blog.html

TurboFan

参考资料:
https://github.com/v8/v8/wiki/TurboFan
https://speakerdeck.com/brn/source-to-binary-journey-of-v8-javascript-engine
https://docs.google.com/presentation/d/1H1lLsbclvzyOF3IUR05ZUaZcqDxo7_-8f4yJoxdMooU/edit#slide=id.p

TurboFan全览

下图显示了截至2018年TurboFan的整体情况

TurboFan的特征

  • Graph Building
    • 从AST创建一个JavaScript节点的graph
      • JSAdd,JSCallFunction,JSLoadProperty,IfTrue,IfFalse等等
    • 在making graphs优化
  • Optimization
    • graph的各种优化
  • Code Generation
    • 机器码生成

TurboFan优化

  • src/compiler/pipeline.cc参考
    • inline
      内联函数调用
    • trimming
      未到达节点删除
    • type
      类型推断
    • typed-lowering
      根据类型将表达式和指令替换为更简单的处理
    • loop-peeling
      取出循环内的处理。
    • loop-exit-elimination
      删除Loop Exit
    • load-elimination
      删除不必要的读取和检查
    • simplified-lowering
      用更具体的值来进行指令的简单转换
    • generic-lowering
      将JS前缀指令转换为更简单的调用和stub调用
    • dead-code-elimination
      删除无法访问的代码


文本框中的文字如下:
细节
出于某种原因,在名为GenerateCode()的函数中执行了对类型和graph的各种优化。
此外,尽管从CreateGraph()调用GenerateCode(),但这些函数原本应该是独立的。(在代码中还有三个独立的部分,job-> CreateGraph(),job-> OptimizeGraph(),job-> GenerateCode())
实际上,在V8的这个时间段中,每个phase都没有完全分离,因为优化和代码生成都是在CreateGraph()函数内部实现的。

Crankshaft/TurboFan检查

  • Crankshaft/TurboFan能够被确认使用,通过–trace-opt

    上面框:大约调用函数10000次
    下面框:Crankshaft被使用


Crankshaft不能对包含with语句的函数进行优化,所以如果你在函数后添加add语句,TurboFan将会被调用。

  • TurboFan还可以通过 –turbo-stats查看优化列表和统计数据

  • Confirm results with d8 –print_code等

    Crankshaft, TurboFan, Inline Caching related, etc. can be confirmed considerably

编译器调用的流程

被调用

  • 参考samples/hello-world.cc
    • 它只涵盖main()

      有各种各样的东西,但最重要的是Compile()和Run()

调用堆栈查看

  • 如何调用Full-Codegen

    • 描述了调用Compile函数时的转换
    1. 如果它是最新的源代码,它会跳转到ParseProgram()而不是ParseStatic(),但它不会有太大的改变,因为它最终会达到AST方向。
    2. 如果它是最新的源代码,它将跳转到GenerateUnoptimizedCode()而不是CompileBaselineCode(),并使用Ignition注册编译作业。
  • 调用Run()函数时的转换如下

    CALL_GENERATED_CODE是一个宏,通过这个宏,在跳转到由Full-Codegen生成的机器语言(JIT)的阶段,优化编译器不会被调用

  • 如何调用Crankshaft / TurboFan
    • Called after runtime-profiler decides whether optimization is possible
      • Optimization availability determination is done automatically in another thread during Run ()
        • 因此,使用V8作为库的程序员基本上不会主动调用执行优化的函数
        • 当然,开发V8的程序员有可能自己故意调用一个根据选项执行优化的函数,但你在exploit的角度不用去考虑它。


在确定使用UseTurboFan()的优化编译器后,将创建Crankshaft / TurboFan作业。
之后,job->CreateGraph()实际触发优化编译

阅读V8的源码

在exploit中,您还需要阅读源代码.
源代码(samples/hello-world.cc),我们还介绍了用于阅读和调试源代码的重要概念

顺便说一下,ToLocalChecked()是一个no-NULL检查函数。

本节介绍以下内容
我只是总结了我不知道的概念
从exploit的角度来看,它们都不是那么重要,但是最好从源码上了解

  • Handle/HandleScope
  • Context
  • Isolate
  • Platform
  • Interpreter
  • blob
  • ICU
  • third_party
  • tools

参考资料:https://github.com/v8/v8/wiki/Embedder's-Guide

Handle/HandleScope

  • Handle
    • 要启用GC跟踪,指针包装类型
      • 为了对应任何类型的指针,请使用C++模板
      • 在源代码中,所有Object都使用此Handle类型进行管理
      • GC有可能移动Object的位置

        即使GC移动该Object,由于handle不移动,所以没有不一致
    • 常用Handle
      • Handle
        • Abstract class
      • Local
        • Temporary Handle, 保留在stack上
        • 使用后面将介绍的HandleScope进行生命周期管理
      • MaybeLocal
        • 它与Local相同,但在使用前检查它是否为空
      • Persistent
        • 一个persistent Handle,保留在heap上
        • 代码编写器使用Persistent::Reset()管理生命周期
  • HandleScope
    • handle总结
      • Temporary Handle such as Local , MaybeLocal
      • 在声明HandleScope时,块中的每个handle都会自动关联
    • 当HandleScope超出范围时,它会处理释放handle
      • 返回函数时,结束{}时,等
      • 用所有使用的handle来描述释放处理是低效的
      • 使用HandleScope的析构函数,GC负责实际的释放处理
    • 参考以下的文件
      • include/v8.h,src/handles.h

Context

  • 在一个V8实例中创建多个执行环境的机制
    • 您可以在一个线程中同时运行彼此独立的JavaScript代码
  • 每个Context对象都有一个全局的Root-Object


左边:每个context都有一个Root-Object,并且彼此独立(在本例中,context是嵌套的,但Root-Object正确切换)
右边:总之,它实现了环境的切换。 我们希望分别通过window,iframe和extended script来独立保护环境。所谓的origin也是在Context中定义的,并且从一个Context到另一个Context的访问不能被默认完成。

Isolate

  • Instance of V8 itself
    • context是在同一个instance中实现不同的执行环境
    • 当你想运行自己的多个实例时使用Isolate
      • 为了适应多线程

Platform

  • It seems to define the operating environment (it seems)
    • 线程相关
      • 决定后台线程和前台线程
      • 管理线程池
    • 任务队列管理
    • 事件追踪

我没有很好理解,因为没有真实的信息

参考

  • include/v8-platform.h
  • src/libplatform/default-platform.cc

Interpreter

  • In V8, two Interpreters are prepared
    • d8
      • 构建src/d8.cc,可以用参数指定各种选项
      • debug-shell d8 in the sense of V8
      • 如果你不用一个文件作为参数去运行它,它将作为interactive interpreter运行。
      • 当文件被指定为参数时,它将被解析为JavaScript并执行
    • shell
      • 构建samples/shell.cc
      • 主要操作与d8相同,但功能减少且轻量级
      • 它可以用于对CTF中的V8的jsp问题进行调试

blob

  • 关于snapshot文件
    • V8在初始化时在内部生成内置JavaScript代码
      • 尽管这些代码可以每次使用时进行编译,但是效率不高。
    • 所以在编译阶段预先准备好他们。
      • 它只需要在启动时读取,因此初始化变得更快
      • 在构建V8时,他们一起生成
    • snapshot可以在程序内部/外部进行
      • 当snapshot文件被放置在外部的时候,就是blob
      • There are two of natives_blob.bin and snapshot_blob.bin

ICU

third_party

  • 和v8捆绑的工具(=被用来构建等)
    • icu, binutils, llvm, etc.
  • 它可以根据需要进行更换
    • 在使用Ubuntu 16.04进行构建时,由于其下属的ld.gold报错,因此通过系统链接程序的符号链接(/usr/bin/ld.gold)
      • ld.gold是Google在2012年左右制作的ld的高速版本
    • 使用GYP_DEFINES,您也可以替换环境变量

tools

  • GDB扩展命令已准备好用于调试目的
    • gdb-peda$ source tools/gdbinit
    • gdb-peda$ source tools/gdb-v8-support.py
    • 如果你这样做,你可以增加gdb命令
      • 也许你可以使用Ok
    • tools/ Because there are various other things under his eyes
  • 但是,由于我们的案例是在2016年,因此需要进行一些修改
    • gdbinit
      • 由于出现与命名空间相关的错误,因此使用“’修补它即可(???)
    • gdb-v8-support.py
      • 由于python 3语法错误出现,所以可以在打印语句OK中放入括号
    • 此外,该文件的内容在最新的V8中已更改
      • 我还没有确认这一点。
  • For example, v8print and job commands display HeapObject cleanly
    • 对象的结构将在后面描述
    • 由于map有各种标志,最好在这里查看
  1. 例如,[0xdeadbee,0xdeadbeef,“hoge”]
    显示FixedArray(减去0x14,因为它指向FixedArray的第一个偏移量)
  2. 我试图显示FixedArray的Map的内容
  3. 实际上,我不必费心使用v8print命令,但我觉得直接调用内部函数可以调用__gdb_print_v8_object(address),如果我传入一个奇怪的地址,我无法通过SEGV恢复它,所以我直接看内存,它会更安全。

其他

  • 其他的细节
    • Macro-intensive use
      • 如果对源代码进行grep找不到定义,则可能有宏
      • 寻找宏的定义是很好的(在源码中的某处#define 〜)
      • In particular, many macros based on the token concatenation operator (##) are used
        • #define HOGE(name,type) hoge_name_##type();
        • 当我找不到它时,一般会有很多模式
    • __asm __(“int 3”)不能嵌入到IC或机器语言生成系统的功能中
      • 做一个blob作为构建过程的一部分
      • 目前这些代码似乎被使用,并且在很多情况下构建失败
    • namespace
      • i是v8::internal的别名
        • namespace i = v8::internal;(src/globals.h)
    • Changes will be made immediately
    • 以下是非常有用的
      https://github.com/danbev/learning-v8/blob/master/README.md

关于V8的GC

参考资料

https://github.com/thlorenz/v8-perf/blob/master/gc.md
https://github.com/joyeecheung/v8-gc-talk
https://www.youtube.com/watch?v=DSBLAG2IvsY

垃圾收集器(GC)

  • 另一个重要组件是GC
    • 一种在V8中单独管理JavaScript对象(称为HeapObject)的机制
      • 如何检测废弃的对象并自动释放它们
    • 使用与Linux heap不同的区域
  • GC区域

    • 除heap以外,还有多个由mmap存放的区域
    • V8内部使用的各种HeapObject被保留在这个区域
  • heap区域

    • 如果不是js object(=不应该由GC管理),用c++语言管理普通object
    • 虽然是一个JavaScript object,但有些例外,存放在heap而不是HeapObject(例如JSArrayBuffer的BackingStore)

GC中有2种generation(= regions with different management methods)

  1. Young Generation
  2. Old Generation

根据GC中object的生存时间,它被分为两类generation ,Young/Old (and New/Old described later)
这不是关于V8版本之间的区别
除此之外,还有一些区域不属于任何一个generation
为了方便起见,它被写为Other,但是其实是关于Large Object Space

在源代码中,有些地方包含Old generation的large object space的描述,但基本上认为它们是不同的东西

Young Generation

  • New Space

    • 新创建的object被保留在这里,并且受到GC管理
    • Almost all objects
    • code object,map object和large object被排除在外
      • 除了看源码之外还有其他的东西,但是从exploit的视角看不重要
  • The GC algorithm is Cheney’s algorithm

    • 为了使用这种算法,它进一步分为两个区域

      • ToSpace
      • FromSpace
    • 这个GC在源码里被称为Scavenge

  • Cheney’s algorithm
    • Each object is reserved from the beginning of ToSpace
    • 当memory exhaustion(空间用罄)时候,GC被调用
    • 主线程的操作(Javascript执行的线程)被暂停
    • Switch To Space and From Space
    • Actually dealing with pointer swap (flip)
    • 仅将living object复制到To Space
      • 首先,确保live (= alive), copy one starting object。
        • 有各种各样的root objects (such as global objects, built-in objects, local objects within the scope of living, etc. )
          有各种各样的说法,详情请参阅heap/heap.cc的IterateRoots()。
        • 从Old side可以访问的object (由后面讲解的Write Barrier mechanism管理), etc.
      • 顺次复制living的object。
        • 还有一些要复制到old generation的object
          正如我们后面将会看到的那样,两次在young generation的GC中幸存下来的对象,被复制到old generation的空间而不是复制到ToSpace
      • 完成后,重新选择root并重复复制。
    • 再次分配之前未分配完成的obj-e
      • From Space中还有garbage存在,但是因为我们不会再次使用它们,所以无所谓。
      • 之后,每次GC发生时,都会重复上面这一系列的流程

Old Generation

  • old space
    • long-lived objects存放的区域
      • New Space中, 在两次GC之后存活下来的object
        • 更多细节参考Heap::ShouldBePromoted()
      • old space发生GC的频率比new space少(取决于使用过程)
        • 如果一个object被移动到old space,该object不会受到GC更改layout的影响
  • code space
    • 仅适用于JIT的code object
      • 由于code object是RWX,因此它从一开始就保留在此区域中
        • 由于它是JIT代码,因此不仅要读取(R)写入(W),还要执行(X),因此memory permissions与其他的地方不同。
  • Map Space

    • 仅Map object
      • 出于GC效率的考虑,Map object从一开始就位于此区域
  • old generation的GC算法是Mark-Sweep-Compact

    • 除New Space区域以外的所有算法
    • 由于它与Exploit无关,因此省略了详细信息

Other

  • Large Object Space
    • 保留600KB或更大的object的区域
      • 它由mmap直接分配
      • 如果有多个存放区域,请使用链表进行管理
      • 它不在GC中移动

Write Barrier

从Exploit的角度来看

  • In case of exploit repeating memory allocation/release
    • When GC runs at Young Generation, memory layout collapses
      • It is more stable to intentionally activate the GC in advance and move the object as much as possible to Old Generation
      • In order to cause GC, it is sufficient to secure a lot of memory (= non-large) in detail
  • In case of heap BOF type exploit
    • Each object does not have metadata for GC (concrete example will be described later)
      • Meta data such as size and prev_size in the malloc chunk are not particularly used for GC applications
      • Since the reserved JS object is used like a structure, there are various information inside the JS object, but there are no headers in the JS object itself, and each JS object is secured consecutively
    • In other words, the technique of the metadata destroying system which is well-known in the Linux heap basically does not exist on the GC

v8对象模型

参考资料

http://steps.dodgson.org/bn/2008/09/07/

V8的object

  • Object
    • v8自己创建的各种各样的类
      • 和GC合作
    • 针对C++类结构制作一个触发器
      • 例如,V8的object没有成员变量
      • 它既没有虚函数,也没有构造函数/析构函数
    • 细节参考src/objects.h,src/objects-inl.h等
  • Exploit
    • 了解每个object的内存结构非常重要
    • 在本文件中,我们将主要讲述下面的内容

      继承关系

Object和Tagged Value

Object

  • Object
    • 它由以下两种类型组成
    • Smi(Small Integer)
      • 整数值
        • 整数由带符号的31位范围表示(在32位环境的情况下)
        • 整数由带符号的32位范围表示(在64位环境的情况下)
    • HeapObject
      • 除整数值之外的其他类
        • 也适用于不能在Smi范围内表达的整数
          • Double value and hold at the end of the pointer (= HeapNumber object)
        • 始终有一个指向Map的指针
      • 由于HeapObject基本上由GC管理,因此它位于GC区域(它不存放在堆区域)

Smi

如果一个成员的值是一个整数,那么存储它的速度会更快
这就是使用Smi的原因(我认为这是原因)

  • 对于使用指针来创建一个整数对象(B)的实现,如图
    指针必须被追踪一次,内存访问两次(慢)

  • 对于省略了指向整数对象(B)的指针并且整数直接存放在内部的实现,如图
    指针应该指向的整数值在V8中被称为Smi
    没有必要跟随指针,内存访问执行一次(快速)

Tagged Values

  • Tagged Values

    • 同时表示指向Smi和HeapObject的指针的机制
      • 但是,不可能区分它们是整数值还是指针
        • 低1位(LSB)是一个标志
  • Smi(=Object)

    • 如果LSB为0,则可以通过右移1位获得原始值
    • 如果LSB为0,则可以通过右移32位获得原始值
  • 指向HeapObject的指针

    • 32位
    • 64位

      由于GC上的chunk在32位环境中的4字节对齐,64位环境中是8字节对齐的,因此LSB始终为0。也就是说,当它存储在内存中时,将其LSB设置为1即代表指针。

HeapNumber

  • 对象的值为double
    • 数字表达式不能在Smi范围内表达
    • 继承Object, HeapObject
      • 内存结构如下所示(64位环境下)

        V8的HeapObject完全没有任何成员变量,它完全由偏移量独立表示。
        为了画起来方便,我们将其视为变量名称,并如右图所示表示(对于后续幻灯片也是如此)
  • 实际演示
    • Smi值(0xdeadbee)和double值(0xdeadbeef,由于它大于0x7fffffff,非Smi)存放在数组中

      搜索
  • 由于0xdeadbee是Smi,因此可以通过在内存中搜索,来查找存储在数组中的值。(换句话说,直接看数组里对应的值就行了)
  • 0xdeadbee(Smi)之后的元素应该是0xdeadbeef(HeapNumber)
    0x41ebd5b7dde00000是0xdeadbeef的double值表示
  • HeapNumber对象和其他对象连续,保证没有任何间隙

PropertyCell

  • Object meaning variable
    • 继承Object,HeapObject
      • 内存结构如下(在64位环境的情况下)
  • 实际演示
    • 存放Smi值(0xdeadbee)
    • 使用0xdeadbee搜索此PropertyCell的在内存中的位置
    • 尝试覆盖变量的值
    • 由于0xdeadbee是Smi,它的值可以通过在内存中搜索找到。

    • 更改为字符串
      • 如果你像以前一样检查相同的地址,则kValueOffset所保持的值会更改
      • 指向的地址是一个表示“hoge”的String对象(String对象的细节将在后面描述)

String

  • 保存字符串的对象
    • 继承Object, HeapObject, Name
      • 内存结构如下(在64位环境的情况下)
  • 实际演示
    • 存放在数组中的字符串“hoge”,“fuga”
    • 用0xdeadbee查找这个数组的内存位置
    • 由于0xdeadbee是Smi,因此你可以发现这个在数组中的值,通过在内存中搜索。基于此,确定数组的内存位置
    • 跟在0xdeadbee(Smi)之后的元素应该是一个String对象,如“hoge”或“fuga”
    • “hoge”和“fuga”连续存放,没有缺口。

Oddball

  • 表示特殊值的对象,例如true,false,undefined

    • 继承object,HeapObject
      • 内存结构如下(在64位环境的情况下)
  • 实际演示

    • 确保true,false等在数组中
    • 用0xdeadbee查找这个数组的内存位置
    • 0xdeadbee(Smi)的下一个元素应该是一个Oddball对象,如true或false

  • 顺便说一下,种类的定义就是这样

JSObject

参考链接

https://v8project.blogspot.jp/2017/08/fast-properties.html

JSObject

  • 表示JavaScript对象的对象
    • 继承自Object,HeapObject,JSReceiver
    • 对于想要了解element的properties和description的人,请参阅上面给出的参考链接
  • properties
    • It is called NamedProperties and manages elements accessed by name. The entity is FixedArray
    • Management when an object has a property (like a.x)
  • element
    • It is called IndexedProperties and manages elements accessed by index. The entity is FixedArray
    • Management when an object has an index (like a[0])

JSFunction

  • Object holding JavaScript function

    • 继承Object, HeapObject, JSReceiver, JSObject
      • 内存结构如下(在64位环境的情况下)
  • 实际演示

    • 存放function f()在数组中
    • 用0xdeadbee查找这个数组的内存位置

    • kCodeEntryOffset is a pointer to the JIT code (RWX area), many strategies to realize arbitrary code execution by writing shellcode before this

JSArray

  • Object holding a JavaScript array
    • 继承Object, HeapObject, JSReceiver, JSObject
      • 内存结构如下(在64位环境的情况下)
  • 实际演练
    • 由于0xdeadbee是Smi,因此可以通过在内存中搜索来查找存储在数组中的值。 基于此,查找数组的内存位置(因为有一些候选项,请小心)

    • 如果增加数组的元素,它将自动扩大
      • 第三个和第四个元素被添加到只有两个元素的数组中
    • 当元素的数量增加时,它会扩展长度(FixedArray存放到另一个位置,并且kElementsOffset所保存的指针改变)
    • 顺便说一下,有很多0x186e00404369代表TheHoleObject的地址(Oddball的kind = 2意思是void)
  • 注意
    • 在一个数组中,有时会存储一个double值的情况
      • 它是一个非Smi范围,但它被存储为一个double值而不是HeapNumber地址
      • Smi范围,但存储为double值而不是Smi表示
    • Perhaps, it seems to be to decide the type of the entire array and speed up it

JSArrayBuffer

ArrayBuffer and TypedArray

  • Originally ArrayBuffer
    • 一个可以直接从JavaScript访问内存的特殊数组
      • 但是,ArrayBuffer仅准备一个内存缓冲区
      • BackingStore——可以使用TypedArray指定的类型读取和写入该区域,例如作为原始数据数组访问的8位或32位内存
      • 为了实际访问,有必要一起使用TypedArray或DataView
        • TypedArray是low function,但因为它不会执行额外的操作,所以访问速度很快。
        • 对于Exploit,最好不要做额外的事情(当发生意想不到的事情时很麻烦),因此比起DataView,我们更多的使用TypedArray。
    • 使用例子 (TypedArray版本)
      • 创建方法1,仅指定长度,初始化为零
        t_arr = new Uint8Array(128) //ArrayBuffer被创建在内部
      • 创建方法2,使用特定值初始化
        t_arr = new Uint8Array([4,3,2,1,0]) //ArrayBuffer被创建在内部
      • 创建方法3,事先构建缓冲区并使用它
        arr_buf = new ArrayBuffer(8);
        t_arr1 = new Uint16Array(arr_buf); //创建一个Uint16数组
        t_arr2 = new Uint16Array(arr_buf, 0, 4); //或者,您也可以指定数组的开始和结束位置
    • ArrayBuffer可以在不同的TypedArray之间共享
      • 它也可以用于double和int的类型转换
        • 类型转换的意义在于改变字节序列的解释,而不是转换
        • 就像C语言的Union
      • BackingStore——可以使用TypedArray指定的类型读取和写入该区域,例如作为原始数据数组访问的8位或32位内存
      • ①预先准备ArrayBuffer
        var ab = new ArrayBuffer(0x100);
      • ②向ArrayBuffer中写入一个Float64的值
        var t64 = new Float64Array(ab);
        t64[0] = 6.953328187651540e-310;//字节序列是0x00007fffdeadbeef
        –>当某些地址在V8上泄露时,通常在大多数情况下被迫将其解释为双精度值,为了正确计算偏移量等,需要将其转换为整数值。 对于完成该转换,ArrayBuffer是最佳的
      • ③从ArrayBuffer读取两个Uint32
        var t32 = new Uint32Array(ab);
        k = [t32[1],t32[0]]
        –>k是6.953328187651540e-310,将字节序列按照4个字节去分开,然后解释为Uint32,于是得到:
        k=[0x00007fff,0xdeadbeef]

JSArrayBuffer

  • 持有ArrayBuffer的对象
    • 继承Object,HeapObject,JSReceiver,JSObject
      • 内存结构如下(在64位环境的情况下)
  • 实际演示
    • 存放TypedArray
    • 使用长度0x13370搜索ArrayBuffer的内存位置
    • 在V8中,对象通常被存放在由GC管理的mapped区域,然而BackingStore是一个不被GC管理的区域,并且被存放在heap中(在图中,可以看到malloc块有prev_size和size成员)
      此外,由于它不是由GC管理的HeapObject,因此指向BackingStore的指针不是Tagged Value(末尾不能为1)
    • 虽然在ArrayBuffer中描述了大小,但如果将此值重写为较大的值,则可以允许读取和写入的长度,超出BackingStore数组的范围。
    • 同样,如果您可以重写BackingStore指针,则可以读取和写入任意内存地址,这些是在exploit中常用的方法。

Numerical conversion tool (It is original work)

  • 在开始JavaScript利用之前
    • 频繁转换unsigned long long <-> double
    • 预先制作转换工具很好
    • 我制作了以下工具(我不会使用float,但只是为了确保)
  • 源代码看起来像这样

实践

攻略方法

  • 模式1和2,策略如下
  1. 创建一个用于调试的js环境版本
    如果有一个包含漏洞的patch,hit和build它。
  2. 分析patch以确定哪个patch适用于哪个进程
    Full-Codegen, Crankshaft, TurboFan, Ignition, AST, IC, …
    Full-Codegen and Crankshaft do not exist in V8 as of 2018 (see below)
  3. 编写利用漏洞的js代码段
    Think JavaScript code that causes patched parts to pass and causes bugs
  4. 创建一个任意地址读/写的原语
    主要使用ArrayBuffer和TypedArray
  5. getshell
    由于这是Pwn类别的问题,getshell是第一目标。
    在JIT区域嵌入shell代码经常被使用

初步调查

  • Plaid CTF 2016-Pwnable 666pts -js_sandbox
    • 访问


http://js.pwning.xxx:27251/files/problem.patch
https://developers.google.com/v8/
http://js.pwning.xxx:27251/file
提供了5个文件作为capture的必要文件。

  1. libc.so.6
    当前的libc(ubuntu14.04)
  2. natives_blob.bin
    shell操作所需的文件
  3. problem.patch
    有漏洞的v8 patch
  4. shell
    构建samples/shell.cc用于本地测试
  5. snapshot_blob.bin
    shell操作所需的文件

shell文件

shell (and *.blob)用作debug的目的
distribution file应该包含与problem服务器相同的源文件

  • V8解释和执行的是JavaScript
    • 因此,exploit也只需要用JavaScript编写
  • 对于相同的输入,V8应该表现相同
    • 如果你可以通过shell来exp v8,你也可以通过Web服务器exp v8

patch分析

  1. 启用PIE,FORTIFY_SOURCE,stack canary
  2. PIE,FULL-RELRO启用
  3. 使read和load函数无效
    print,read,load,quit和version等功能都是在sample/shell.cc中专门定义的,但是经过patch后,read和load时会失效
  4. 从源代码路径,TurboFan相关补丁和猜测

    lhs:左手侧(左侧)rhs:右手侧(右侧)?
    此外,因为函数名称是JSAddRanger,所以可以预料可能是与加法有关的漏洞(?)

Identification of calling conditions

  • 假设被patch的函数是有漏洞的
    • 我想调用这个函数
      • 如果我们不能调用这个函数,我们不能触发漏洞
    • 怎么调用它?
      • 我没有任何提示,我只有一个函数名称
      • 猜测这个函数所在的文件或目录有什么功能
      • 从该函数的调用回溯,找到调用路径。
      • 最终目标是找到读取和调用每个函数的条件。

Google

尝试google搜索函数名称
触及此功能的评论页尤为重要

确认内置漏洞的文件名

  • src/compiler/typer.cc
    • 由于它是src/compiler/下的一个文件,因此它被认为与TurboFan有关

确定来源

  • 检查修补程序周围的代码
    • 看看JSAddRanger()

确定调用路径

  • 到目前为止,做一个总结
  • 寻找调用路径
    • 使用gdb回溯调用栈是最快的方法。
  • 编写测试代码

    • 准备Javascript code去调用TurboFan
      • 通过代码调用函数10000次,由于我想调用TurboFan,所以不要忘记使用with语句
  • 使用gdb运行

    • 如果某些条件不满足,JSAddRanger()将不会调用…
    • In C ++ that does not reach JSAddRanger () in test code, that is, it does not reach the JSAddRanger () in the test code, you can not set a breakpoint unless you specify not only the function name but also the namespace and type to which it belongs. So using nm, it searches for mangled function names and specifies a breakpoint (if PIE is invalid, it is OK even if you set a breakpoint at the found address)
    • 实际上,您无法在测试代码中访问JSAddRanger()
  • 调用JSAddRanger()

    图示第一行是函数原型,第二行是函数定义,看看第三行。
    • 从JSAddTyper()调用。
      • 除非满足某些条件,否则不会调用JSAddRanger()

  • 同时检查JSAddTyper()的调用者
    • 在函数定义中只找到一个地方
      • 由于无法用简单的grep找到它,因此很有可能涉及宏。
        • 追溯更多来源是很麻烦的
    • 在JSAddTyper()上放置一个断点并查看是否能在测试代码中断下来
      • 如果没有断下,努力尝试,阅读源码,进一步回溯
    • 使用gdb运行
      • 在JSAddTyper()上放置一个断点,发现停在断点处
  • 在停止后进行回溯(查看调用栈)
    • 从这个函数名,可以确认JSAddRanger()和JSAddTyper()与优化编译器(TurboFan)相关
    • 由于它是TyperPhase::Run,证明它是一个关于TurboFan优化中“Typer”阶段的函数。
      另外,如果TurboFan进行了优化编译运行,就会发现JSAddTyper()在测试代码中被调用。
  • 您可以在TyperPhase中看到TurboFan的功能
  • 到目前为止做一个总结
  • JSAddRanger()调用条件探索
    • lhs-> IsRange()&& rhs-> IsRange()
    • 首先,代码中出现的Range是什么?
      • 为了知道这一点,我们需要更多地了解TurboFan的优化机制

Typer和Range调查

确定调用条件

  • 编写测试代码
    • 添加AND操作并在gdb下执行
    • 在此之后,在断点处停止
  • 调用路径总结

漏洞理解

  • 补丁周围的代码
  • 从操作实例理解
  • 用make x64.debug -j 8重新编译

    • 在“环境设置”描述的步骤中,我已经预先构建了它。
  • 尝试有趣的测试case

    • 下面的JavaScript代码展示了有趣的结果
    • 如果打了有漏洞的补丁,你会在AND操作之后得到新的范围信息,而这个范围信息是错误的
    • 但是,由于该信息仅用作类型提示,因此它不会对选择Word32的类型造成影响,因为它可以用32位表示[0,24]和[0,16]。在这个例子里,f函数正常应该返回24作为结果

解法

https://gist.github.com/sroettger/d077d3907999aaa0f89d11d956b438ea

漏洞利用

  • 通过假的range信息,你能做什么?
    • 这里的目标是创建任意地址读/写的原语
    • 具体来说,就是伪造一个很大的array的length
      • 许多JavaScript引擎的漏洞利用都是使用这种方法。
    • OOB-RW (Out-Of-Bounds-Read/Write access)
    • 如果在array之外读写数据,并劫持JSArrayBuffer的BackingStore的指针,就获胜。
  • 如何用OOB-RW创建任意地址读/写的原语
    • 内存排布如下
    • 如果可以模拟长度,就可以通过越界访问来更改JSArrayBuffer的BackingStore的指针
      基本形式如下
  • 通过range来实现我们的目的(改大array的length)
    • 正确的尝试
      • 首先用范围信息创建一个值
      • 使用这个值来创建一个array
    • 测试代码看起来像这样
      • 变量sz具有范围信息
    • 修改源代码为有漏洞的版本
    • make x64.debug -j 8再次编译
  • 在gdb下运行,检查内存
    • 搜索0xdeadbee将命中3次,其中这个是一个数组(= FixedArray)
    • 通过将标记值1加到FixedArray的地址上,然后进行搜索
    • 找到的地址应该是JSArray
      一个很重要的图


      通过check我知道我能伪造FixedArray的长度,因为如果不打patch,上下的值应该都是0x18
  • 这意味着什么?
    • 我们打算创建一个长度0x18元素的数组,但实际上只准备了长度0x10元素的数组

      虽然它与基本形式稍有不同,但如果您仅信任此长度(0x18),并将这个长度的值写入FixedArray,则您能够读取和写入的数据,将会超出原本仅有0x10的FixedArray
      实际上想用只有0x8个字节的数据来覆盖backing store ptr是十分困难的,我们将在后面介绍更好的方法。

参考解说:typed-lowering

  • 为什么会出现这种情况?
    • 使用range信息的部分在哪里?
      • 在typer phase旁边的typed-lowering phase
  • typed-lowering

    • 它似乎使用type information来optimize graph
    • Follow until array association comes out






  • 用printf调试确认

编写exp

  • 你现在在做什么?
    • Array length伪造
  • 我们将会考虑编写exp
    • 流程如下
      1. 伪造Array length
      2. 伪造ArrayBuffer
      3. Identify function object
      4. 在JIT区域嵌入shellcode

伪造Array length

  1. 顺次排列两个FixedArray(其长度通过range漏洞伪造)
    由于这些FixedArrays的范围是伪造的,因此它们可以在数组之外进行读写操作.

  2. 每个double值存储在Element [0]中,并且数组类型被识别为double类型(即FixedArray被转换为FixedDoubleArray)
    • 在FixedArray变成FixedDoubleArrayed之后,内存的布局会发生变化并且变的很麻烦,所以让我们先提前认识它是一个只有double类型元素的FixedDoubleArray。
      这也确保了FixedDoubleArray 1和2连接

  3. 使用OOB-W漏洞更新FixedDoubleArray1中的FixedDoubleArray 2的kLengthOffset

    如果连续排列,FixedDoubleArray 1的元素[17]应该是kLengthOffset。
    通过此更新,FixedDoubleArray 2可以越界读取和写入了。

    其实我们不能直接访问Element [17]。
  • 状态
    在JSArray中,长度信息首先存储在两个地方。JSArray::kLengthOffset(= 24)和FixedArray::kLengthOffset(=16)
  • 原因
    当存储到一个数组时,它使用JSArray::kLengthOffset和FixedArray::kLengthOffset来进行索引的范围判断(可以确认的是,如果你通过gdb上的rwatch设置了一个内存访问断点,它将以任一方式停止)
    17超出了FixedArray::kLengthOffset的范围,所以我们扩展了数组的长度并在其他地方预留了一个新数组。这不会成为OOB-RW。
  • 解决方法
    According to Write-up, it seems to be enough to substitute twice in the for statement as follows
    1
    2
    for(var i=0;i<24;i+=17)
    Element[i]=value;

称为KeyedStore IC的IC对应于数组元素中的存储,KeyedStoreIC是状态直接转换为(0)->(1)的IC,IC在第二次访问时已处于活动状态.
当通过触发IC来处理时,它不会与JSArray::kLengthOffset或FixedArray::kLengthOffset进行比较(However, this is not exactly confirmed here, and only JSArray :: kLengthOffset comparison may be done on the code embedded in JIT)

伪造ArrayBuffer

  1. 将ArrayBuffer放置在FixedDoubleArray 1,2之后

  2. 由FixedDoubleArray 2的漏洞搜索kByteLengthOffset和kBackingStoreOffset的偏移量

    • 它每次从FixedArray2的元素[16]中读取一个元素,并根据是否包含假定值进行搜索。 您可以在kByteLengthOffset(= ArrayBuffer拥有的BackingStore的长度)中放入一个特征值并搜索它(如果向此添加1,kBackingStoreOffset的偏移量也是已知的)
    • ab_off表示从FixedArray 2(代码中的arr [1])中看到的作为kByteLengthOffset位置的元素索引,
  3. 更新来kByteLengthOffset和kBackingStoreOffset的偏移量

    • 如果设置元素[kByteLengthOffset_offset] = 0xfffff0,
      元素[kByteLengthOffset_offset + 1] = rw_addr。
      请记住在步骤2-2中获得的偏移量,并且在ArrayBuffer读取和写入rw_addr,也就是说,它几乎变成了任何内存读/写的原语。
    • 通过重写kBackingStoreOffset的值,您可以读取和写入任意地址,因此在利用时可以将其作为RW原语的函数来实现。
      另外,关于i2_to_d()的描述被省略了,它是一个函数,可以使用ArrayBuffer将Uint32转换为double。

Identify function object

  1. ArrayBuffer后面跟着FixedArray 3,它有一个适当的函数对象作为元素

    选择7作为特征值没有特别的意义。 只要选择你喜欢的长度,然后尝试。

  2. 从FixedDoubleArray 2中,使用漏洞探索FixedArray 3的Element的偏移量,获取函数f的对象地址。

    • 如果一个值连续出现kLengthOffset次(如图中是7),则可以推断出它可能是包含函数f的对象地址的元素的偏移量。

在JIT区域嵌入shellcode

  1. 通过将函数f的对象地址放入kBackingStoreOffset并读取第七个元素,获取kCodeEntryOffset中的JIT地址
  2. 将该地址放在kBackingStoreOffset中,用shellcode覆盖JIT区域,然后调用函数f()

exploit

  • I am rewriting a part of the author’s write-up

  • Execute exploit code with V8 sample-shell
    • 你可以确认/bin/sh启动
    • 虽然以上是针对自建shell执行的,即使对distributed shell执行了exploit代码,也应该启动/bin/sh
    • Then replace it with the shellcode to be backconnected, then try exploit to the production is OK
  • 除了本文中讨论的解决方案之外,PPP还使用GC实现了另外一种writeup

Bonus Other JavaScript issues and links

V8

SpiderMonkey

Chakra

WebKit-JSC

v8 exploit study

SpiderMonkey exploit study

WebKit-JSC exploit study