Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zoom: Remote Code Execution with XMPP Stanza Smuggling

bugs.chromium.org

Post reply on HN
Print view View original

41–50 of 93 posts

Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling

#41

Post by iancarroll »

Diggsey wrote: post #33
twoodfin wrote: post #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…

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…

> Revoke certificates for old compromised versions of an installer so that downgrade attacks are not possible.

Worth noting that Windows accepts signatures from revoked code signing certificates so long as it has a signed timestamped before the revocation.

Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling

#42

Post by hamandcheese »

iancarroll wrote: post #41
Diggsey wrote: post #33

Earlier 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…

> Revoke certificates for old compromised versions of an installer so that downgrade attacks are not possible. Worth noting that Windows accepts signatures from revoked code signing certificates so long as it has a signed timestamped before the revocation.

….and I assume the revocation can’t be back-dated?

Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling

#43

Post by pixl97 »

Aeolun wrote: post #23
WesolyKubeczek wrote: post #13

Earlier quoted context omitted.

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.

Security by obscurity has been debated to hell and back. It only works if you stay obsecure... and don't leak your code.

Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling

#44

Post by mehagar »

user23894295637 wrote: post #36
henearkr wrote: post #9

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

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

Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling

#45

Post by ydant »

user23894295637 wrote: post #36
henearkr wrote: post #9

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

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 :/

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.

Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling

#46

Post by amluto »

mwcampbell wrote: post #31
jerf wrote: post #29

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

More generally, if you want to include a block of untrustworthy structured data in a protocol, it’s very much preferable to do so in a way that does not require inspecting the data in question to figure out where it ends and thus where the outer protocol resumes.

English is not immune. Think about “who’s on first” — there is no way to distinguish the untrustworthy name “who” from a grammatical part of the conversation.

Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling

#47

Post by ComputerGuru »

hamandcheese wrote: post #42
iancarroll wrote: post #41

Earlier quoted context omitted.

> Revoke certificates for old compromised versions of an installer so that downgrade attacks are not possible. Worth noting that Windows accepts signatures from revoked code signing certificates so long as it has a signed timestamped before the revocation.

….and I assume the revocation can’t be back-dated?

timestamps must come from a globally recognized signed source, like digicert or verisign.

Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling

#48

Post by IshKebab »

jerf wrote: post #29
twoodfin wrote: post #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…

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 had a ton of unnecessary complexity that could have been avoided to make implementations simpler. I haven't actually read this bug so let's see if it was one of:

* Closing tags having to repeat the name / two different ways of closing tags.

* CDATA

* Namespaces (especially how they are defined)

* &entities;

Edit: Ha it wasn't any of those - but it was still an issue with text based formats. Seems like Expat assumes the content is valid UTF-8 (and doesn't validate it), while Gloox assumes it is ASCII. Obviously this couldn't have happened with binary formats.

If you care about security DON'T USE TEXT FORMATS!

Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling

#49

Post by zamalek »

TedDoesntTalk wrote: post #38
zamalek wrote: post #34

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

DOM-based XML parsers use SAX parsing under the hood.

Right, but if they don't give you access to the SAX parser then you are SOL.

Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling

#50

Post by defen »

TedDoesntTalk wrote: post #39
jeffbee wrote: post #22

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.

We are? Why?

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.
Post reply on HN