Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85382
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain geolim4.com designates 212.129.18.216 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <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> <3136D99B-EA3D-4AF1-9B20-C13DF55E3A53@zort.net>
Date: Sat, 21 Mar 2015 18:55:32 +0100
Message-ID: <CACjyb+zob0k3zmJOomeZbk57wO=TY2cN3gK+H9dNgx3FXZ-kmw@mail.gmail.com>
To: John Bafford <jbafford@zort.net>
Cc: Benjamin Eberlei <kontakt@beberlei.de>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113a95446da32f0511d02502
Subject: Re: [PHP-DEV] RFC: Nested enclosing returns
From: contact@geolim4.com ("Georges.L")

--001a113a95446da32f0511d02502
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

To be honest I had not thought about the bad side of this use, i guess it
could be possible to not return upper than a try/catch block (then return a
fatal error if our code is trying to returns upper than a try/catch block).

Now the practical example:

// Code i have the hand on
function main()
{
 foo('bar');
 echo "I'm an angel !";
}

function bar()
{
  echo "I'm not Evil";
}

//Code i don't have the hand on (like a MVC core)
function foo($thing)
{
 //
 make_love_dont_war();
 call_user_func($thing);

 //Do some stuff i don't want to execute
 echo 'evil';
}

function make_love_dont_war()
{
 echo 'Make love, dont war.';
}

You get it ?



Georges.L

2015-03-21 17:07 GMT+01:00 John Bafford <jbafford@zort.net>:

>
> 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 o=
f
> > PHP but to improve the code logic/hierarchy.
> >
> >>> Hi php internals,
> >>>
> >>> 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();
>         }
>
>         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=E2=80=99s 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 su=
re
> 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();
>
>                 //do more stuff
>
>                 return true;
>         } catch($ex) {
>                 //do error stuff
>
>                 return false;
>         }
> }
>
> function doEvil() {
>         $sentinel =3D //some unique value
>
>         $result =3D API_Function_With_Callback(function() use($sentinel) =
{
>                 $backtrace =3D debug_backtrace();
>                 $nestingLevel =3D //determine nesting level from backtrac=
e
>                 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
>         }
>
>         // Exploit inconsistent state of Call_API_Function here
>         if($result =3D=3D=3D $sentinel) { =E2=80=A6 }
> }
>
> Then we can short-circuit code from some other library which isn=E2=80=99=
t
> prepared to deal with this kind of hijacking. More seriously, this sort o=
f
> hijacking *can=E2=80=99t* be defended against (at least not without a wea=
kening of
> your original proposal). Any function that takes a callback is potentiall=
y
> 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 =E2=80=9Cimproved=E2=80=9D with thi=
s functionality
> is already in significant need of improvement by more conventional means.
>
> -John
>
>

--001a113a95446da32f0511d02502--