Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58699
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.170 as permitted sender)
Received-SPF: pass (google.com: domain of adamjonr@gmail.com designates 10.60.12.230 as permitted sender) client-ip=10.60.12.230;
MIME-Version: 1.0
In-Reply-To: <4F567FD9.2050609@gmail.com>
References: <CAJzDObekVt_F6JZP-B-YCs0khvfcSDW1PNeC6Bf5LUk=xPqVAQ@mail.gmail.com>
	<4F55DB1F.5040108@sugarcrm.com>
	<CAJzDObcwd6KMSNvJa8mui0QGiof+BEMoJ2WuGEq09uN+yc4n+g@mail.gmail.com>
	<4F567FD9.2050609@gmail.com>
Date: Tue, 6 Mar 2012 18:04:39 -0500
Message-ID: <CAJzDObcEUscO7q=h0DToEwvrxZMDnWFxjZnmWrsWxx+CKDkVxg@mail.gmail.com>
To: =?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?= <keisial@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=e89a8ff1ce264a8c0604ba9b1110
Subject: Re: [PHP-DEV] Providing sandboxed versions of include and require
 language constructs
From: adamjonr@gmail.com (Adam Jon Richardson)

--e89a8ff1ce264a8c0604ba9b1110
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

2012/3/6 =C1ngel Gonz=E1lez <keisial@gmail.com>

> On 06/03/12 14:04, Adam Jon Richardson wrote:
> > The sandbox I'm considering would only impact the ability to directly
> call...
> It's not that easy. The internal functions could be splitted to
> safe/unsafe (according
> tosome definition, which would itself be a controversial one)


Yes, perhaps controversial, but using an objective criterion like purity
would aid the effort.


> but all
> functions defined
> outside would be injection candidates, too.


The idea I put forth would only deal with internal functions. Frameworks
and CMS's would still be on-the-hook to validate incoming data and escape
data according to context for all of the functions that they expose to the
plugin/library. And this would still be very beneficial. As framework
developer, I can validate the inputs coming into my API hooks and escape
the outputs according to context. However, when plugin developers can call
the internal functions and circumvent my protections, this is a more
difficult issue to solve en masse.


> Suppose you modified the
> function
> hash table to store if it's a limited function or it should be run with
> high privileges.
>

I'm not promoting a privilege-based system of high and low privileges.
Rather, I'm posing the possibility of limiting the access of included code
to internal functions/objects.


> Now, you need to audit the whole framework so that no can be tricked
> into doing more
> things than it should, if called from low-privilege code.
> Which is pretty hard when that code could be corrupting your variables.
> For instance, a safe framework function to perform database queries,
> could become
> unsafe by changing the db configuration (usually stored on globals),
> allowing connections
> to arbitrary servers.
>

It would be the responsibility of the framework or CMS or application to
protect against this type of attack (which they do quite well.) When you
can force a plugin to work through your API, you can take appropriate
measures. When the plugin can avoid working through, say, a file API that
protects against misuse by using the internal file functions, this is a
much more difficult issue to mitigate.


> Or a malicious plugin could register a class with the same name as a
> framework one, before
> the autoloader loads the right one, and have it used by privileged code.
>
> PHP is not designed to use it that way, so unless there is an high level
> way to do it, it's probably
> impossible to do right. Maybe you can perform a full global replacement
> when calling
> untrusted code. That might work.
>

Javascript wasn't "designed this way", either. However, tools like Secure
EcmaScript go a long way towards protecting against the attacks mashups
typically must prevent by protecting/limiting the environment:

http://code.google.com/p/es-lab/wiki/SecureEcmaScript
http://www.infoq.com/presentations/Secure-Mashups-in-ECMAScript-5

Thanks for the feedback, Angel.

Adam

--e89a8ff1ce264a8c0604ba9b1110--