11 ms·

Zoom: Remote Code Execution with XMPP Stanza Smuggling

231 points by Flowdalic 4y ago

Flowdalic 4y ago
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.
- Aeolun 4y ago
  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.
  - mwcampbell 4y ago
    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.
  - WesolyKubeczek 4y ago
    Using what everyone and their dog is using is prone to bugs just as much because software without bugs doesn't exist or is not very useful, but it also has the benefit of many versatile eyeballs looking at it in many different contexts. So if there's a bug found and fixed in libxml2 which is used by almost everything else, everyone else instantly benefits. Same with libicu which is being used, for example, by NodeJS with its huge deployments footprint. Oh, and every freakin' Webkit-based browser out there. OTOH, they rolled their own, so all bugs they hit are confined only to zoom, and are only guaranteed to get Zoom all the bad press. Choose your poison carefully.
    - Aeolun 4y ago
      If they roll their own it also becomes less interesting to actively exploit. Obviously this doesn’t really work for Zoom any more, since their footprint is too large, but it can stop driveby attackers in other situations. Nobody is going to expend too much effort figuring out joe schmuck’s homegrown solution, where they’d happily run a known exploit against the unpatched wordpress server.
      - pixl97 4y ago
        Security by obscurity has been debated to hell and back. It only works if you stay obsecure... and don't leak your code.
  - eli 4y ago
    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.
    - remus 4y ago
      > You need to not roll your own and also ensure that any third party components didn’t roll their own. If you're not writing the code and somebody else isn't writing the code then who is writing the code?!
      - eli 4y ago
        A well-tested Unicode library built for security should be doing your Unicode parsing in security critical components. It’s just another way of saying you should be doing a security audit as part of selecting a library and integrating it into your product.
  - Flowdalic 4y ago
    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.
- xxpor 4y ago
  This is a very common issue across all of software engineering I've found. But I really don't get why. If I was given the task of parsing Unicode or XML, I'd run and find a library as fast as possible, because that sounds terrible and tedious, and I'd rather do literally anything else! Why aren't people more lazy, in other words?
- zamalek 4y ago
  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.
  - TedDoesntTalk 4y ago
    DOM-based XML parsers use SAX parsing under the hood.
    - zamalek 4y ago
      Right, but if they don't give you access to the SAX parser then you are SOL.
  - Flowdalic 4y ago
    > 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.
    - zamalek 4y ago
      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.
      - Flowdalic 4y ago
        Smack uses an XML pull parser and non-blocking I/O. It does so by splitting the XMPP stream top-level elements first and only feeding complete elements to the pull parser.
        4y ago
- powerapple 4y ago
  IMO we should use external libraries, and should invest engineering time on the library rather than just take a library. Not using good third party library means you need to invest at least a few engineer-month in it to get the same result, and you will need to invest a lot more to do better than third party library. Instead, you can take the library and invest a few engineer month to improve the opensource library.
- account42 4y ago
  Why? If anything, the client does the more reasonable interpretation of the XML-in-malformed-UTF-8 - skipping to the next valid UTF-8 sequence start. It's the server that has really weird behavior for their UTF-8 handling where it somehow special cases multi-byte UTF-8 sequences but then does not handle invalid ones.
dgellow 4y ago
Some 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 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
thinkmassive 4y ago
Heh, it’s like an AIM punter, but better!
dqv 4y ago
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. [0]: https://darknetdiaries.com/episode/93/ https://darknetdiaries.com/episode/93/
kevincox 4y ago
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.
- lovasoa 4y ago
  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.
- fsflover 4y ago
  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.
  - JoshTriplett 4y ago
    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.
    - fsflover 4y ago
      This is however a very different level of sandboxing.
      - JoshTriplett 4y ago
        Sure, but it's much easier for most people to run things in a browser sandbox.
  - jeffbee 4y ago
    How is that helpful? This exploit completely replaces the Zoom software with arbitrary attacker software and it executes in your VM that has access to camera, microphone, network, and presumably screen recording. It sounds to me like the highest possible level of access and your VM is just performative.
henearkr 4y ago
Good thing that I never used the standalone client and always the in-browser webapp instead.
- user23894295637 4y ago
  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 :/
  - mehagar 4y ago
    Check out https://github.com/arkadiyt/zoom-redirector https://github.com/arkadiyt/zoom-redirector. You can also join meetings from https://pwa.zoom.us/wc/ https://pwa.zoom.us/wc/.
    - user23894295637 4y ago
      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.
  - ydant 4y ago
    I've always been able to use the in-browser client, but you have to download the client once or twice before the page will update to show the alternative "use browser". It's definitely an intentional dark pattern.
  - woojoo666 4y ago
    After you click "download Zoom client" the button will turn into a "use Web app". You don't even need to download anything if you cancel the system dialog asking you where to save the download. However I still find this UX pattern incredibly deceptive. People and companies seriously need to stop using Zoom
jeffbee 4y ago
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.
- TedDoesntTalk 4y ago
  We are? Why?
  - defen 4y ago
    Since most software users are not tech-savvy and care about convenience and price significantly more than they care about security (revealed preference), the "worse is better" phenomenon incentivizes commercial developers to implement the minimum security practices that their customers will bear. This is individually rational for the developers and the users, but the result is untold billions of dollars of costs costs. Regulation would be one way to change the incentives.
- userbinator 4y ago
  No. We don't need more authoritarian dystopia.
- turminal 4y ago
  This bug has nothing to do with language choice. I agree that better professional standards and accountability should be introduced for software like zoom though.
twoodfin 4y ago
The XML parsing/validation bugs are, I suppose, not shocking, but deeply disappointing. The one thing 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.) That, 25 years on, a popular XML processor can’t even meet that low bar for tag names is maddening.
- jerf 4y ago
  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 edges and you will find things. This is neat, not because it is special to JSON in particular but because it's an example of examining a good chunk of a large ecosystem: https://seriot.ch/projects/parsing_json.html https://seriot.ch/projects/parsing_json.html Consider this is likely to be true in any ecosystem that doesn't make it a top priority to avoid.
  - lmm 4y ago
    Programmers respond to their incentives. Like most security bugs, this one happened because someone was dumb enough to use C for something connected to the internet. But the reason programmers do that is because of a culture that rewards fast and insecure more than slightly less fast and correct.
  - mwcampbell 4y ago
    I suppose it's safest to use a binary format where variable-length fields are prefixed with their length.
    - jandrese 4y ago
      Sure if you like ingesting 4GB records. There is nothing inherently safer in binary formats. It's easy to write parsers that can handle properly formatted files, it is when you're dealing with corrupt or misformed files that everything gets complicated.
rektide 4y ago
How much of Zoom is powered by XMPP? Do we know much about these internals? This would be super cool to learn about.
bobbylarrybobby 4y ago
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. https://blog.siguza.net/psychicpaper/ https://blog.siguza.net/psychicpaper/
robertlagrant 4y ago
This vuln writeup is extremely well written. Actually quite interesting to read!
pabs3 4y ago
Are these issues bugs in libxml, gloox, ejabberd? Or just in the Zoom client and server?
deleted 4y ago
[deleted]
- deleted 4y ago
  [deleted]
spyc 4y ago
Thanks to Ivan Fratric and Google Project Zero!

231 points by Flowdalic 4y ago

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.

Aeolun 4y ago
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.
- mwcampbell 4y ago
  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.
- WesolyKubeczek 4y ago
  Using what everyone and their dog is using is prone to bugs just as much because software without bugs doesn't exist or is not very useful, but it also has the benefit of many versatile eyeballs looking at it in many different contexts. So if there's a bug found and fixed in libxml2 which is used by almost everything else, everyone else instantly benefits. Same with libicu which is being used, for example, by NodeJS with its huge deployments footprint. Oh, and every freakin' Webkit-based browser out there. OTOH, they rolled their own, so all bugs they hit are confined only to zoom, and are only guaranteed to get Zoom all the bad press. Choose your poison carefully.
  - Aeolun 4y ago
    If they roll their own it also becomes less interesting to actively exploit. Obviously this doesn’t really work for Zoom any more, since their footprint is too large, but it can stop driveby attackers in other situations. Nobody is going to expend too much effort figuring out joe schmuck’s homegrown solution, where they’d happily run a known exploit against the unpatched wordpress server.
    - pixl97 4y ago
      Security by obscurity has been debated to hell and back. It only works if you stay obsecure... and don't leak your code.
- eli 4y ago
  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.
  - remus 4y ago
    > You need to not roll your own and also ensure that any third party components didn’t roll their own. If you're not writing the code and somebody else isn't writing the code then who is writing the code?!
    - eli 4y ago
      A well-tested Unicode library built for security should be doing your Unicode parsing in security critical components. It’s just another way of saying you should be doing a security audit as part of selecting a library and integrating it into your product.
- Flowdalic 4y ago
  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.
xxpor 4y ago
This is a very common issue across all of software engineering I've found. But I really don't get why. If I was given the task of parsing Unicode or XML, I'd run and find a library as fast as possible, because that sounds terrible and tedious, and I'd rather do literally anything else! Why aren't people more lazy, in other words?
zamalek 4y ago
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.
- TedDoesntTalk 4y ago
  DOM-based XML parsers use SAX parsing under the hood.
  - zamalek 4y ago
    Right, but if they don't give you access to the SAX parser then you are SOL.
- Flowdalic 4y ago
  > 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.
  - zamalek 4y ago
    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.
    - Flowdalic 4y ago
      Smack uses an XML pull parser and non-blocking I/O. It does so by splitting the XMPP stream top-level elements first and only feeding complete elements to the pull parser.
      - 4y ago
powerapple 4y ago
IMO we should use external libraries, and should invest engineering time on the library rather than just take a library. Not using good third party library means you need to invest at least a few engineer-month in it to get the same result, and you will need to invest a lot more to do better than third party library. Instead, you can take the library and invest a few engineer month to improve the opensource library.
account42 4y ago
Why? If anything, the client does the more reasonable interpretation of the XML-in-malformed-UTF-8 - skipping to the next valid UTF-8 sequence start. It's the server that has really weird behavior for their UTF-8 handling where it somehow special cases multi-byte UTF-8 sequences but then does not handle invalid ones.

dgellow 4y ago

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

thinkmassive 4y ago

Heh, it’s like an AIM punter, but better!

dqv 4y ago

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. [0]: https://darknetdiaries.com/episode/93/ https://darknetdiaries.com/episode/93/

kevincox 4y ago

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.

lovasoa 4y ago
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.
fsflover 4y ago
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.
- JoshTriplett 4y ago
  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.
  - fsflover 4y ago
    This is however a very different level of sandboxing.
    - JoshTriplett 4y ago
      Sure, but it's much easier for most people to run things in a browser sandbox.
- jeffbee 4y ago
  How is that helpful? This exploit completely replaces the Zoom software with arbitrary attacker software and it executes in your VM that has access to camera, microphone, network, and presumably screen recording. It sounds to me like the highest possible level of access and your VM is just performative.

henearkr 4y ago

Good thing that I never used the standalone client and always the in-browser webapp instead.

user23894295637 4y ago
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 :/
- mehagar 4y ago
  Check out https://github.com/arkadiyt/zoom-redirector https://github.com/arkadiyt/zoom-redirector. You can also join meetings from https://pwa.zoom.us/wc/ https://pwa.zoom.us/wc/.
  - user23894295637 4y ago
    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.
- ydant 4y ago
  I've always been able to use the in-browser client, but you have to download the client once or twice before the page will update to show the alternative "use browser". It's definitely an intentional dark pattern.
- woojoo666 4y ago
  After you click "download Zoom client" the button will turn into a "use Web app". You don't even need to download anything if you cancel the system dialog asking you where to save the download. However I still find this UX pattern incredibly deceptive. People and companies seriously need to stop using Zoom

jeffbee 4y ago

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.

TedDoesntTalk 4y ago
We are? Why?
- defen 4y ago
  Since most software users are not tech-savvy and care about convenience and price significantly more than they care about security (revealed preference), the "worse is better" phenomenon incentivizes commercial developers to implement the minimum security practices that their customers will bear. This is individually rational for the developers and the users, but the result is untold billions of dollars of costs costs. Regulation would be one way to change the incentives.
userbinator 4y ago
No. We don't need more authoritarian dystopia.
turminal 4y ago
This bug has nothing to do with language choice. I agree that better professional standards and accountability should be introduced for software like zoom though.

twoodfin 4y ago

The XML parsing/validation bugs are, I suppose, not shocking, but deeply disappointing. The one thing 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.) That, 25 years on, a popular XML processor can’t even meet that low bar for tag names is maddening.

jerf 4y ago
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 edges and you will find things. This is neat, not because it is special to JSON in particular but because it's an example of examining a good chunk of a large ecosystem: https://seriot.ch/projects/parsing_json.html https://seriot.ch/projects/parsing_json.html Consider this is likely to be true in any ecosystem that doesn't make it a top priority to avoid.
- lmm 4y ago
  Programmers respond to their incentives. Like most security bugs, this one happened because someone was dumb enough to use C for something connected to the internet. But the reason programmers do that is because of a culture that rewards fast and insecure more than slightly less fast and correct.
- mwcampbell 4y ago
  I suppose it's safest to use a binary format where variable-length fields are prefixed with their length.
  - jandrese 4y ago
    Sure if you like ingesting 4GB records. There is nothing inherently safer in binary formats. It's easy to write parsers that can handle properly formatted files, it is when you're dealing with corrupt or misformed files that everything gets complicated.

rektide 4y ago

How much of Zoom is powered by XMPP? Do we know much about these internals? This would be super cool to learn about.

bobbylarrybobby 4y ago

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. https://blog.siguza.net/psychicpaper/ https://blog.siguza.net/psychicpaper/

robertlagrant 4y ago

This vuln writeup is extremely well written. Actually quite interesting to read!

pabs3 4y ago

Are these issues bugs in libxml, gloox, ejabberd? Or just in the Zoom client and server?

deleted 4y ago

[deleted]

deleted 4y ago
[deleted]

spyc 4y ago

Thanks to Ivan Fratric and Google Project Zero!