This vuln writeup is extremely well written. Actually quite interesting to read!
Zoom: Remote Code Execution with XMPP Stanza Smuggling
51–60 of 93 posts
Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling
#52At 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.
No. We don't need more authoritarian dystopia.
Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling
#53It 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.
One of the harder things with XMPP is that it is a badly-formed document up until the connection is closed. You need a SAX-style/event-based parser to handle it. That makes rolling your own understandable in some cases (e.g. dotnet's System.Xml couldn't do this prior to XLinq). That being said, as you indicated Gloox is C-based, and the reference implementation of SAX is in C. There is no excuse.
> One of the harder things with XMPP is that it is a badly-formed document up until the connection is closed. You need a SAX-style/event-based parser to handle it.
That is a common misconception, although I am not sure of its origin. I know plenty of XMPP implementations that use an XML pull parser.
Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling
#54Earlier quoted context omitted.
Unfortunately, the problem here is programmers moreso than formats. It literally doesn't matter what you specify, programmers will not implement it to a T. Most programmers simply don't know that every single detail matters. Many of those who may have some idea don't really care, since they can't imagine how something like this could happen. It's not just XML. It's every ecosystem I've ever used. Push it around the e…
I disagree. The way the format is designed has a direct effect on how likely implementors are to implement it correctly. So the format designers bear some responsibility. For example how many Protobuf parser libraries have security bugs? I'm guessing very few because the standard is nice and simple, and it's very clearly defined without much "it's probably like this" wiggle room (much easier for binary formats!). XML…
Wrong.
If you care about security, verify your goddamn invariants.
This is not a software problem. This is a lazy programmer/software engineer problem. Electrical Engineering, or hell, any matyre engineering field understands this concept.
If you have mot read your entire codepath, you have no idea what it is you are doing.
Welcome to why my life as a QA is effing miserable. Every bit of ignorance by devs following the philosophy of "abstraction is good" is dealt with at the level of Software BoM audit.
All hail Time to Market!
Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling
#55It 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 get your confusion. But keep in mind that it is not only about just picking the library that shows as first result of your Google search. My naive self thinks that a million dollar company should do some research and evaluate different options when choosing external codebase to build their flagship product on. There a dozens of XMPP libraries, and they picked the one that does not seem to delegate XML and Unicode handling to other libraries, which should raise a flag.
Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling
#56Earlier quoted context omitted.
There are just so many issues here. 1) Don't rely on two parsers having identical behaviour for security. Yes parsers for the same format should behave the same, but bugs happen, so don't design a system where small differences result in such a catastrophic bug. If you absolutely have to do this, at least use the same parser on both ends. 2) Don't allow layering violations. All content of XML documents is required to…
I doubt anyone actively revokes certificates ever - perhaps maybe the game console makers.
dsdas
Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling
#57Earlier quoted context omitted.
One of the harder things with XMPP is that it is a badly-formed document up until the connection is closed. You need a SAX-style/event-based parser to handle it. That makes rolling your own understandable in some cases (e.g. dotnet's System.Xml couldn't do this prior to XLinq). That being said, as you indicated Gloox is C-based, and the reference implementation of SAX is in C. There is no excuse.
> One of the harder things with XMPP is that it is a badly-formed document up until the connection is closed. You need a SAX-style/event-based parser to handle it. That is a common misconception, although I am not sure of its origin. I know plenty of XMPP implementations that use an XML pull parser.
It's possible by blocking the thread that's reading the XML, but now you're in thread-per-client territory, and that doesn't scale.
Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling
#58Earlier quoted context omitted.
Unfortunately, the problem here is programmers moreso than formats. It literally doesn't matter what you specify, programmers will not implement it to a T. Most programmers simply don't know that every single detail matters. Many of those who may have some idea don't really care, since they can't imagine how something like this could happen. It's not just XML. It's every ecosystem I've ever used. Push it around the e…
I suppose it's safest to use a binary format where variable-length fields are prefixed with their length.
Sure, until someone sets the prefix to 100MB large, and sends zero bytes of data :)
Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling
#59Earlier quoted context omitted.
How do you do that? On any OS I tried (Debian, Windows) it always *forces* me to download the standalone client, otherwise I can't join. There's no alternative link ("Join via web") like MS Teams has for example. I really feel uncomfortable each time I have to install the client on a machine for my relatives :/
Check out https://github.com/arkadiyt/zoom-redirector . You can also join meetings from https://pwa.zoom.us/wc/ .
OMG, thank you so much! That's a huge relief.
I actually started boycotting Zoom meetings where I can. If anyone sends me a zoom invitation and I know that they are not forced by having to be available for larger audiences I suggest them to use basically anything else.
I don't know why, but from the first time I visited their website until today, I have the feeling I can't trust the company.
Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling
#60Earlier quoted context omitted.
….and I assume the revocation can’t be back-dated?
timestamps must come from a globally recognized signed source, like digicert or verisign.
The CA could backdate the CRL’s revocation timestamp if they wanted, but it seems unlikely and presumably it’s not allowed.