Secrutiy Patch 10.1.5 10.0.13 9.0.0p44 any Idea to patch 8.8.15p46 with that fix?

[Klug]

Digging in a bit more, the ZBUG-4048 commits are about requiring auth on the change password endpoint so that it can't bypass 2FA, which definitely isn't critical.

This might be the "There are changes in ChangePassword SOAP API. Please refer to API reference documentation. If you have custom auth implementation with ChangePassword, please incorporate changes to support new API changes. " that is in the release notes.

[Klug]

The files that were modified last week in reference to ZBUG-4238 were modified again 3 days ago (or pushed again?)
Commit ID is the same: https://github.com/Zimbra/zm-web-client ... 744ed9b14c

Parent is ZCS-15582: https://github.com/Zimbra/zm-web-client ... 9e6323be8a
I did not see that one on monday.

[jered]

The files that were modified last week in reference to ZBUG-4238 were modified again 3 days ago (or pushed again?)
Commit ID is the same: https://github.com/Zimbra/zm-web-client ... 744ed9b14c

Parent is ZCS-15582: https://github.com/Zimbra/zm-web-client ... 9e6323be8a
I did not see that one on monday.

The ZBUG-4238 fix previously appeared on the 10.1.3 and 10.1.4 tags as an October commit, but not on the develop branch until just now. This is very confusing, as it's not clear that this is the new issue: https://github.com/Zimbra/zm-web-client ... 3b14425db8

[adrian.gibanel.btactic]

The files that were modified last week in reference to ZBUG-4238 were modified again 3 days ago (or pushed again?)
Commit ID is the same: https://github.com/Zimbra/zm-web-client ... 744ed9b14c

Parent is ZCS-15582: https://github.com/Zimbra/zm-web-client ... 9e6323be8a
I did not see that one on monday.

The ZBUG-4238 fix previously appeared on the 10.1.3 and 10.1.4 tags as an October commit, but not on the develop branch until just now. This is very confusing, as it's not clear that this is the new issue: https://github.com/Zimbra/zm-web-client ... 3b14425db8

You are right!

That commit is related to 10.1.3:

CVE-2024-54663 : A Local File Inclusion (LFI) vulnerability in the /h/rest endpoint, allowing authorized remote attackers to access sensitive files in the WebRoot using their valid auth tokens, has been fixed to prevent unauthorized file access.
An XSS vulnerability in the /h/rest endpoint, which allows authorized remote attackers to exploit it using their valid auth tokens, has been fixed to prevent arbitrary JavaScript execution.

So... Zimbra has managed to embargo its vulnerability fix commits properly despite of what we thought originally.
We will have to wait for 7 days since the NE release hopefully.

They have even changed the build system to use different repos to build Zimbra (based on additional suffix on the repo name).

Example:

Code: Select all

# Push zm-mailbox as zm-mailbox_vuln134
# Push zm-web-client as zm-web-client_vuln134

./build.pl --repo_name_suffix=_vuln1234

That way it's even easier for them not to push vulnerability specific commits to the public repos before the embargo ends.

Regarding develop branch having commits in a different order than the tags, well, that's to be expected. That's why I only build from tags and I encourage others to do so.

[bulletxt]

From your knowledge, is this CVE critical?

[Klug]

There's also ZBUG-4109 commited four days ago (in develop branch).
https://github.com/Zimbra/zm-web-client ... a7e6bea831

[ghen]

This is again an old commit that for some reason re-appears as new.
This change was already part of 9.0 Patch 41 (September 2024).

[jered]

From your knowledge, is this CVE critical?

It sure would be nice to have some information on this from Synacor, wouldn't it? What we know:

• The blog post says "Patch Security Severity: High" and "APPLY THIS PATCH IMMEDIATELY". This severity and language has not been used on previous 10.1.x patch releases,
• The 10.1.5 patch reversed other security improvements to allow customers delaying 10.1.4 updates to apply 10.1.5,
• The 10.1.4 (?) release notes have been updated to describe the CVE as "A Cross-Site Scripting (XSS) vulnerability via crafted <img> HTML content in the Zimbra Classic UI has been fixed. LC attribute zimbra_owasp_strip_alt_tags_with_handlers introduced in previous patch is no longer required and has been removed." (https://wiki.zimbra.com/wiki/Zimbra_Releases/10.1.4)
• A third-party enrichment service identifies a CVSS of 6.1 (https://www.tenable.com/cve/CVE-2024-45516), although this may not be meaningful (https://daniel.haxx.se/blog/2025/01/23/ ... ead-to-us/). They describe it as "A remote attacker can trick the victim to follow a specially crafted link and execute arbitrary HTML and script code in user's browser in context of vulnerable website."
• The one line of change previously shared looks like it was regarding calendar invite content sanitization, and calendar invites often trigger automatic processing.

I don't think this is critical in the same way as past RCE vulnerabilities have been, and clearly "not using the web UI" is a possible (though perhaps untenable) workaround. Still, it's an XSS and depending on how easily exploitable and how scriptable the classic UI is, it means that an attacker could perform (plausibly) any action as the logged-in user -- sending, deleting, forwarding etc email, for example.

The reference to localconfig "zimbra_owasp_strip_alt_tags_with_handlers" is interesting because it does not appear anywhere in the public repos.

[JDunphy]

We are now past 7 days:

Code: Select all

%  ./build_zimbra.sh --tags 9.0
Version 9.0 is a recognized version pattern.
Building tags for version 9.0
..............Latest is [9.0.0.p43]

We are now passed 7 days.

How long to wait before building? Do you have any guidance Synacor employees for FOSS builds with these critical security patches.

If it's not time based for FOSS builds, how about some meta data where you don't have to show the source code but the community is in the loop. Someone must be tracking what they need to add to the public githubs correct? Could be a simple as this:

Code: Select all

Patch ID: Zimbra-2023-001
Description: CVE-2023-XXXX: Remote code execution vulnerability in Web Client
Commercial Version Timestamp: 2023-10-01
FOSS Version Timestamp: Expected by 2023-10-08
Status: Scheduled for FOSS Release on 2023-10-08

Jim

[adrian.gibanel.btactic]

How long to wait before building? Do you have any guidance Synacor employees for FOSS builds with these critical security patches.

If it's not time based for FOSS builds, how about some meta data where you don't have to show the source code but the community is in the loop. Someone must be tracking what they need to add to the public githubs correct? Could be a simple as this:

Code: Select all

Patch ID: Zimbra-2023-001
Description: CVE-2023-XXXX: Remote code execution vulnerability in Web Client
Commercial Version Timestamp: 2023-10-01
FOSS Version Timestamp: Expected by 2023-10-08
Status: Scheduled for FOSS Release on 2023-10-08

Jim

Good luck on getting feedback from Synacor.

I also asked feedback to the community for a new repo called zimbra-releases-data that could help automate Foss build but now that we have automated that part it would not be needed any more.

In any case a new simple repo called zimbra-foss-releases which gets tags (same name as versions) pushed to it when a Foss version has been fully pushed to all of the Zimbra foss repos should do it.
No need to add any commit but the initial commit. Just push tags and that's it.

No need to setup any new fancy news feed, wiki page, webpage or github repo as Jdunphy proposal might imply where FOSS future releases (based only on source code) have their release date announced.
I just ask for a tag to be pushed in an specific repo.