Zoom: Remote Code Execution with XMPP Stanza Smuggling
bugs.chromium.org
Zoom: Remote Code Execution with XMPP Stanza Smuggling
1–10 of 93 posts
Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling
#2It 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.
Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling
#3Some relevant info in case you don’t want to read the whole description but wonder if you’re concerned by the issue:
> Zoom fixed the server-side issues in February and client-side issues on April 24 in version 5.10.4.
> Zoom published a security bulletin about client-side fixes at https://explore.zoom.us/en/trust/security/security-bulletin
CVE-2022-25235 CVE-2022-25236 Fixed-2022-Apr-24 CVE-2022-22784 CVE-2022-22785 CVE-2022-22786 CVE-2022-22787
Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling
#4Heh, it’s like an AIM punter, but better!
Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling
#5I 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.
Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling
#6It 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.
I find that response a bit strange, since the whole reason the Zoom client has these particular vulnerabilities is because they didn’t roll their own, and instead rely on layers of broken libraries.
It’s quite possible they’d have more bugs without doing that, but re-using existing modules could just as easily have been an even worse idea.
Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling
#7This 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.
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.
Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling
#8It 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.
I find that response a bit strange, since the whole reason the Zoom client has these particular vulnerabilities is because they didn’t roll their own, and instead rely on layers of broken libraries. It’s quite possible they’d have more bugs without doing that, but re-using existing modules could just as easily have been an even worse idea.
I think that's a false dichotomy; IMO the best default choice is to rely on the most well-tested library in any given category. That suggests to me that they should have used expat on the client side.
Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling
#9Good thing that I never used the standalone client and always the in-browser webapp instead.
Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling
#10This 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. 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.
I am not sure this applies in this case. I don't know how Zoom's XMPP backend works, but it could very well parse and serialize and still be vulnerable. If the xml library accepts invalid 3-byte utf8 characters on parse, then its internal representation supports these characters, and I don't see why they would not be serialized just as well.