Zoom: Remote Code Execution with XMPP Stanza Smuggling

Post by fsflover » Tue, May 24, 2022, 4:13 PM UTC

kevincox wrote: post #7

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. 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.

Post by WesolyKubeczek » Tue, May 24, 2022, 4:20 PM UTC

Aeolun wrote: post #6

Flowdalic wrote: post #2

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.

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.

Post by eli » Tue, May 24, 2022, 4:28 PM UTC

Aeolun wrote: post #6

Flowdalic wrote: post #2

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.

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.

Post by remus » Tue, May 24, 2022, 4:40 PM UTC

eli wrote: post #15

Aeolun wrote: post #6

Earlier quoted context omitted.

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 the point is that Unicode and XML parsing are known to be security critical components and you should take care that they are handled only by well tested code designed specifically for the purpose. You need to not roll your own and also ensure that any third party components didn’t roll their own.

Post by fsflover » Tue, May 24, 2022, 4:41 PM UTC

JoshTriplett wrote: post #16

fsflover wrote: post #11

Earlier quoted context omitted.

Or, it's another lesson that you should not completely trust any code but compartmentalize instead. Thanks to Qubes OS, I am still safe, since Zoom is running in a hardware-virtualized VM.

I'm safe as well, because I only use the web version of Zoom. Code you don't trust should always run in a sandbox, if it runs at all.