Input-output parsing mismatches have repercussions across the Golang ecosystem
A trio of unpatched XML round-trip mutation vulnerabilities in Go’s standard library could lead to SAML authentication bypass in downstream projects, security researchers have revealed.
The open source programming language’s security team have apparently found the critical vulnerabilities, which were traced to Go’s encoding/xml package, fiendishly difficult to resolve.
With Go’s blessing, researchers from messaging platform Mattermost coordinated public disclosure because the vulnerabilities’ root causes “cannot be reliably addressed”, and mitigations planned for an upcoming Go release risked making the flaws public anyway, Juho Nurminen, product security engineer at Mattermost, said in a blog post published on December 14.
Downstream security alerts
With the vulnerabilities posing serious security threats “in key use cases”, researchers privately notified 20 projects across the Go ecosystem in advance of public disclosure, and open-sourced an XML validation library to help them develop mitigations.
Many responded positively but “companies understandably don’t want to comment on ongoing incidents, so we’re not aware how many were able to patch or how quickly,” Nurminen told The Daily Swig.
Other maintainers of potentially affected projects have been urged to review their “codebase for vulnerable patterns”.
The latest version of Mattermost, an open source alternative to Slack and Microsoft Teams collaboration software, fully protects its users from the threat, with Nurminen reporting “no evidence” of exploitation.
The vulnerabilities – XML attribute instability, directive instability, and element instability bugs – all arise from the fact that “maliciously crafted XML markup mutates during round-trips through Go’s decoder and encoder implementations”.
With the semantics thus altered, the issue is “much more serious” than it might sound, suggested Nurminen.
Some applications “require semantic integrity in XML in order to be secure” – not least SAML (Security Assertion Markup Language), a standard approach to conveying user identities during online single sign-on (SSO).
Some Go-based SAML implementations could allow attackers to inject “malicious markup to a correctly signed SAML message”, and “change its semantics to convey a different identity than the original document” without invalidating the cryptographic, XML-DSig signature.
“The result is arbitrary privilege escalation within the scope of the SAML Service Provider, or in some cases even complete authentication bypass,” explains Nurminen.
Uncertain roadmap to remediation
Only one of the three flaws “is on the roadmap to be patched in the foreseeable future”, said Nurminen. In the meantime, a new Go mode will “make explicit that [the other] vulnerabilities exist”.
Having determined that encoding/xml was “not designed to make safe round-trips possible”, Go has decided to launch a new API that allows users to disable namespace prefix parsing, which “will no longer be considered secure for use cases that require round-trip stability.”
However, Mattermost recommends that affected developers continue using its XML validation module even after the new API arrives with Go 1.16 in February, since “parsing and resolving namespaces is an essential requirement for correctly implementing SAML.”
He added: “As a long-term solution, it may make sense to refactor code in a way that avoids encoding round-trips altogether, but it’s unclear if such refactoring is possible in all cases.”
In a post published on GitHub on December 15, Go security lead Filippo Valsorda said a prototype that adds “an IgnoreNamespaces field to Decoder, which when set disables all namespace processing”, had “survived extensive fuzzing”.
Nurminen told The Daily Swig that this was a “great step forward”.
The first vulnerability to surface was discovered on August 28, then traced to the encoding/xml and relayed to Go's core developers on August 31.
The other two flaws were discovered and shared with Go on September 23-24.
Mattermost disabled a potentially vulnerable beta SAML implementation on August 28 and the implementation was absent from version 5.26.2, released on September 8.
Users of older versions can still manually disable the SAML setting.
Nurminen thanked “everyone involved in the process”, especially the “library maintainers who reacted on short notice, immediately recognized the seriousness of the situation, and helped us take the disclosure process over the finish line despite time zone differences and other challenges.”