Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[Process] Windows argument escaping is fragile #19993

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
johnstevenson opened this issue Sep 20, 2016 · 2 comments
Closed

[Process] Windows argument escaping is fragile #19993

johnstevenson opened this issue Sep 20, 2016 · 2 comments

Comments

@johnstevenson
Copy link
Contributor

It is quite easy to break ProcessUtils::escapeArgument on Windows, because it does not follow all the various argument-parsing rules.

I discovered this while working on Composer's XdebugHandler (which restarts the process and needs a robust way to escape its passed-in arguments) and after much research came up with a single function Winbox\Args::escape to handle this.

To illustrate the problems, we can pass some contrived arguments to both escape functions and get php to print out its $argv:

Given this composer.json:

{
    "require": {
        "symfony/process": "^2.1",
        "winbox/args": "^1.0"
    }
}

and this script:

<?php
require __DIR__ . '/vendor/autoload.php';

$params = [
    PHP_BINARY,
    '-r',
    'print_r($argv);',
    '--',
    'path=%PATH%',
    'quote="',
    'colors=red & blue',
];

run($params, ['Symfony\Component\Process\ProcessUtils', 'escapeArgument']);
run($params, ['Winbox\Args', 'escape']);

function run($params, $escaper)
{
    $command = implode(' ', array_map($escaper, $params));
    printf("%s command line:\n%s\n\n", $escaper[0], $command);
    passthru($command);
    echo PHP_EOL;
}

the expected output from print_r($argv); is:

Array
(
    [0] => -
    [1] => path=%PATH%
    [2] => quote="
    [3] => colors=red & blue
)

The actual output using Winbox\Args is as above, whereas the output using ProcessUtils is:

Array
(
    [0] => -
    [1] => path=C:\WINDOWS\system32 ... and the rest of the PATH variable
    [2] => quote="
    [3] => colors=red
)
'blue"' is not recognized as an internal or external command,
operable program or batch file.

The unexpected path-expansion is a simple logic error, but the argument splitting (colors=red followed by cmd.exe trying to run a program called blue) highlights a more serious problem:

  • the escaped arguments are not totally self-contained.

What's happening here is that quote=" is escaped as "quote=\"" and while this will work fine on its own, the odd number of double-quotes may corrupt subsequent arguments. In this case the escaped "colors=red & blue" is interpreted by cmd.exe as an argument ("colors=red) followed by the special character & which signifies a separate command (blue"). See How cmd.exe parses a command for more information.

The wiki at winbox-args details the various hoops you have to go through to try and make this stuff work.

@sstok
Copy link
Contributor

sstok commented Sep 22, 2016

@romainneutron can you take a look this?

@johnstevenson
Copy link
Contributor Author

@wouterj FYI, the problem you encountered with ProcessUtils surrounding everything in double-quotes (composer #4280) is another example of this fragility.

fabpot added a commit that referenced this issue Feb 8, 2017
…ars, fixing signaling and escaping (nicolas-grekas)

This PR was merged into the 3.3-dev branch.

Discussion
----------

[Process] Accept command line arrays and per-run env vars, fixing signaling and escaping

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | yes
| Tests pass?   | yes
| Fixed tickets | #12488, #11972, #10025, #11335, #5759, #5030, #19993, #10486
| License       | MIT
| Doc PR        | -

I think I found a way to fix this network of issues once for all.
Of all the linked ones, only the last two are still open: the remaining were closed in dead ends.

Instead of trying to make `ProcessUtil::escapeArgument` work correctly on Windows - which is impossible as discussed in #21347 - this PR deprecates it in favor of a more powerful approach.

Depending on the use case:

- when a simple command should be run, `Process` now accepts an array of arguments (the "binary" being the first arg). Making this the responsibility of `Process` (instead of `ProcessBuilder`) gives two benefits:
  - escape becomes an internal detail that doesn't leak - thus can't be misused ([see here](#21347 (comment)))
  - since we know we're running a single command, we can prefix it automatically by "exec" - thus fixing a long standing issue with signaling

```php
        $p = new Process(array('php', '-r', 'echo 123;'));
        echo $p->getCommandLine();
        // displays on Linux:
        // exec 'php' '-r' 'echo 123;'
```

- when a shell expression is required, passing a string is still allowed. To make it easy and look-like sql prepared statements, env vars can be used when running the command. Since the shell is OS-specific (think Windows vs Linux) - this PR assumes no portability, so one should just use each shell's specific syntax.

From the fixtures:
```php
        $env = array('FOO' => 'Foo', 'BAR' => 'Bar');
        $cmd = '\\' === DIRECTORY_SEPARATOR ? 'echo !FOO! !BAR! !BAZ!' : 'echo $FOO $BAR $BAZ';
        $p = new Process($cmd, null, $env);
        $p->run(null, array('BAR' => 'baR', 'BAZ' => 'baZ'));

        $this->assertSame('Foo baR baZ', rtrim($p->getOutput()));
        $this->assertSame($env, $p->getEnv());
```

Commits
-------

330b61f [Process] Accept command line arrays and per-run env vars, fixing signaling and escaping
@fabpot fabpot closed this as completed Feb 8, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants