Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85373
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zort.net designates 96.241.205.2 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
In-Reply-To: <CACjyb+xoknqifsy7D3MDUC4QDmVphLFfoTpa0vVKm=4F2DqONg@mail.gmail.com>
Date: Sat, 21 Mar 2015 12:07:33 -0400
Cc: Benjamin Eberlei <kontakt@beberlei.de>,
        PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <3136D99B-EA3D-4AF1-9B20-C13DF55E3A53@zort.net>
References: <CACjyb+xrqDhyBNjUBhedFH6faaPKamV7o2j1ChUEoVodgo-bnw@mail.gmail.com> <CAEPJdunjGoA9HJsvBgouitnsyY0_f7XNZ=Ey98FyVwY0R51rMw@mail.gmail.com> <CACjyb+xoknqifsy7D3MDUC4QDmVphLFfoTpa0vVKm=4F2DqONg@mail.gmail.com>
To: "Georges.L" <contact@geolim4.com>
Subject: Re: [PHP-DEV] RFC: Nested enclosing returns
From: jbafford@zort.net (John Bafford)


On Mar 21, 2015, at 10:17, Georges.L <contact@geolim4.com> wrote:

> The main purpose of this RFC is *not* to improve the exception system =
of
> PHP but to improve the code logic/hierarchy.
>=20
>>> Hi php internals,
>>>=20
>>> After some long and deep research i finally decided to write my =
first RFC
>>> about a feature i'd be interested to be improved in the php core: =
*Nested
>>> enclosing returns*

Georges,

This would make simply looking at code and reasoning about what it does =
impossible.

At present, if I have the following code:

function foo() {
	if(doSomething()) {
		success();
	} else {
		failure();
	}
=09
	return 42;
}

try {
	bar(foo());
} catch($ex) {
}

Then I can make the following true statements about this code:
	* foo always calls doSomething()
	* foo always calls either success() or failure(), based on the =
result of doSomething()
	* foo always returns 42
	* bar is always called (with foo=92s return value, 42)
	* Alternatively to the above, any of the called functions may =
throw an exception, which will be caught by the catch block

If any of doSomething(), success(), failure(), or bar() can arbitrarily =
return to some higher calling scope, then the only thing I can say for =
sure is that doSomething() is called, after which my application could =
be in some dangerously inconsistent state because I have no idea what =
will be executed next.

This then provides significant security concerns. For example, if we =
have this:

function API_Function_With_Callback($callback) {
	try {
		$callback();
	=09
		//do more stuff
	=09
		return true;
	} catch($ex) {
		//do error stuff
	=09
		return false;
	}
}

function doEvil() {
	$sentinel =3D //some unique value
=09
	$result =3D API_Function_With_Callback(function() use($sentinel) =
{
		$backtrace =3D debug_backtrace();
		$nestingLevel =3D //determine nesting level from =
backtrace
		if($nestingLevel =3D=3D 2) return $sentinel, 2;
		else if($nestingLevel =3D=3D 3) return $sentinel, 3;
		else if($nestingLevel =3D=3D 4) return $sentinel, 4;
		// etc
	}
=09
	// Exploit inconsistent state of Call_API_Function here
	if($result =3D=3D=3D $sentinel) { =85 }
}

Then we can short-circuit code from some other library which isn=92t =
prepared to deal with this kind of hijacking. More seriously, this sort =
of hijacking *can=92t* be defended against (at least not without a =
weakening of your original proposal). Any function that takes a callback =
is potentially vulnerable to this sort of attack.


Can you suggest an actual, practical, example, where this would be such =
a benefit as to override the inherent difficulty about reasoning about =
this code, and the potential security concerns? Are there any other =
languages that make something like this possible?

I suspect that any code that could be =93improved=94 with this =
functionality is already in significant need of improvement by more =
conventional means.

-John