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

71–80 of 93 posts

Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling

#71

Post by RhodesianHunter »

joefkelley wrote: post #67
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…

> 3) Don't transparently download and install stuff without user interaction, regardless of where it comes from! This is an interesting one. I totally get your point. But also users are terrible about updating their software if you give them the choice. Automatic updates have very practical security benefits. I've witnessed non-technical folks hit that "remind me later" button for years .

> I've witnessed non-technical folks hit that "remind me later" button for years.

Doesn't that then become their problem and responsibility then?

Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling

#72

Post by lmm »

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…

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.

Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling

#74

Post by Bootvis »

CaliforniaKarl wrote: post #65
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…

> 4) Revoke certificates for old compromised versions of an installer so that downgrade attacks are not possible. I suggest the following alternative: When your own software is triggering the upgrade process, don't allow triggering an upgrade to an older version of the software. In other words: If a user wants to downgrade, they will have to do the work of running the installer for the older version (and possibly uni…

Not entirely clear to me that would be sufficient a mitigation on this case: the endpoint could claim Zoom version 999 is served and serve the old exe and cab which then would be run, possibly before other checks can even be done.

Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling

#75

Post by powerapple »

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.

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.

Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling

#76

Post by Flowdalic »

zamalek wrote: post #57
Flowdalic wrote: post #53

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 is a common misconception, although I am not sure of its origin. I know plenty of XMPP implementations that use an XML pull parser.

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.

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.

Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling

#77

Post by remus »

lucideer wrote: post #64
twoodfin wrote: post #63

Earlier quoted context omitted.

This is just so basic a screwup though. The W3C spec for XML has had a formal syntactic description of valid tag names for decades: https://www.w3.org/TR/2006/REC-xml11-20060816/#sec-common-sy... Plenty of libraries get this right because it’s so easy. You’d almost have to try—probably by being “clever”—to get it wrong.

While I'm not defending the screw-up here - it's bad - it does do it a slight injustice to omit that the issue was not something simplistic around ascii/utf8 parsing but rather failing to reject/escape malformed-UTF8 strings . Unicode handling even in actual programming language implementations is an extremely common and well-documented problem.

I think it's worth remembering that XML parsing is also a big historic source of bugs which suggests to me that while it may look simple and well formed on the surface it's probably a lot harder than it looks.

Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling

#78

Post by forty »

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.

Not only that, but before the TLS session starts you have to handle an invalid XML document (the starttls mechanism start encrypting stuff right in the middle of the initial XML document). Also some XML constructs are not valid in XMPP (like comments)

I think rolling out your own XML parser for XMPP is a fairly reasonable thing to do. In the past at least, many, if not most, implementations had their own parser (often a fork of a proper XML parser). What is more surprising to me is why would they choose XMPP for their proprietary stuff. I don't think they want to interroperate or federate with anything?

(if I remember correctly and if it hasn't changed compared to many years ago, when I looked at that stuff.)

Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling

#79

Post by autoexec »

fsflover wrote: post #11
kevincox wrote: post #7

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.

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.

The real lesson is not to use Zoom. Anyone who does deserves everything they get. There have been so so many red flags that using Zoom will leak your data to 3rd parties (often in china) and compromise your security that people using it now must simply not care if it happens. So no surprise, it's happened yet again, and you can bet it will again and again in the future.

There are other options besides Zoom. They are different from Zoom, each with their own strengths and weaknesses, but they don't have example after example showing total incompetence and/or malicious intent the way Zoom does.

Re: Zoom: Remote Code Execution with XMPP Stanza Smuggling

#80

Post by forty »

Flowdalic wrote: post #76
zamalek wrote: post #57

Earlier quoted context omitted.

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.

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.

https://github.com/igniterealtime/Smack/blob/master/smack-xm...

I don't see any opportunity not to block when calling "next"

Post reply on HN