|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #70163 curl_setopt_array() type confusion
Submitted: 2015-07-29 07:15 UTC Modified: 2015-07-30 08:42 UTC
From: andrea dot palazzo at truel dot it Assigned: laruence (profile)
Status: Closed Package: cURL related
PHP Version: 7.0.0beta2 OS: Ubuntu x86_64
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
Solve the problem:
23 - 6 = ?
Subscribe to this entry?

 [2015-07-29 07:15 UTC] andrea dot palazzo at truel dot it

In PHP7 curl_setopt_array is prone to a type confusion due to an unsafe use of the Z_RES_P macro.


from ext/curl/interface.c:2794

 if (zend_parse_parameters(ZEND_NUM_ARGS(), "za", &zid, &arr) == FAILURE) {

   if ((ch = (php_curl*)zend_fetch_resource(Z_RES_P(zid), le_curl_name, le_curl)) == NULL) {

The problem here is that zid is being retrived as a generic zval but then an assumption is made about it being a resource, thus if a numeric value is supplied as first argoment, Z_RES_P would be confused and try to dereference its value as a pointer.


Crash on invalid read access

curl_setopt_array(1337, array());


php poc.php

Program received signal SIGSEGV, Segmentation fault.
0x000000000098d81f in zend_fetch_resource (res=0x539, 
    resource_type_name=0xb39cf1 "cURL handle", resource_type=10)
    at /home/kingolol/php-7.0.0beta2/Zend/zend_list.c:126
126		if (resource_type == res->type) {
(gdb) x/i $pc
=> 0x98d81f <zend_fetch_resource+23>:	mov    0xc(%rax),%eax
(gdb) p $rax
$109 = 1337

An attacker could exploit such condition by simply crafting a zend_resource value in memory with an arbitrary *ptr which would then be used as a php_curl.
From this point code execution could be achieved in several ways, relying on the *handlers or *to_free fields for example. 
Details about that will follow as soon as further investigations will be conducted.


For what is my understanding of the code here, just retrieving zid as a resource should do the job. Other way a typecheck should be performed on zid before passing it to Z_RES_P.



Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2015-07-30 05:59 UTC]
-Status: Open +Status: Closed -Assigned To: +Assigned To: laruence
 [2015-07-30 06:04 UTC]
-Type: Security +Type: Bug
 [2015-07-30 07:48 UTC] andrea dot palazzo at truel dot it
kudos for the very prompt fix!

I see that you are not considering this one to be security related, but what about the following scenario?

Class XMLHttpDummy {

	public $curlInstance;

	function __call($x, $y) {
		curl_setopt_array($this->curlInstance, array("CURLOPT_POSTFIELDS" => xml_encode_request($x, $y), "CURL_BLA" => "whatever"));
		return curl_exec($this->curlInstance);


If a class of this kind is present in an unserialize context this pretty seems remote code execution to me, and that's not that unlikely to have something like that, is it?

 [2015-07-30 08:42 UTC] andrea dot palazzo at truel dot it
Just to be clear, I' haven't investigated the remote execution possibility in deep yet, still I suggest you keep this report private until the next release since remotely triggering the bug is possible.
 [2015-08-04 20:54 UTC]
Automatic comment on behalf of laruence
Log: Fixed bug #70163 (curl_setopt_array() type confusion)
 [2016-07-20 11:37 UTC]
Automatic comment on behalf of laruence
Log: Fixed bug #70163 (curl_setopt_array() type confusion)
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Thu Aug 11 20:05:45 2022 UTC