php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #77496 mysqli->real_connect() overwrites MYSQLI_OPT_LOCAL_INFILE setting
Submitted: 2019-01-21 15:33 UTC Modified: 2019-01-22 16:58 UTC
Votes:9
Avg. Score:3.9 ± 0.7
Reproduced:8 of 8 (100.0%)
Same Version:2 (25.0%)
Same OS:2 (25.0%)
From: php at yghe dot net Assigned:
Status: Verified Package: MySQLi related
PHP Version: 7.3.1 OS: Mac OS X Mojave 10.14.2
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2019-01-21 15:33 UTC] php at yghe dot net
Description:
------------
Calls to "mysqli->options(MYSQLI_OPT_LOCAL_INFILE, ...)" before "mysqli->real_connect()" do not seem to have any effect.

They appear to be silently overwritten when "real_connect()" sets the option value from the "mysqli.allow_local_infile" configuration option.

Calls after "real_connect()" behave as expected.

For context, see: <https://secure.phabricator.com/T13238>

Test script:
---------------
<?php

$conn = mysqli_init();

// Call (A).
// $conn->options(MYSQLI_OPT_LOCAL_INFILE, 0);

$conn->real_connect('127.0.0.1', 'root', '', 'local_user');

// Call (B).
// $conn->options(MYSQLI_OPT_LOCAL_INFILE, 0);

$conn->query('CREATE TEMPORARY TABLE t (v LONGTEXT NOT NULL)');
$conn->query('LOAD DATA LOCAL INFILE "example.txt" INTO TABLE t');

var_dump(
  array(
    'errno' => $conn->errno,
    'error' => $conn->error,
  ));


Expected result:
----------------
When "options(MYSQLI_OPT_LOCAL_INFILE, ...)" is called at point (A) above, it should not be silently ignored.

Possible alternative results might include:

"mysqli.allow_local_infile" is configured in "mysqli_init()" instead of "real_connect()".

Setting "options(MYSQLI_OPT_LOCAL_INFILE, ...)" before "real_connect()" fails/warns.

"real_connect()" does not set "MYSQLI_OPT_LOCAL_INFILE" if "options()" has already set it.

Actual result:
--------------
Any "options(MYSQLI_OPT_LOCAL_INFILE, ...)" call at point (A) is ignored.

The actual value for the "LOAD DATA LOCAL INFILE" query at the bottom is determined only by configuration option "mysqli.allow_local_infile" which is set on the connection inside "real_connect()", and any later calls to "options(...)".

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2019-01-22 00:42 UTC] cmb@php.net
-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb
 [2019-01-22 00:42 UTC] cmb@php.net
Active support for PHP 7.1 has ended more than a month ago[1],
i.e. this branch will only receive security related fixes.  Since
this issue does not seem to be security related, please check
whether PHP 7.2 or higher are affected as well, and change the
“PHP Version” field accordingly.

[1] <http://php.net/supported-versions.php>
 [2019-01-22 00:45 UTC] requinix@php.net
-PHP Version: 7.1.26 +PHP Version: 7.3.1
 [2019-01-22 00:47 UTC] requinix@php.net
-Status: Feedback +Status: Verified
 [2019-01-22 00:47 UTC] requinix@php.net
I hit Enter as a reflex, wasn't ready...

Came from the migration to mysqlnd.
 [2019-01-22 00:50 UTC] cmb@php.net
-Assigned To: cmb +Assigned To:
 [2019-01-22 00:50 UTC] cmb@php.net
Thanks, Damian!
 [2019-01-22 11:17 UTC] hanno at hboeck dot de
I'd like to point out that this actually is a security issue.

LOCAL INFILE can be used by a malicious server to exfiltrate files from the client. Disabling this option thus can certainly have security implications.

This caused an issue in phpmyadmin where they thought they set that option, but it wasn't active:
https://github.com/phpmyadmin/phpmyadmin/commit/c5e01f84ad48c5c626001cb92d7a95500920a900
 [2019-01-22 16:58 UTC] requinix@php.net
> I'd like to point out that this actually is a security issue.
...in the application. Not in PHP. There's a distinction there often lost in the commentary on this bug tracker.
 [2019-01-22 17:10 UTC] spam2 at rhsoft dot net
the distinction in this bugtracker is more than questionable and how security relevant bad behavior is treated is terrible at all and has a broader impact:

distributions which are doing only backports of security bugfixes when everything is handeled "it's not a security bug"

this general attitude is part of PHP's bad reputation
 [2019-01-23 10:32 UTC] spam2 at rhsoft dot net
>> I'd like to point out that this actually is a security issue.
> ...in the application

this arrogance when MYSQLI_OPT_LOCAL_INFILE in the application should prevent issues like https://gwillem.gitlab.io/2019/01/17/adminer-4.6.2-file-disclosure-vulnerability/
 [2019-01-23 10:56 UTC] hanno at hboeck dot de
> ...in the application. Not in PHP. There's a distinction there often lost in the commentary on this bug tracker.

No, sorry, it's not. The application tries to set a security related flag with PHP. It should work. It does not.

phpmyadmin added a workaround for a PHP bug. It's still a PHP bug causing a security issue.
 
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Thu Dec 12 16:01:24 2019 UTC