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

31–40 of 93 posts

Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling

#31

Post by mwcampbell »

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 suppose it's safest to use a binary format where variable-length fields are prefixed with their length.

Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling

#32

Post by jandrese »

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.

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.

Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling

#33

Post by Diggsey »

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 be valid in the configured character encoding. That means layer 1 of your decoder should be converting a byte stream into a character stream, and layers 2+ should not even have the opportunity to mess up decoding a character. Efficiency is not a justification, because you can use compile-time techniques to generate the exact same code as if you combined all layers into one. This has the added benefit that it removes edge-cases (if there is one place where bytes are decoded into characters, then you can't get a bug where that decoding is only broken in tag names, and so your test coverage is automatically better).

3) Don't transparently download and install stuff without user interaction, regardless of where it comes from!

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

Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling

#34

Post by zamalek »

Flowdalic wrote: post #2

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.

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.

Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling

#35

Post by teakettle42 »

jandrese wrote: post #32
mwcampbell wrote: post #31

Earlier quoted context omitted.

I suppose it's safest to use a binary format where variable-length fields are prefixed with their length.

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.

> There is nothing inherently safer in binary formats.

Sure there is. Barring a pathologically bad wire format design, they’re easier to parse than an equivalent human editable encoding.

Eliminating the human-editing ability requirement also enables us to:

- Avoid introducing character encoding — a huge problem space just on its own — into the list of things that all parsers must get right.

- Define non-malleable encodings; in other words, ensure that there exists only one valid encoding for any valid message, eliminating parser bugs that emerge around handling (or not) multiple different ways to encode the same thing.

Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling

#36

Post by user23894295637 »

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

Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling

#37

Post by bombcar »

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…

I doubt anyone actively revokes certificates ever - perhaps maybe the game console makers.

Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling

#38

Post by TedDoesntTalk »

zamalek wrote: post #34
Flowdalic wrote: post #2

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.

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.

Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling

#39

Post by TedDoesntTalk »

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?

Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling

#40

Post by jerf »

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.

Assuming properly-created data, yes. You aren't immune to problems but you will reduce them, especially in a memory-safe language.

Unfortunately, in a security context, that is not only not guaranteed, but will be actively attacked, so in practice I'm not sure it buys you that much from a security perspective. A net positive, I think, but certainly not enough that you ca metaphorically kick back and enjoy your lemonade.

The binary format is one of the oldest of security vulnerabilities, by simply claiming a length of larger than the buffer allocated in the C program, though I'm inclined to credit that particular joy to C and not the data itself. Nowadays there aren't many languages where simply claiming to be really long will get you anywhere like that.

Post reply on HN