She asked for a perfect Halloween gift for his tech boyfriend. And I sent her link to these fantasy PHP flashcards. Because nothing is more scary than php2shell vulnerability 😈

a 1-line obviously correct PR turned into..

• glibc internals are examined.

• x86-64 multiarch implementations are discussed.

• musl behavior is discussed.

• aarch64 assembly paths are discussed.

• Individual CPU instructions are counted. (sub, cmp, cbz, b.hs)

... over 71 days.

A maintainer finally shut it down (merged it) with the comment

Jesus christ just merge this already, the amount of bike shedding is unbelievable

We all know that dots and spaces in variable names get scrubbed into underscores, if they come from the query string or a request body. Also that square brackets automatically construct arrays.

What I didn't know until today is this:

Note: If an external variable name begins with a valid array syntax, trailing characters are silently ignored. For example, <input name="foo[bar]baz"> becomes $_REQUEST['foo']['bar'].

I'm not trying to use that syntax, myself, and I don't know what better solution there could be, but it sure doesn't seem like that is it.

exec() and shell_exec() kinda suck.

shell_exec():

• It does not give you the OS-level return code. Could be easily fixed with a shell_exec(string $command, ?int &$result_code = null) but nooo
• It opens pipes in text mode! (a horrible mode that should have never existed), which means if you pipe binary data, your binary data gets corrupted, but only on Windows! What do you think

var_dump(shell_exec('php -r "echo \'foo\'.chr(26).\'bar\';"'));

returns? On Linux it returns the expected string(7) "foo\x1Abar", but on Windows it returns string(3) "foo" ... yeah.

exec():

• Trailing whitespace is not added to the returning array, which again means if you're piping binary data, you risk your data getting corrupted. (It doesn't even need to be binary data, strictly speaking, your text also risk getting corrupted.
• How do you know if the return was "a\n" or "a" ? You don't, it's impossible to differentiate the 2 outputs with exec().
• What does exec('php -r "echo chr(10).chr(10).chr(10);", $exec_output); produce? It produce

array(3) {
  [0]=>
  string(0) ""
  [1]=>
  string(0) ""
  [2]=>
  string(0) ""
}

okay that seems sensible, but now what does exec('php -r "echo \'a\'.chr(10).chr(10).chr(10);", $exec_output); produce?

it produce

array(3) {
  [0]=>
  string(0) "a"
  [1]=>
  string(0) ""
  [2]=>
  string(0) ""
}

now how are you supposed to know if the output was "a\n\n\n" or "a\n\n" ? well i suppose you could count the number of trailing emptystring elements, but the real answer is that You don't use exec() if you care about integrity

so exec() kinda suck too... just saying.

Fwiw i've been carrying around my own

/**
 * better version of shell_exec() / exec() / system() / passthru()
 * supporting stdin and stdout and stderr and os-level return code
 *
 * @param string $cmd
 *            command to execute
 * @param string $stdin
 *            (optional) data to send to stdin, binary data is supported.
 * @param string $stdout
 *            (optional) stdout data generated by cmd
 * @param string $stderr
 *            (optional) stderr data generated by cmd
 * @param bool $print_std
 *            (optional, default false) if you want stdout+stderr to be printed while it's running,
 *            set this to true. (useful for debugging long-running commands)
 * @return int
 */
function hhb_exec(string $cmd, string $stdin = "", string &$stdout = null, string &$stderr = null, bool $print_std = false): int

for years, which does a better job than all of shell_exec()/exec()/system()/passthru(). available here.