The XML parsing/validation bugs are, I suppose, not shocking, but deeply disappointing.<p>The <i>one thing</i> XML & its tooling were supposed to get right was document well-formed-ness. Sure, it might be a mess of a standard in other ways, but at least we could agree what a parser should and shouldn’t accept! (Not the case for the HTML tag soup of then or now.)<p>That, 25 years on, a popular XML processor can’t even meet that low bar for <i>tag names</i> is maddening.
It appears that Gloox, a relative low-level XMPP-client C library, rolled much of its Unicode and XML parsing itself, which made such vulnerabilities more likely. There maybe good reasons to not re-use existing modules and rely on external libraries, especially if you target constraint low-end embedded devices, but you should always be aware of the drawbacks. And the Zoom client typically does not run on those.
Some relevant info in case you don’t want to read the whole description but wonder if you’re concerned by the issue:<p>> Zoom fixed the server-side issues in February and client-side issues on April 24 in version 5.10.4.<p>> Zoom published a security bulletin about client-side fixes at <a href="https://explore.zoom.us/en/trust/security/security-bulletin" rel="nofollow">https://explore.zoom.us/en/trust/security/security-bulletin</a><p>CVE-2022-25235
CVE-2022-25236
Fixed-2022-Apr-24
CVE-2022-22784
CVE-2022-22785
CVE-2022-22786
CVE-2022-22787
This is another lesson that you should always parse+serialize rather that just validate. It is much harder to smuggle data this way to exploit different parsers.<p>Basically the set of all messages that will satisfy your validator is far larger than the set of all messages that will be produced by your serializer.
Having multiple, potentially different parsers is incredibly dangerous. One person used the fact that different plist parsers in the macOS kernel choked in different ways when interpreting malformed xml, leading some to believe the plist was "safe" because it did not grant certain permissions, while others trusted this "safe" plist but believed it did grant these permissions.<p><a href="https://blog.siguza.net/psychicpaper/" rel="nofollow">https://blog.siguza.net/psychicpaper/</a>
I didn’t even consider the existence of XMPP vulns until I listened to the Darknet Diaries episode about Kik[0]. It’s a really interesting class of vulnerabilities.<p>[0]: <a href="https://darknetdiaries.com/episode/93/" rel="nofollow">https://darknetdiaries.com/episode/93/</a>
At some point we are going to need enforceable professional standards that effectively deal with commercial software publishers who choose to parse untrusted inputs in non-performance-sensitive contexts with C libraries.