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.
Zoom: Remote Code Execution with XMPP Stanza Smuggling
21–30 of 93 posts
Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling
#22Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling
#23Earlier 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…
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
#24The 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
#25Earlier 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.
Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling
#26Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling
#27Earlier 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?
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
#28Earlier 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?!
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
#29The 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…
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.