msgbartop
PHP语言, PHP扩展, Zend引擎相关的研究,技术,新闻分享 – 左手代码 右手诗
msgbarbottom

27 Sep 10 PHP stream未能及时清理现场导致Core的bug

同事发现一个在使用set_error_handler的时候, 能100%重现的core, 提炼后的重现代码如下(环境必须不能访问internet):

<?php
function err_handler(){
    exit;
    return true;
}

set_error_handler('err_handler');
$client = file_get_contents("http://www.laruence.com/ServiceNoWse.asmx?WSDL");

这段代码, 放在webServer中, 第一次访问不会有事, 第二第三次的时候就会出core.

gdb跟踪以后发现, core出在php_stream_display_wrapper_errors函数中, 对err_stack中的错误信息字符串做处理的时刻, core的堆栈如下:

#0  0x000000302af6ff20 in strlen () from /lib64/tls/libc.so.6
#1  0x0000002a989d97c1 in php_stream_display_wrapper_errors (wrapper=0x2a98e884a0, path=Variable "path" is not available.
) at /home/huixc/package/php-5.2.14/main/streams/streams.c:151
#2  0x0000002a989dca22 in _php_stream_open_wrapper_ex (path=0x76e7c8 "http://www.laruence.com/ServiceNoWse.asmx?WSDL", mode=0x2a98ae3087 "rb", options=8, opened_path=0x0,
    context=0x76e808) at /home/huixc/package/php-5.2.14/main/streams/streams.c:1893
#3  0x0000002a98966541 in zif_file_get_contents (ht=-1729541984, return_value=0x76e738, return_value_ptr=Variable "return_value_ptr" is not available.
) at /home/huixc/package/php-5.2.14/ext/standard/file.c:541
#4  0x0000002a98a2c05e in zend_do_fcall_common_helper_SPEC (execute_data=0x7fbfffca30) at /home/huixc/package/php-5.2.14/Zend/zend_vm_execute.h:200
#5  0x0000002a98a2b671 in execute (op_array=0x769890) at /home/huixc/package/php-5.2.14/Zend/zend_vm_execute.h:92
#6  0x0000002a98a0c734 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/huixc/package/php-5.2.14/Zend/zend.c:1134
#7  0x0000002a989c965d in php_execute_script (primary_file=0x7fbfffef00) at /home/huixc/package/php-5.2.14/main/main.c:2036
#8  0x0000002a98a9bd36 in php_handler (r=0x8f1ba8) at /home/huixc/package/php-5.2.14/sapi/apache2handler/sapi_apache2.c:639

经过半个多小时的跟踪, 终于找到原因

是因为, 在PHP中, 对于exit, 其实是借助了set/longjmp来实现用户脚本退出以后, 到达收尾工作, 而对于出错代码出是根据wrapper的err_count计数来确定有多少错误信息要输出.

并且, 在输出完错误信息以后, 清空wrap的错误信息, 置零错误计数.

void php_stream_tidy_wrapper_error_log(php_stream_wrapper *wrapper TSRMLS_DC)
{
    if (wrapper) {
        /* tidy up the error stack */
        int i;

        for (i = 0; i < wrapper->err_count; i++) {
            efree(wrapper->err_stack[i]);
        }
        if (wrapper->err_stack) {
            efree(wrapper->err_stack);
        }
        wrapper->err_stack = NULL;
        wrapper->err_count = 0;
    }
}

而, 因为在现实错误信息之后, 会紧接着触发php_error_docref1, 继而触发代码中设置的error_handler, 而在handler中, 却调用了exit, 最终longjmp到了soap处理时刻设置的跳转点, 造成跳过了对 php_stream_tidy_wrapper_error_log 的调用, 所以导致第二次再来请求的时候, err_count并没有正确的被初始化为零, 还是保持着上次请求的错误数.

于是, 在输出错误信息的时候,

......
         for (i = 0, l = 0; i < wrapper->err_count; i++) {
                l += strlen(wrapper->err_stack[i]); //出core了
                if (i < wrapper->err_count - 1) {
                    l += brlen;
                }
            }

暂时来说, 解决这个办法, 可以在streams的php_stream_display_wrapper_errors函数调用php_error_docref1之前掉后用php_stream_tidy_wrapper_error_log;

我已经提交了 bug, 并提供了PHP-5.2.14的patch
http://bugs.php.net/bug.php?id=52935


分享到:



Related Posts:

Tags: , , ,

12 Responses to “PHP stream未能及时清理现场导致Core的bug”

  1. PHP高级技能之PHP缓存 |

    威武!又找到bug

  2. WOXNhHWXb |

    236533 393638 It

  3. PHP stream未能及时清理现场导致Core的bug | 万维网黑客联盟 |

    [...] 本文地址: http://www.laruence.com/2010/09/27/1754.html [...]

  4. horseluke |

    根据个人经验,在err_handler函数还是需要对部分错误(errno为1, 4, 16, 64, 256, 4096)强制进行exit,否则脚本会因为set_error_handler而继续执行下去,除非遇到CORE ERROR,这样有时会会引发不小的漏洞(特别是某些组件使用trigger_error触发errorno为256错误的时候)。

    不知道对这几个错误进行强制exit的情况下,会不会出现lz所说的问题?
    代码见:http://code.google.com/p/horseluke-code/source/detail?r=135

  5. Thinking In LAMP Blog » Blog Archive » PHP每月通讯(2010年11月) |

    [...] http://www.laruence.com/2010/09/27/1754.html PHP stream未能及时清理现场导致Core的bug [...]

  6. 雪候鸟 |

    @shengyu 唉,没办法了,,,六级考了5次过不了, 嘿嘿

  7. shengyu |

    建议您提高一下英语水平,对于外国人可能比较难看懂

  8. Think In LAMP Blog » Blog Archive » PHP每月通讯(2010年10月) |

    [...] http://www.laruence.com/2010/09/27/1754.html PHP stream未能及时清理现场导致Core的bug 风雪之隅 [...]

  9. PetrovVALENTIN24 |

    недорогие грузчики киев только тут

  10. www.51qsjf.com |

    不错,支持博主

  11. 雪候鸟 |

    @胖子 是啊,,这个验证码不咋地,,,我打算回头再换一个.

  12. 胖子 |

    学习了
    验证码经常是wave

Leave a Reply

*