Bug#726600: otrs2: Internal server error when replying to email ticket

[Niko Tyni]

tag 726600 - moreinfo unreproducible
reassign 726600 libmime-tools-perl 5.504-1
thanks

On Fri, Nov 01, 2013 at 08:17:03AM +1100, John Seymour wrote:
> I have worked out how to reliably trigger the bug.
> 
> If you enter a Unicode character in the the "system standard
> signature"  and reply to a ticket that uses that signature the bug
> will be triggered.

Thanks. It doesn't need a signature in my tests, just replying to a bug
and copy-pasting non-latin1 chararacter to the text field triggers it.

It can be reduced to this:

  % perl -w -MMIME::Entity -e 'print MIME::Entity->build(Data => "\x{2660}")->body_as_string'
  Strings with code points over 0xFF may not be mapped into in-memory file handles
  open body: Invalid argument at /usr/share/perl5/MIME/Entity.pm line 1878.

or just

  % perl -w -MMIME::Body -e 'MIME::Body::InCore->new("\x{2660}")->open("r") or die "open failed: $!"'
  Strings with code points over 0xFF may not be mapped into in-memory file handles
  open failed: Invalid argument at -e line 1.

I'm reassigning this against libmime-tools-perl again - if this is an
intentional limitation there, it should at least be documented better.
Preferrably, I suppose MIME::Body::InCore should transparently encode
Unicode data before making an in-memory file out of it. (This needs to
be discussed upstream, of course.)

In this case, OTRS hits it in Kernel::System::Email::Send() when it gets
a body containing HTML elements that map onto non-latin characters,
for instance ♠ . The $Self->{HTMLUtilsObject}->ToAscii() call
around line 288 of Kernel/System/Email.pm then converts the elements into
Unicode characters, which are later passed to MIME::Entity->build() as-is.

If necessary, OTRS could work around the problem by encoding the string
first. It already does for some cases, around line 316 or so:

    # body encode if utf8 and base64 is used
    if ( $Header{Encoding} =~ /utf(8|-8)/i && $Header{Encoding} =~ /base64/i ) {
        $Self->{EncodeObject}->EncodeOutput( \$Param{Body} );
    }

Making this EncodeOutput() call unconditional fixes the crash for me,
probably at the cost of some double encoding later. (I don't use OTRS
myself so I didn't really test that any further, but it seems too simple
minded to be a proper fix.)
-- 
Niko Tyni   ntyni at debian.org