OWASP P13 and P4 removing css display attribute

[JDunphy]

Just saw the bug fix for inline images that is coming our way. I am a little concerned with the Known issue with this patch that is removing the display attribute. Would like to see some finer granularity with this patch.

https://wiki.zimbra.com/wiki/Zimbra_Releases/8.7.11/P13
https://wiki.zimbra.com/wiki/Zimbra_Releases/8.8.12/P4

In addition to having an impact in usability from mobile devices, we lose some local ability of spam identification that keyed off of css html tag display. Some newspapers and newsletters could be impacted if they do preheaders stuff which we see in a lot of our incoming business email. I am going to install this on a test machine but was curious what others think of removing css display completely from any rendering for html email as part of this patch. They must think this is pretty important but saying "In order to prevent XSS attacks" is a rather interesting comment given how used the display tag is with browsers and websites. A little more detail would have been valuable here IMO.

ref:https://www.w3schools.com/CSSref/pr_class_display.asp

[khalilquza]

Hello

The updates on the REPO now , should we update or wait ?

[phoenix]

The updates on the REPO now , should we update or wait ?

That's rather a strange question, what would be the point of waiting? Your choice is your choice and it's up to you to make the decision but I must point out that by 'waiting' to update lots of people have had their servers compromised - was that a good choice?

[rickaotc]

I'm surprised there's a p4 and not zcs 8.8.15, supposedly to be released July 1 -

https://www.zimbra.com/support/support- ... lifecycle/

[L. Mark Stone]

I'm surprised there's a p4 and not zcs 8.8.15, supposedly to be released July 1 -

https://www.zimbra.com/support/support- ... lifecycle/

At this writing, it looks like July 19 for 8.8.15's release, and then Patch 1 ten days later.

Hope that helps,
Mark

[rickaotc]

At this writing, it looks like July 19 for 8.8.15's release, and then Patch 1 ten days later.

Thanks Mark!

[L. Mark Stone]

Just saw the bug fix for inline images that is coming our way. I am a little concerned with the Known issue with this patch that is removing the display attribute. Would like to see some finer granularity with this patch.

https://wiki.zimbra.com/wiki/Zimbra_Releases/8.7.11/P13
https://wiki.zimbra.com/wiki/Zimbra_Releases/8.8.12/P4

In addition to having an impact in usability from mobile devices, we lose some local ability of spam identification that keyed off of css html tag display. Some newspapers and newsletters could be impacted if they do preheaders stuff which we see in a lot of our incoming business email. I am going to install this on a test machine but was curious what others think of removing css display completely from any rendering for html email as part of this patch. They must think this is pretty important but saying "In order to prevent XSS attacks" is a rather interesting comment given how used the display tag is with browsers and websites. A little more detail would have been valuable here IMO.

ref:https://www.w3schools.com/CSSref/pr_class_display.asp

Hi JD,

Curious if you have had an opportunity to test Patch 4 to see how big of an impact on rendering it actually causes?

All the best,
Mark

[L. Mark Stone]

Just saw the bug fix for inline images that is coming our way. I am a little concerned with the Known issue with this patch that is removing the display attribute. Would like to see some finer granularity with this patch.

https://wiki.zimbra.com/wiki/Zimbra_Releases/8.7.11/P13
https://wiki.zimbra.com/wiki/Zimbra_Releases/8.8.12/P4

In addition to having an impact in usability from mobile devices, we lose some local ability of spam identification that keyed off of css html tag display. Some newspapers and newsletters could be impacted if they do preheaders stuff which we see in a lot of our incoming business email. I am going to install this on a test machine but was curious what others think of removing css display completely from any rendering for html email as part of this patch. They must think this is pretty important but saying "In order to prevent XSS attacks" is a rather interesting comment given how used the display tag is with browsers and websites. A little more detail would have been valuable here IMO.

ref:https://www.w3schools.com/CSSref/pr_class_display.asp

Hi JD,

Curious if you have had an opportunity to test Patch 4 to see how big of an impact on rendering it actually causes? I have not; I've been conducting Zimbra 3-Day Admin Training this week...

All the best,
Mark

[JDunphy]

Hi JD,

Curious if you have had an opportunity to test Patch 4 to see how big of an impact on rendering it actually causes? I have not; I've been conducting Zimbra 3-Day Admin Training this week...

All the best,
Mark

Hi Mark,

I have not tested and applied the patch yet. I did test an email by removing the display attributes directly to get an early idea of what it might be like last weekend. The example that I tested with is what Amazon sends to their re-sellers which is a really odd report about inventory that will blow up and is unreadable without display. The email in question is 110-130 images arranged in a report so that means unless you have already increased zimbraHttpDosFilterMaxRequestsPerSec, it never displays completely anyway but it shows you how reliant some businesses have become in using html and css display.

I'll try this weekend to get actual testing in now that the patch has been released. I have been waiting a few days because recently they seem to release the patch... wait a day or two and quietly update the patch but don't renumber the patch so you end up with "I tried patch X but did you apply patch X on Monday or Wed?" We are really interested in how some newspapers like Washington Post looks for sure. I doubt anything will help that Amazon email however. In fact, I don't even know if they send email like that still but I kept it because it caused me a lot of pain in debugging because the throttling appeared random during the testing with different parts rendered. No teacher like pain as I thought it was browser related. Oops.

My initial spam comment makes no sense and was more of a knee jerk reaction thinking I might loose some capability. I continue to rack my brain trying to understand the threat mentioned. Perhaps an obfuscation attack that could lead to non-direct xss but I can't come up with a direct XSS myself so their statement worries me if they think there could be a direct XSS attack in there somewhere. html5 is a real problem child so they may be attempting to foil some unique ways of encoding or its early days and they haven't finished tuning OWASP.

I was pretty excited about patch 12 when I heard they were adding an OWASP santizer and jumped on it. They lost some of my trust so this thread topic is me not wanting to get burned again because it embarrassed us after we introduced a new bug to our customers on what had been a stable platform. Generally, I normally wait for others to test but the last few patches have been about stopping CWE's. So everyone please patch and let me know.

Jim

PS. We look at html encoding in our email for malware/spam signatures that I call obfuscation methods lacking a better term and I am completely sympathetic to what they are attempting to do here.

[L. Mark Stone]

Hi Jim,

Thanks so much for the detailed analysis and reply.

FWIW I have already set zimbraHttpDosFilterMaxRequestsPerSec to 200. ZeXtras recommends like 150 but even with that I found that DoSFIlter was blocking legitimate use cases in the Admin Console so increased it 200 and haven't had any issues since.

Will be interesting to see if 8.8.15 includes all of these fixes, or something less or something more.

I too don't like that Zimbra reissues patches without loudly broadcasting that they have done so (and boldly annotating the Release Notes accordingly), but as we all know, unit and QA testing is never perfect and all software has bugs (and all hardware eventually fails), so I'd rather Zimbra re-release something quickly than wait a few weeks to the next scheduled release.

With best regards,
Mark