Harden open_basedir restrictions in various extensions

[LamentXU123]

Description

Now, several extensions in the php codebase has functions with the ability to read/write outside the open_basedir restrictions.

That is because, the open_basedir restrictions only works on PHP streams, and some of our extensions read/write without it, and therefore bypassing the open_basedir check.

Examples found while auditing similar open_basedir behavior:

• ext/dba: non-stream DBA handlers such as gdbm, qdbm, or lmdb open paths through their backend libraries, e.g. gdbm_open(), dpopen(), mdb_env_open().
• ext/gettext: bindtextdomain() resolves a directory and then passes it to libc/gettext, which later loads .mo files from that location.
• ext/openssl: SSL context options such as cafile, capath, and dh_param may be passed to OpenSSL APIs such as SSL_CTX_load_verify_locations() or BIO_new_file().
• ext/gd: FreeType font loading can pass the resolved font path to FT_New_Face() after locating it with access().
• ext/standard: stream_resolve_include_path

IMO, all of them are supposed to be fixed, that they should align with the expected open_basedir behavior. I know that the above only work with conditions (e.g. know dba keys for dpopen, or being a .mo file for bindtextdomain) but all of them should only works under the restrictions of open_basedir due to serious safety concerns. Which is simply by adding

#include "main/fopen_wrappers.h"

if (php_check_open_basedir(path)) {
    RETURN_FALSE;
}

/* then call native/library open */

I don't think this requires a RFC so I would like to directly open this issue to discuss about this. cc @iluuu1994 . Thanks!

Below are some example payloads:

<?php
ini_set('open_basedir', __DIR__ . '/allowed');

$db = dba_open('/tmp/outside.gdbm', 'r', 'gdbm');
var_dump(dba_fetch('secret', $db));

and

<?php
ini_set('open_basedir', __DIR__ . '/allowed');

bindtextdomain('leak', '/tmp/outside-locale');
textdomain('leak');

echo gettext('secret_key'), "\n";

and (this can only check if a file exists, but without any restrictions)

<?php
ini_set('open_basedir', __DIR__ . '/allowed');
ini_set('include_path', '/etc');
var_dump(stream_resolve_include_path('passwd'));
var_dump(@file_get_contents('passwd', use_include_path: true));

I don't sure if we should treat this as a security issue :) This research is done with @q1uf3ng

TL;DR some of the functions use zend_resolve_path for file IO, the API doesn't check if it fits in the open_basedir restrictions.

[iluuu1994]

I don't sure if we should treat this as a security issue

As mentioned:

https://www.php.net/manual/en/ini.core.php#ini.open-basedir

Caution open_basedir is just an extra safety net, that is in no way comprehensive, and can therefore not be relied upon when security is needed.

So we don't consider these security issues. As long as PHP has engine memory issues (#20001, #20018, etc.) hardening will also be ineffective.

[LamentXU123]

As long as PHP has engine memory issues (#20001, #20018, etc.) hardening will also be ineffective.

I think adding additional restrictions will make open_basedir to be at least safer. It doesn't has obvious downside and could make the approach more effective. The initial idea of open_basedir is to restrict web user's permission as good as possible to make web apps stable and safe.

I know we have lots of known UAFs, but they are far more complicated to be utilized in reality. The status quo is, while we are restricting most of the file read/write operations out of the given path in open_basedir, there are still ways to escape the restrictions and are easy to fix.