Page MenuHomePhorge

Invalid MIME encoding in the title of an attachement leads to a crash of the syncroton
Closed, ResolvedPublic

Description

In an e-mail we have received an attachement with the title "=?iso-8859-1?Q?PC_CADDIE,_Kantonalbank_Z=FC=81rich_-_Startliste.pdf?=". Whilst =FC is the ü umlaut, =81 is invalid (in less shown as <U+FFFE>).

  • Expexted e-mail to get synced with the invalid character
  • synctron crashes with the following error message in /var/log/kolab-syncroton/errors
[17-Jun-2016 06:32:18,669700 +0200]: [ERR] {"user":<redacted>,"cmd":"Sync","device":<redacted>,"type":"WindowsOutlook15"} Syncroton_Server::_handlePost::191 Could not encode
 output: exception 'Syncroton_Wbxml_Exception' with message 'XML error: Invalid character at line 829' in /usr/share/kolab-syncroton/lib/ext/Syncroton/Wbxml/Encoder.php:174
Stack trace:
#0 /usr/share/kolab-syncroton/lib/ext/Syncroton/Server.php(188): Syncroton_Wbxml_Encoder->encode(Object(DOMDocument))
#1 /usr/share/kolab-syncroton/lib/ext/Syncroton/Server.php(70): Syncroton_Server->_handlePost()
#2 /usr/share/kolab-syncroton/lib/kolab_sync.php(169): Syncroton_Server->handle()
#3 /usr/share/kolab-syncroton/index.php(31): kolab_sync->run()
#4 {main}
[17-Jun-2016 06:32:18,671000 +0200]: [ERR] {"user":<redacted>,"cmd":"Sync","device":<redacted>,"type":"WindowsOutlook15"} Syncroton_Server::_handlePost::192 xml response(0):

Kolab version:
$ rpm -qv pykolab
pykolab-0.8.1-2.3.el7.kolab_16.noarch
$ yum list | grep pykolab
pykolab.noarch 0.8.1-2.3.el7.kolab_16 @Kolab_16
pykolab-xml.noarch 0.8.1-2.3.el7.kolab_16 @Kolab_16
pykolab-telemetry.noarch 0.8.1-2.3.el7.kolab_16 Kolab_16

Details

Ticket Type
Task

Event Timeline

Kolab-syncroton package version would be more relevant here. Sounds like a it could have been fixed in https://issues.kolab.org/show_bug.cgi?id=3844.

Thank you for your fast response.

Our syncroton version is:

$ yum list | grep syncroton
kolab-syncroton.noarch                      2.3.3-1.6.el7.kolab_16     @Kolab_16

It seems that the syncroton is a newer version than the one mentioned in the other issue and I coulnd't check if the patches have been applied, because they seem to have been moved/removed.

Hmm... I'd expect clean() in this line https://git.kolab.org/diffusion/S/browse/master/lib/kolab_sync_data_email.php;a6b7464233dcf471293103aa735d42ea8f3c7870$350 would fix such issues. Could you compare this with what you have installed?

The specified line with the clean() call is the same. The only difference in the files is that the messageClass gets a suffix for encrypted messages:

322,323c322,333
<         // @TODO: add messageClass suffix for encrypted messages
<         $result['messageClass'] = 'IPM.Note';
---
>         if ($headers->ctype == 'multipart/signed'
>             && count($message->attachments) == 1 && $message->attachments[0]->mimetype == 'application/pkcs7-signature'
>         ) {
>             $result['messageClass'] = 'IPM.Note.SMIME.MultipartSigned';
>         }
>         else if ($headers->ctype == 'application/pkcs7-mime' || $headers->ctype == 'application/x-pkcs7-mime') {
>             $result['messageClass'] = 'IPM.Note.SMIME';
>         }
>         else {
>             $result['messageClass'] = 'IPM.Note';
>         }
>

Could you provide complete message sample? You can remove message/attachment bodies or other sensitive information, but keep the structure.

Since we had to remove the e-mail to get the sync to work again I had to recreate it.

I've created a file called mail with the following content and sent it with cat mail | sendmail -t -oi

From: nicolas.ganz@citrin.ch
To: nicolas.ganz@citrin.ch
Subject: Test Mail
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="ZZ_/afg6432dfgkl.94531q"

--ZZ_/afg6432dfgkl.94531q
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Test Content

--ZZ_/afg6432dfgkl.94531q
Content-Type: text/plain
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="=?iso-8859-1?Q?PC_CADDIE,_Kantonalbank_Z=FC=81rich_-_Startliste.pdf?="

VGVzdCBBdHRhY2hlbWVudAo=

--ZZ_/afg6432dfgkl.94531q--

After that the sync failed and the error message appeared in /var/log/kolab-syncroton/errors

Does this information suffice or in which format do you need the message?

Ok, I investigated this case. I have no idea yet why but mb_convert_encoding() converts ISO-8859-1 string of "=FC=81" into (UTF-8) "=C3=BC=EF=BF=BE" (using quoted-printable encoding).

This "=EF=BF=BE" is redundant. I have no idea why this happens. If you had php-iconv installed you'd see that iconv does not do this (actually that would be a good workaround, but will not work if the string is invalid).

Now, this character sentence is valid UTF-8 character (http://www.fileformat.info/info/unicode/char/fffe/index.htm). That's why it's not removed by rcube_charset::clean().

Looks like Syncroton's encoder (PHP XML Parser) does not like this character sequence. Maybe more investigation would be needed here, but...

I suppose a fix would be to make rcube_charset::clean() to remove all special characters from U+FFF0 to U+FFFF (http://www.fileformat.info/info/unicode/block/specials/index.htm). Maybe except U+FFFD.

machniak claimed this task.

I've tested all special chars. It looks only two cause errors. It's "=EF=BF=BE" and "=EF=BF=BF". Fixed.