拥抱php之CVE-2019-11043

拥抱php

这个洞是在discord看见的,只能叹息一声,linux kernel又要往后延期了。作者是打realworld发现的一个0day,有趣,随手一打,服务就crash了,然后0day一枚。

https://bugs.php.net/bug.php?id=78599从作者的描述加上官方的patch。

你能知道所有的东西和PATH_INFO这个fastcgi的参数有关。


   location ~ [^/]\.php(/|$) {
        fastcgi_split_path_info ^(.+?\.php)(/.*)$;
        fastcgi_param PATH_INFO       $fastcgi_path_info;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_pass   php:9000;
        ...
  }
}

之前我对nginx完全一片空白,这个地方我想了很久,fastcgi_split_path_info这个关键字字面意思就是用来分割PATH_INFO的,后面这个正则第一个子匹配给$fastcgi_script_name,第二个子匹配给 $fastcgi_path_info,这里用个换行符这条正则就gg了,nginx里面的.可以用来匹配除换行符以外的字符。有意思是这个正则gg以后,全部的URI都给了$fastcgi_script_name.所以这里的PATH_INFO是个空值。

下面涉及到了php内核问题,没什么好办法,只能调。用作者给的crash_url,我这里并不能crash-.+。

http://127.0.0.1:8080/helloworld.php/%0aAAAAAAAAAAAAAAAAAAAAAAAAAAAA?QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ

按照上面的nginx的规则这里的PATH_INFO是个空值。而SCRIPT_NAME"$document_root/helloworld.php/\nAAAAAAAAAAAAAAAAAAAAAAAAAAAA",这在你调的时候都能打印出来。定位问题所在的函数init_request_info,注意看下面的代码段:

if (script_path_translated &&
				(script_path_translated_len = strlen(script_path_translated)) > 0 &&
				(script_path_translated[script_path_translated_len-1] == '/' ||
				(real_path = tsrm_realpath(script_path_translated, NULL)) == NULL)
			) {
				char *pt = estrndup(script_path_translated, script_path_translated_len);
				int len = script_path_translated_len;
				char *ptr;

				if (pt) {
					while ((ptr = strrchr(pt, '/')) || (ptr = strrchr(pt, '\\'))) {
						*ptr = 0;
						if (stat(pt, &st) == 0 && S_ISREG(st.st_mode)) {
							int ptlen = strlen(pt);
							int slen = len - ptlen;
							int pilen = env_path_info ? strlen(env_path_info) : 0;
							int tflag = 0;
							char *path_info;
							if (apache_was_here) {
								/* recall that PATH_INFO won't exist */
								path_info = script_path_translated + ptlen;
								tflag = (slen != 0 && (!orig_path_info || strcmp(orig_path_info, path_info) != 0));
							} else {
								path_info = env_path_info ? env_path_info + pilen - slen : NULL;
								tflag = (orig_path_info != path_info);
							}

这段代码注释里面也说了这是用来找请求脚本的真实路径。什么意思呢?

SCRIPT_NAME = "$document_root/helloworld.php/\nAAAAAAAAAAAAAAAAAAAAAAAAAAAA";

这里脚本并不是真实路径,需要压缩,一直取最右边的'/'或者'\'来分割字符串,直到找到真实的路径。然后这里有一个操作

path_info = env_path_info ? env_path_info + pilen - slen : NULL;

因为有可能出现这种情况/something/random.php/real_path.php/aaaaaaaaaaaa;
这里本意是应该用来真实的PATH_INFO,但是这里出现了问题,直接把env_path_info当做了判断条件,但是php里面存储空值的fastcgi字段,是用的char[1],什么情况才会出现NULL呢?除非fastcgi的请求里面没有这个字段,但只要你有这个字段,尽管是空值,就给你char[1].

所以这里env_path_info不是个NULL的指针。这就出现问题了,后面的正常逻辑应该是env_path_info指向的是个非空的字符串。这里pilen代表PATH_INFO的长度,当然为0,这里相当于你把path_info往后移了slen个字节。关于这一点我放个图就知道了

可以看到path_info会指向REDIRECT_STATUS这个字符串。继续往后看:

if (tflag) {
	if (orig_path_info) {
		char old;

		FCGI_PUTENV(request, "ORIG_PATH_INFO", orig_path_info);
		old = path_info[0];
		path_info[0] = 0;
		if (!orig_script_name ||
			strcmp(orig_script_name, env_path_info) != 0) {
			if (orig_script_name) {
				FCGI_PUTENV(request, "ORIG_SCRIPT_NAME", orig_script_name);
			}
			SG(request_info).request_uri = FCGI_PUTENV(request, "SCRIPT_NAME", env_path_info);
		} else {
			SG(request_info).request_uri = orig_script_name;
		}
		path_info[0] = old;

这操作太熟悉了path_info[0] = 0;,有点NULL off by one的味道了。这个写一字节null的机会应该怎么用呢?上面的截图,就算在这个REDIRECT_STATUS字符串写NULL似乎没什么用,控制写NULL的偏移是可以来控制,但是当我上面偏移往后看的时候,存储都是fastcgi的字段,怎么写似乎都没什么作用,似乎这个洞用来DOS都没办法做到。

单纯看作者的exp也没什么眉目,但是有一个重要的地方,在运行exp过程中fpm的worker crash过一次。这是我用ASAN检测到的,具体在php编译的时候如何加上ASAN可以按照下面的写

CFLAGS="-O0 -g -fsanitize=address -fno-omit-frame-pointer" LIBS='-ldl' ./configure --prefix=/root/php-7.3-fpm --enable-fpm  --enable-debug

千万别加上--disable-all,这会导致后面用session.auto_start检测回显的时候出错。所以标准库改加上的就加上。

这个时候,其实我有点手足无措,但是有一个地方我有注意到,作者的exp中对于从env_path_info往后偏移的slen一直都是没有变的,这个是值是30,相当于写NULL的地方是固定的。

/helloworld.php/PHP%0Ais_the_shittiest_lang.php?qqqqqqqqqqqqqqqqqqqqqq
				-------------------------------

影响slen的是画横线的地方,这个地方从exp可以看到一直是没有改变过的。完全没有思路的我,只能硬着头皮去看crash的点,从ASAN的bt回溯里面定位到下面地方

static inline char* fcgi_hash_strndup(fcgi_hash *h, char *str, unsigned int str_len)
{
	char *ret;

	if (UNEXPECTED(h->data->pos + str_len + 1 >= h->data->end)) {
		unsigned int seg_size = (str_len + 1 > FCGI_HASH_SEG_SIZE) ? str_len + 1 : FCGI_HASH_SEG_SIZE;
		fcgi_data_seg *p = (fcgi_data_seg*)malloc(sizeof(fcgi_data_seg) - 1 + seg_size);

		p->pos = p->data;
		p->end = p->pos + seg_size;
		p->next = h->data;
		h->data = p;
	}
	ret = h->data->pos;
	memcpy(ret, str, str_len);  //crashed~!!!!!!!!!!!!!!!!!!!!!1
 	ret[str_len] = 0;
	h->data->pos += str_len + 1;
	return ret;
}

memcpy地方出现了Segmentfault,ret是个非法地址。ret来自于h->data->pos,这个h->data是个什么结构呢?

struct _fcgi_data_seg {
    char *pos;
    char *end;
    struct _fcgi_data_seg *next;
    char data[1];
} *

看起来似乎一个内存块管理结构,而且是pos的第5个字节被写NULL了。这就变得很有趣了,env_path_info往后写30字节,怎么能写到这个结构上。反过来想env_path_info-30就在_fcgi_data_seg结构里面。这地方就需要看这个结构是怎么分配了,继续往前看。

可以看到这个结构位于内存块的起始位置,最大可以分配malloc(sizeof(fcgi_data_seg) - 1 + seg_size);考虑到16对齐,这个size应该是4096+32,可以看到逻辑上内存块是个链式结构,用pos和end分布来记录起始和结束,这个char data[1]就是data段的开始。当这块内存不够的时候,会重新分配。

这一切都变的明朗了,储存fastcgi的参数地方内存是动态分配的。初始时候会分配最大的内存块4128,那么会存在这样一种情况,在分配PATH_INFO的时候,前面初始化的内存块用完了。重新开始分配一块内存,存储fastcgi的参数的是个_fcgi_hash_bucket结构,先存储是PATH_INFO这个字段名,然后存储对应的值。我们可以画一下出现这种情况的内存分布:

		char *pos  
		------------- +8
		char *end  
		------------- +8
		char *next 
		------------- +8
		PATH_INFO\x00 
		------------- +10
		\x00            <---- env_path_info
		-------------

你可以算一下这种情况下 env_path_info-30,刚好在pos位置的第5个字节上,一般用户态的地址只用了6个字节,第5字节高字节一般都是随机化的字节,写NULL以后,最后肯定非法了。

这个NULL写的地方现在来看就有意义了。我们可以一直通过增加query的长度,来达到这个效果,最后返回404就代表worker crash了。这样我们就可以控制写的位置,下面来讲一讲具体存储fastcgi字段的过程,只有了解这工程以后,我们才知道具体哪里写NULL。

我们直接来看是怎么取值的,首先会根据fastcgi的参数名取一个hash。

#define FCGI_HASH_FUNC(var, var_len) \
	(UNEXPECTED(var_len < 3) ? (unsigned int)var_len : \
		(((unsigned int)var[3]) << 2) + \
		(((unsigned int)var[var_len-2]) << 4) + \
		(((unsigned int)var[var_len-1]) << 2) + \
		var_len)

具体过程如下:

static char *fcgi_hash_get(fcgi_hash *h, unsigned int hash_value, char *var, unsigned int var_len, unsigned int *val_len)
{
	unsigned int      idx = hash_value & FCGI_HASH_TABLE_MASK;  //这里做的是个映射,映射到0-127
	fcgi_hash_bucket *p = h->hash_table[idx]; //取hash_bucket

	while (p != NULL) { //这里取值是比较严格的hash_value 和参数名要完全对上。
		if (p->hash_value == hash_value &&
		    p->var_len == var_len &&
		    memcmp(p->var, var, var_len) == 0) {
		    *val_len = p->val_len;
		    return p->val;
		}
		p = p->next;
	}
	return NULL;
}

按照上面的思路,如果我们要伪造PHP_VALUE,就得找到和PHP_VALUE hash值和长度相同的fcgi_hash_bucket,相当于要找已经插入到h->hash_table的键值对,mochzz问过我下面字段出现了fastcgi请求,是有什么作用,作用就在这里,可以自己加http_header 直接传不就行了,这样我们就直接插入一个PHP_VALUE位置对应的fcgi_hash_bucket.

0x559b058ea102:	"HTTP_EBUT"
0x559b058ea10c:	"mamku tvoyu"

这个HTTP_EBUT就和PHP_VALUE有相同的hash值和长度。如果不太确定话,可以直接用上面计算hash的方法算一下,所以现在我们需要做就是让我们的PHP_VALUE刚好能覆盖HTTP_EBUT,并且紧随在后面的mamku tvoyu也能被我们构造的ini设置覆盖掉。

具体怎么做呢? 我们NULL off by one,现在不能写在pos的第5字节上了。需要把pos往后移动,最好的情况应该是写第一个字节,把第一个字节置NULL,pos后移。为了能精准的覆盖,这个时候还需要加一个http_header用来作为调节。如下

HTTP_D_PISOS8
==============================D
HTTP_EBUT
mamku tvoyu
...
...
...  <------- 正常pos的指向。

HTTP_D_PISOS8
==============================D <--------------- 写pos第一个字节以后的指向
HTTP_EBUT
mamku tvoyu
...
...
...  

我可以通过调节HTTP_D_PISOS8的长度,让位置的fake PHP_VALUE正好覆盖在HTTP_EBUT上。写个NULL最多往前移0xff个字节,完全可控。这是第二个需要爆破的点。

这也需要调节前面的结构,让PATH_INFO现在需要偏移34而不是30,因为要写pos的第一个字节。这里作者exp里面用的是session.auto_start=1让页面返回Set-Cookie来判断恰好覆盖点,因为每次通过ini设置的语句长度可以不太一样,这个时候在后面填;,第一次在session.auto_start=1;;;;来保证长度足够后面写。因为fpm以worker来调度的,一个worker就是一个进程,进程只要不crash就可以保存之前ini设置。所以这里可以分开来写ini的设置来getshell,这样引用一张mochazz的图,你就可以知道是如何getshell的。

image

mochazz也问我了一个问题,为什么前面加Q是5个的一加来进行爆破的,这里其实很简单,PATH_INFO\x00,长度为10,加5个Q相当于加了10个Q因为fastcgi里面有两个字段 queryrequest_uri都会包含查询字段。

还有这里fpm不只有一个woker,在后面写ini的时候,你需要一个请求发几次,确保同一个worker都能写上去。这里调试的时候,你可以把fpm只开一个worker,虽然我这里开了3个worker,但我用gdb把其他两个都挂起来了,相当于只有一个worker。

只能说作者幸运值和技术值爆表,想要弄个crash也不太容易啊,我为什么没有碰到过这种好事-.-,如果上述分析有不对地方,师傅们都可以指出来,有疑问的都可以一起来探讨!

8 Likes

还有一点小思考:其实这个地方,在看crash点之前,env_path_info+offset这种超边界的移动,ASAN竟然都没有报错,你其实可以预想到在进行内存分配的时候,并不是一个字段一个字段这种粒度的内存分配,可能是一大段内存,而且fastcgi的字段都是未知的,那么肯定存在这样一个内存管理分割的过程,按照php内存管理的习惯,喜欢把内存管理结构放在内存块的开始,我在这里是耗费了一些时间,所以反过来在这里留下一点小思考,供大家参考。