Forwarded to devs Mixup of recipients and subject in Mail settings->Mail Queue

[mow]

TITLE:

Mixup of recipients and subject in Mail settings->Mail Queue​

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE:

Plesk Onyx
Version 17.0.17 Update #42
debian 8.10 x86_64​

PROBLEM DESCRIPTION:

Recently we had trouble with our account creation page that was abused for mailbombing. The entered names consist of chinese characters and the (as in this example, often invalid) mail address.

In the mail queue /admin/mail-settings/queue?serviceNodeId=1, under Recipients, Plesk displays a weird amalgamation of the contents of To: and the content of the following Subject: line:



The To: line is truncated, and the Subject: itself is not in there.
This looks like a buffer overflow/out of bonds read that continues from the field where the To: is stored to the end of the following field where the Subject: is stored.

I have no idea whether it is possible to exploit this, but such things definitely shouldn't happen.​

STEPS TO REPRODUCE:

Relevant part of mail header, copied from the popup clicking on the Subject: field of the mail queue list:
Example 1:
To: =?utf-8?Q?=EF=BC=88=E5=BC=80=EF=BC=891522ooo9328=20?= =?utf-8?Q?=E5=BC=A0=EF=BC=88=E7=A5=A8=EF=BC=89=20yusheyu?= <[email protected]>
Subject: Willkommen bei Sourcetronic GmbH!

Example 2:
To: =?utf-8?Q?=EF=BC=88=E7=A5=A8=EF=BC=891522ooo9328=E5=BC=A0=20?=@sourcetronic.com,
[email protected];15o5149862=EF=BC=89=20xieliuzi?= <[email protected]>
Subject: Willkommen bei Sourcetronic GmbH!​

ACTUAL RESULT:

See for yourself​

EXPECTED RESULT:

Correct display of To: line, no cut-off, no overflow into Subject:; rendering of utf-8 not really necessary​

ANY ADDITIONAL INFORMATION:

Suspicion: something partially renders utf-8 and then uses the character count from that to allocate the buffer, which is definitively too small for multibyte characters​

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM:

Confirm bug​

 

[IgorG]

Thank you for the report. The issue was confirmed by developers and submitted as bugreport PPPM-7865