Live data from Hacker News

Zoom: Remote Code Execution with XMPP Stanza Smuggling

bugs.chromium.org

21–30 of 93 posts

Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling

#21

Earlier quoted context omitted.

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.

This is however a very different level of sandboxing.

Sure, but it's much easier for most people to run things in a browser sandbox.

Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling

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

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…

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.

Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling

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

Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling

#25
post #18

Earlier quoted context omitted.

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.

1. It will not have access to anything else than Zoom. 2. It will not have access to the camera or network, when I'm not using Zoom. 3. If I'm using a disposable VM, it's cleaned every reboot. > and presumably screen recording Screen recording of this VM.

How is screen recording only of Zoom itself of any use to you?

Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling

#27
post #25

Earlier quoted context omitted.

1. It will not have access to anything else than Zoom. 2. It will not have access to the camera or network, when I'm not using Zoom. 3. If I'm using a disposable VM, it's cleaned every reboot. > and presumably screen recording Screen recording of this VM.

How is screen recording only of Zoom itself of any use to you?

If needed, I can move a presentation to that VM, or open a browser in it.

It gets a bit complicated if you want to share a screen from another VM, see https://forum.qubes-os.org/t/share-screen-of-qube-with-anoth...

Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling

#28
post #17
post #15

Earlier quoted context omitted.

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.

> 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?!

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.

Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling

#29

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…

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 Consider this is likely to be true in any ecosystem that doesn't make it a top priority to avoid.

Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling

#30
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/

Post reply on HN