php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

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:10
Avg. Score:3.8 ± 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
View Developer Edit
 [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

Pull Requests

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:45 UTC] requinix@php.net 
https://github.com/php/php-src/blob/PHP-7.3.1/ext/mysqli/mysqli_nonapi.c#L260
 [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.
 [2020-02-13 02:50 UTC] greenreaper at hotmail dot com 
On a related note, it's confusing that the commented-out configuration line for mysqli.allow_local_infile in the production ini makes it look like the default is still 'On', when in fact it's 'Off':
https://github.com/php/php-src/blob/master/php.ini-production#L1131

Perhaps this was missed when disabling it in 7.2.16 and 7.3.3? Other commented-out items tend to use the default value, or even explicitly state the default as well as the production value.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sun Dec 22 13:01:30 2024 UTC