Rare spam messages causing segmentation faults on PHP while displaying messages

[deklar]

I've been tracking this off and on for the past five years. Over the past few days I took a deeper look into it as these rare spam messages became more frequent.

Software: RC 1.1.x, RC 1.3.3

What the end-user sees: A user will login to RC and be presented with the generic "Server Error! (Service Unavailable)" dialog (which will timeout and go away normally). The inbox at this point will appear empty.

What is happening: The user received an email using a form of UTF-32 encoding for the subject line. I've tested various webmail clients, some are broken and simply do not work as intended (RC for instance), others strip the UTF and display any clear text (if any) after it for a subject, while others display the ASCII format of the UTF.

The fix: Either deleting the message in question, or if direct access to the message can be obtained and the subject altered to delete the UTF in the subject line, the issue goes away.

Raw example from the MTA before any alterations:
Subject: =?UTF-32?B?IAAAAN70AQAgAAAA?=

Additional notes: UTF-8 works fine, I'm only seeing the issue with UTF-32 (which is very rare to see anyone use in a subject). If it matters the IMAP servers being used are Dovecot 1.x and 2.x (including latest stable).

[deklar]

Thinking down the lines of PHP decoding issue at this point and not so much RC. I'll continue digging..

[deklar]

Found the issue. Can be closed.

[thomascube]

Can you maybe share your findings here? Roundcube uses iconv to convert charsets to utf-8. Maybe there's some configurations or other hints you could share with us?

[sheldonwjones]

I'm also having this issue. Can you please share your findings.

Thanks.

[deklar]

May not be related to what my issue was, in either case I'll share what I discovered on my end below.

With PHP compiled with debug, running gdb on httpd, I was able to identify that the issue was with the iconv library itself. While iconv did not error out in my own testing (it did indeed work), for whatever the reason (which I didn't bother looking into) RC did not play nice with it. The work-around for the time being was to compile PHP without iconv (--without-iconv if I recall correctly), so that RC would fall back to mbstring (if I recall, this is all from memory). That solved the first issue (albeit a temporary fix).

Second issue was the RC log files indicating conversion errors from utf-32 to utf-8 (this was on RC 1.1.x). Again a temporary fix, I tossed the latest program/lib/Roundcube/rcube_charset.php in to replace the old version, which corrected most of the PHP errors. RC-1.3 does not report any errors.

Long term solution will be to upgrade PHP, libiconv, Apache and then RC itself.

The temporary fix works well enough to get by for now (as this is a production server, I didn't want to leave it hanging). The only downside is that the UTF-32 subject is still not parsed correctly (it's essentially ignored/stripped) - but that makes up for something like 1 out of 850,000 emails delivered and that one message is always spam - so no biggie. The end user no longer is affected - which is more important.

I'm confident that with an updated version of libiconv on a newer build of PHP the issue will be resolved completely.

Hope this helps someone.

[sheldonwjones]

Removing iconv from php has resolve the issue.

Thank you.

[deklar]

I'll also point out that in my testing on a second (non-production) machine running a different OS with a different version of iconv/php, RC 1.1.x did handle the utf-32 subjects (and displayed them) just fine.

I almost wonder if the newer versions of libiconv may be an issue. Installed affected version is 1.14_8 (2015?), latest is 1.15 (10 months old) from what I can tell. I'm fairly confident that the non-production server that does work is running a bit behind 1.14_8. I'm hoping that is not the case and 1.15 works as I would hate to go backwards.

If you'd like I can update you after my upgrades (but that remains 2-3 weeks out).

[Ddruid]

I've been banging my head on this issue for a few days now as well and just stumbled upon this after coming to the same conclusion. Same complaint, mail fails to display (mailbox appears empty) and same cause (after reading above) a spam message with UTF-32. Spun up a new VM to replicate the issue.

OS: FreeBSD 11.1-RELEASE-p1
Rouncube: roundcube-1.3.3,1 From ports
PHP: php56-5.6.32
Iconv: php56-iconv-5.6.32, libiconv-1.14_11
Apache: apache24-2.4.27_1

Subject of SPAM: Subject: =?UTF-32?B?IAAAAN70AQAgAAAA?= Call me now!

Apache log just showed an Abort being called when the account logged in:
[Thu Dec 21 12:58:42.927462 2017] [core:notice] [pid 41471] AH00052: child pid 47018 exit signal Abort trap (6)

Apache Backtrace:
#0 0x0000000801c6884a in thr_kill () from /lib/libc.so.7
#1 0x0000000801c68814 in raise () from /lib/libc.so.7
#2 0x0000000801c68789 in abort () from /lib/libc.so.7
#3 0x0000000809aa6123 in unicode_loop_convert () from /usr/local/lib/libiconv.so.2
#4 0x000000080989d5ac in php_iconv_string ()
from /usr/local/lib/php/20131226/iconv.so
#5 0x000000080989ab0d in php_if_iconv () from /usr/local/lib/php/20131226/iconv.so
#6 0x0000000805694b59 in zend_do_fcall ()
from /usr/local/libexec/apache24/libphp5.so
#7 0x0000000805654f98 in execute_ex () from /usr/local/libexec/apache24/libphp5.so
#8 0x0000000805629f2e in zend_execute_scripts ()
from /usr/local/libexec/apache24/libphp5.so
#9 0x00000008055c53ff in php_execute_script ()
from /usr/local/libexec/apache24/libphp5.so
#10 0x00000008056b25da in zend_get_zval_ptr_ptr ()
from /usr/local/libexec/apache24/libphp5.so
#11 0x0000000000458a45 in ap_invoke_handler ()
#12 0x000000000046e852 in ap_process_async_request ()
#13 0x000000000046e8e9 in ap_process_request ()
#14 0x000000000046b452 in ap_process_http_connection ()
#15 0x00000000004636e5 in ap_process_connection ()
#16 0x0000000804637bf5 in ?? () from /usr/local/libexec/apache24/mod_mpm_prefork.so
#17 0x00000008046376c0 in ?? () from /usr/local/libexec/apache24/mod_mpm_prefork.so
#18 0x0000000804637467 in ?? () from /usr/local/libexec/apache24/mod_mpm_prefork.so
#19 0x000000000043b75b in ap_run_mpm ()
#20 0x0000000000433da3 in main ()

Modifying the function 'convert' in rcube_charset.php to use mbstring over iconv fixes the display issue.

[alecpl]

Could you check if that also fails?

<?php
iconv('UTF-32', 'UTF-8', base64_decode('IAAAAN70AQAgAAAA'));
?>

If we find a reproducible test case we could create a ticket in PHP bugtracker. This is obviously PHP issue.

[Ddruid]

It does fail

$ php test.php
PHP Notice: iconv(): Detected an illegal character in input string in /usr/local/www/apache24/data/test.php on line 2

Notice: iconv(): Detected an illegal character in input string in /usr/local/www/apache24/data/test.php on line 2

[deklar]

Same results here. Does libiconv 1.15 have the same issue? Anyone have that installed to test with? Or perhaps an earlier version of libiconv? I only ask because on another server which I sadly do not have direct access to check versions on, this is a non-issue.

[alecpl]

A notice is nothing serious, however on PHP 7.2 it does not print a notice for me. We'd need a test case that produces a backtrace. Maybe it only fails in the Apache module.

The string looks valid. The command below prints no warnings on my system:

echo -e "IAAAAN70AQAgAAAA" | base64 -d | iconv --from=utf-32 --to=utf-8

the same as the php script above.

[sheldonwjones]

I'm using php-fpm 5.6 behind apache reverse proxy. Same result.