"Fatal error: Uncaught exception 'PDOException' "- password issue

[namiltd]

When a password error when connecting an error is displayed (in the browser or Apache error log)
with unencrypted password and username:

Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[HY000] [1045] Access denied for user 'username'@'localhost' (using password: YES)' in /var/www/vhosts/mydomain.com/htdocs/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:43 Stack trace: #0 /var/www/vhosts/mydomain.com/htdocs//vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php(43): PDO->__construct('mysql:host=loca...', 'USERNAME', 'PASSWORD', Array) #1

Fix e.g. PDOMySql\driver.php line 34:

    /**
     * {@inheritdoc}
     */
    public function connect(array $params, $username = null, $password = null, array $driverOptions = array())
    {
        try {
            $conn = new PDOConnection(
                $this->constructPdoDsn($params),
                $username,
                $password,
                $driverOptions
            );
           return $conn;
        } catch (PDOException $e) {
 //            throw DBALException::driverException($this, $e);
        } 
//        return $conn;
    }

[Ocramius]

Hello,

This is because you have xdebug.collect_params set to an incorrect value: https://xdebug.org/docs/stack_trace

We can't do anything about this.

[namiltd]

What if I do not have the possibility to change these parameters? According to me, the code should be immune to this problem.

[Ocramius]

You shouldn't display technical-layer exceptions to the end user anyway.

These parameters are displayed because XDebug is installed in your production system (first problem), because it collects parameters by default (second problem) and because you are displaying exceptions in a user-facing application (third problem).

These are all well known security-affecting mis-configurations.

If you do not have access to your production environment, then please contact who has access to it IMMEDIATELY.

[namiltd]

What about Apache error_log?:

[Fri Mar 18 12:00:09 2016] [warn] [client 99.99.99.99] mod_fcgid: stderr: PHP Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[HY000] [1045] Access denied for user 'USERNAME'@'localhost' (using password: YES)' in /var/www/vhosts/mydomain.com/httpdocs/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:43
[Fri Mar 18 12:00:09 2016] [warn] [client 99.99.99.99] mod_fcgid: stderr: Stack trace:
[Fri Mar 18 12:00:09 2016] [warn] [client 99.99.99.99] mod_fcgid: stderr: #0 /var/www/vhosts/mydomain.com/httpdocs/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php(43): PDO->__construct('mysql:host=loca...', 'USERNAME', 'PASSWORD', Array)
[Fri Mar 18 12:00:09 2016] [warn] [client 99.99.99.99] mod_fcgid: stderr: #1 /var/www/vhosts/mydomain.com/httpdocs/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOMySql/Driver.php(45): Doctrine\DBAL\Driver\PDOConnection->__construct('mysql:host=loca...', 'USERNAME', 'PASSWORD', Array)

[Ocramius]

Same thing: traces should not collect parameters. Fix that xdebug config ;-)

[namiltd]

This is not the fault of the xdebug settings because I do not have that module installed in the system.

[Ocramius]

Ah yes, I see that indeed the defaults of PHP are to show the trace parameters: https://3v4l.org/ms3TK

Sorry, I was looking at the wrong traces (HHVM).

There is no way to prevent that from happening: the methods need to be called with that information, and debug_backtrace() will always contain such info. Anything printing the trace info will indeed show these parameters in clear text, regardless of doctrine.

[namiltd]

The solution is to patch the file "PDOMySql\driver.php" and similar as I described in the first post.

[Ocramius]

That would be exception suppressing, leading to a crash later on (connection is null), which is likely going to contain a similar trace anywhere. Even if you have something referencing your config and throwing an exception you will have the same issues.

[namiltd]

It will trace but not the lines containing functions with password and username as arguments. A problem is precisely their display.

[Ocramius]

Right, and that will happen for DB passwords, API keys, SMTP credentials, etc etc. This is not to be fixed by the library itself: we are supposed to give a clear statement of what is going on to the developer.

[namiltd]

OK I understand. Thanks for the clarification.

[namiltd]

However, the problem exists and the current code is not safe :(

[Ocramius]

Then any code producing a stack trace is affected (PHP itself). The issue here (in first place) is caused by producing output of technical-layer-level exceptions, which is a no-go for production environments.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.