fix typo in os name

Huh, imap library just runs external commands with no escaping whatsoever? This sucks :(

I guess we need to add some filters there. Not sure whether this ssh/rsh thing is even useful... But we probably could at least filter the hostname.

And mailbox parsing happens inside c-client, so we have no control over it. Looks like we'd have to disassemble the mbox string, validate it and re-assemble it back. Maybe also add /norsh by default.

> Maybe also add /norsh by default.

Iff that would resolve the RCE vulnerability, we may consider
to disable rsh support globally.  From imap.2007f/docs/FAQ.txt:

| You can disable rsh globally by setting the rsh timeout value
| to 0 with the call:
| mail_parameters (NIL,SET_RSHTIMEOUT,0);

Calling this in MINIT[1] *might* be sufficient.

Anyhow, since this issue is already lively discussed in public, I
think we have to hurry up with a solution.

[1] <https://gist.github.com/cmb69/b3ca981599bf21004c6417ab64dea4b7#file-disable-rsh-globally-patch>

Would this also disable SSH functionality? Because there's also ssh (which seems to be different branch from rsh, though on Debian it's the same thing in fact, but not on other systems) and it may be vulnerable too. 

It is also BC break so we'd probably have to announce it and put it into UPGRADING.

OK, there's also SET_SSHTIMEOUT, so probably we'd need to do both of them. We may allow a way to enable them back though, in case anybody needs it (doubtful, but who knows?)

i think maybe adding a `php.ini` directive for it defaulting to 0 should do it.

example :

imap.set_rshtimeout=0
imap.set_sshtimeout=0

revert summary change

Indeed, (a) new ini option(s) might be appropriate for BC reasons.
I think we should reduce these to a minimum (maybe just a boolean
imap.allow_sh).

FTR: not only imap_open() seems to be affected by this issue, but
also imap_createmailbox() and imap_append() and maybe others.

Proposed patch:

https://gist.github.com/smalyshev/aae34ba0a831e9a5c4824b1ee89579c2

I plan to merge it sometime early next week, if there are no objections, since the issue is already public. It is somewhat of a BC break but I don't think we have a choice here.

The patch is for 5.6, I'll upmerge it of course.

Opening it since it's essentially in public anyway.

Guys this is the same research from #76428 which you totally ignored.

stas@php.net knew about this from 2018-06-20.

Yes, I did not realize at the time c-client is essentially a dead project and is not going to be fixed. Now I realize that so it looks like we need to mitigate it in PHP (even though it's not directly a PHP issue).

CVE-2018-19158 is a typo. mitre actually allocated CVE-2018-19518 instead, see also https://www.openwall.com/lists/oss-security/2018/12/05/2

could some php.net fix the metadata here? I'll request Mitre reserve the erroneous CVE since it's been used in some other places already and should probably be discarded to avoid the confusion.