XSF Discussion - 2022-05-24

moparisthebest: sounds fine to me, but - why?

moparisthebest, to me, at least one canonical way to discover QUIC connectivity (e.g. SRV records) would seem sensible

because the canonical way will be in (hopefully) xep-0156

> is there precedent Like, the core RFC defining both the TCP binding and the SRV discovery method?

no, the opposite, *not* defining port binding or discovery, just saying "that's defined in $other-xep"

very interesting XMPP vuln in Zoom's implementation https://bugs.chromium.org/p/project-zero/issues/detail?id=2254

moparisthebest: is that something that should have attention from our side?

The XML parser stuff might be interesting

As the stanza smuggling attack could also be used on other clients

/servers

It appears that Gloox rolled much of its Unicode and XML parsing code itself, which makes such vulnerabilities more likely. Not using existing libs may be fine if you target constraint low-end embedded devices. But the Zoom client typically runs on none of those

Ah, I thought gloox was an XML parser lib, not an XMPP client library :D

Well, apparently its both :P

If we want to spin the story away from "XMPP is so complicated because it uses Unicode and XML, hence there are such security issues", then we should point out that there are robust, sound, and battle tested libraries for the heavy-lifting of the low-level stuff, which, if used, make such issues much less likely

In fact the Project Zero report even mentions (and praises) ejabberd for its validation

moparisthebest: am I remembering this correctly that you had some quic to xmpp c2s termination proxy thing?

flow, idk seems like most of our vulns have been *because* of using existing XML libs that support way-more-than-XMPP-needs

A found it. Never mind

yep https://github.com/moparisthebest/xmpp-proxy

> Client messages are sent over the same stream connection as control messages from the server. This specifically interests me and is something I've thought about separating in the past. Maybe multiplexed quic streams could do this as an additional separation if security

Maybe that's a naive question but would we use raw quic or rather something bosh over HTTP/3?

the former

use QUIC as a modern replacement for TCP+TLS

don't stuff HTTP in there, that's just needless overhead

I think ^ until websockets-over-http3 is standardized and then we can use that to evade the evil firewalls

aaand here I'm sad again

what's sad about that? a client tries to connect all the ways, it'd probably prefer plain QUIC, but if blocked, go to other methods?

I'd rather have clients take a pickaxe and smash that firewall to pieces

*ahem*

I can't disagree with that

also, all the good technology going to waste just because some idiot firewalls

*but* XMPP has to *just work* like Signal does, users are uninterested with long explanations about how they should talk to their network administrator

so much damage for nothing

see, I'll rather clean the kitchen than continuing to think about this

I'm curious to see if QUIC/http3 itself will actually ever make it through firewalls

So what are the bits (roughly) that a xep would have to specify?

I reckon a ton of networks currently block UDP on port 443

moparisthebest, google will make it happen, one way or another

"hey enterprise, you're using gmail corporate, right? well it will stop working if you don't allowlist udp 443"

Daniel, honestly hardly anything, tl;dr "connect and validate cert like TLS, use bi-directional streams only, each stream is treated as already authenticated as the cert implies, open as many as you want for 'different connections', use connection roaming if you can </eof>"

in some future where google has ensured UDP on 443 always works we could recommend not using stream-management but I think we are far off there (for when you are disconnected and can only connect back over TCP+TLS)

So there wouldn't be any type of a stanza is a frame or something like that? (asking as someone who doesn't know what a frame is)

nope, to application code it's identical to a TCP stream

there are other types of "transports" you can use under a QUIC session but I think they are uninteresting for XMPP, there are one-way streams for instance

ok. i thought that maybe 'frames' could take over some part of stream managment acks or so

My instinct would be that those are orthogonal things at different layers.

https://docs.rs/quinn/latest/quinn/struct.Connection.html#method.send_datagram

that's the other thing you can do besides bi-directional and uni-directional streams

but it's basically sending a UDP packet, un-ordered, no guarantees on delivery, must be "small enough"

Daniel, after tying up some loose ends and writing the XEPs I plan to try to expose xmpp-proxy as a java library and make it take over for Conversation's network code, giving it the ability to do QUIC and Websockets all in one go, no idea how this will work out though :)

it sounds like one of those things that is easier said than done

Daniel, I'd expect XMPP over QUIC feels just like XMPP over TCP+TLS

so instead of a TlsSocket where you shove raw bytes into and read from, you have a QuickSocket

you'd still want to use stream mangement, even if QUIC provides this functionality already, if you want to be able to resume a stream over a different transport mechanism

yep ^

of course you could re-use QUIC resumption is your transport stays QUIC during a connectivity change

so do we know of any XMPP clients that use gloox ? or that parse ascii vs UTF-8 ? seems like this attack is generic in that way

> so instead of a TlsSocket where you shove raw bytes into and read from, you have a QuickSocket That's what I initially hoped but the existing Java quic libraries make this all look a little bit more complex than that

isn't there just one QUIC library for java?

you have to be careful searching for them, old ones say QUIC but mean HTTP3 because that's what it was before it was re-named

moparisthebest, fwiw, these are the reverse dependencies of gloox that ::gentoo nows: https://qa-reports.gentoo.org/output/genrdeps/rindex/net-libs/gloox

you could probably do a similar search for e.g. debian packages

> isn't there just one QUIC library for java? flow: maybe? Which one are you talking about?

hmm gloox hasn't had an update since 2020, wonder if it's still developed or if they were given a heads up, will see if the JID works :)

https://github.com/ptrd/kwik

> The TLS library used by Kwik is also "home made"

hard pass

> it's encrypted and secured by TLS (not as a separate layer, but embedded in the protocol) AIUI you can't use existing TLS libraries as-is unless they have QUIC support

right, but all the maintained ones have that by now

Kwik literally says not to use it for security sensitive things, yet it's a TLS replacement, footgun much

Memberbot is online for our Q2 2022 elections.

Gloox is used by renga, on haiku

^ pulkomandy

Dunno if he's here or just jdev

thanks pep. , joined their muc and let them know

gloox dev's JID is alive, no response yet, I'll say in here if I get one

moparisthebest, what exactly did you ask gloox's dev?

> hi! I got your JID from the gloox website, wondered if you were made aware of a recent vulnerability found in gloox or not? https://bugs.chromium.org/p/project-zero/issues/detail?id=2254

I'd somehow assume that he is aware of this. I wonder if gloox being gpl even suggests that zoom bought a license from him

or if they used gloox under the GPL, which means free zoom source for everyone!!!

Daniel, fwiw: https://github.com/ptrd/kwik/blob/3458cd17f76d9cd0ad0b17536af6bcd03bb96081/src/main/java/net/luminis/quic/run/SampleClient.java#L57-L61

flow: 👍

now of course, the question is if kwik is portable and runs on android

Daniel: please pay attention to "Kwik implemented it's own TLS lib and should not be used" from it's readme

Yes I saw that. I have no plans on using that

yep, that was just to show that quic client libraries provide a stream abstraction of the quic transport

Cool, easy to miss, scares me they don't put that up top :/

I'll soon see how much of a nightmare interfacing rust and Java/Android is in practice :'(

Wow, is Jakob Schröter still maintaining gloox? He's been working on that for ages.

he certainly has

I mean, we had a commercial license for it at JINC circa 2004 (IIRC).

You can tell it's been ages because he uses SVN :)

heh

Could be CVS I guess

> I'd somehow assume that he is aware of this. I wonder if gloox being gpl even suggests that zoom bought a license from him I know Jakob selling licenses was a thing, I would assume Zoom did (shame they didn't pick Swiften :D)

Ah, Peter got here before me.

Kev: what does swiften use for parsing XML?

Seems like this class of bug could be rather widespread

I mean hopefully no XMPP clients are downloading and running software but the impersonation aspect

Expat or libxml2 at user's choice.

libxml2 being the better choice.

s/user's choice/dev's choice/

Would be interesting to do an inventory of all the various XML parsers and see if any parse differently like this

Kev, why libxml2 >> Expat?

And by interesting I mean I would enjoy reading someone else's summary because that seems like an absolutely massive amount of work :D

flow: I honestly don't remember why I think that :D

oh, that's also an expat bug (reported, was it fixed?) and a bug in ejabberd's fast_xml, fun stuff

so much for flow 's "well tested libraries" eh :P

expat CVEs: https://nvd.nist.gov/vuln/detail/CVE-2022-25236 / https://nvd.nist.gov/vuln/detail/CVE-2022-25235

what are we looking at? anything I should watch out for in rxml? dino doesn't have sufficient scrollback and I am too tired to open my poezio shell and scroll.

jonas’, about, 3 or 4 XML-specific bugs not counting the zoom RCE from https://bugs.chromium.org/p/project-zero/issues/detail?id=2254

and yes re: rxml, basically does it parse these the same way expat does, what does it do in the face of utf-8 nonsense etc

in english the bug is roughly "can you pass a single stanza through a server that a client interprets as more-than-one stanza"

if so, since the server isn't checking the inner one, you can spoof literally anything to the client

*Those are the accepted contributors for the XSF!!!* *A warm welcome again Patiga and Pawbud! * *I will communicated via our channels soon! Are there any annotations here?* Patiga: More flexibility in dino file transfers Resource-wise, messenger applications tend to be on the lightweight side of the spectrum. This drastically changes when file transfers are added to the equation. File transfers can introduce arbitrary more resource-usage, both on network and data storage aspects. To alleviate this issue, stateless file sharing empowers the user to make informed decisions on which files to load. Deliverables • Unified handling of http and jingle (peer-to-peer) file transfers • Enable sending metadata alongside files • Thumbnail previews for images https://summerofcode.withgoogle.com/programs/2022/projects/z9ixHTWZ Pawbud: Adding support for Audio/Video Communication via Jingle The idea is to add support for Audio & Video communication through the Jingle protocol. The goal is to create a Converse plugin that adds the ability to make one-on-one audio/video calls from Converse. The audio/video calls will be compatible with other XMPP clients. https://summerofcode.withgoogle.com/programs/2022/projects/0nRwZN19

moparisthebest, well, rxml uses rust strings, and as I don't have any unsafe { from_utf8_unchecked(..) } in there, I should be golden on the UTF-8 front I think.

I suspect so also

oh god

the gloox/expat mixture there is explosive, and a nice find

meanwhile, people complaining that rxml refuses <?xml-stylesheet ..?>

muh nice-looking atom feeds!

I'm pretty much completely convinced at this point that using generic XML libraries for XMPP is a giant mistake

said the one dissecting XMPP streams with .find() ;P

(which is just barely better)

I agree, I just think it's better than pulling in expat, rxml didn't exist at that point :P

may 11 vs. apr 14, you win, but only barely

besides, mine sits in between the server and the client, so I've got parsers on both ends, it doesn't actually matter if I forward crap :D

Wouldn't .find([<>]) be sensitive to broken half of UTF-8 sequences messing with it?

Zash, uhhhh

iiiinteresting

though that'd then drop dead on the real parsers on the other end (if it's not gloox, apparently. or expat?)

which was what I gathered from that Zoom issue

and another point in moparisthebest's favour is that initially, rxml had its own utf8 decoder, which wasn't just slow but also a source of errors (most of which *probably* had eventually been found by fuzzing, but you never know) ✏

that scared me and is why I didn't consider using it originally, but now you said that's gone, and I just haven't went back and looked again yet

I'd only be using it for websocket <-> regular xmpp conversions, the only other thing I use find() for is extracting the target domain from <stream to= which even ejabberd doesn't use a proper XML parser on, it's fine :D

otherwise it doesn't parse any XML, that's the whole point even

doesn't it do that to enforce stanza size limits?

no, it enforces stanza size limits without parsing XML

it counts delimiters, which for me counts as parsing XML

it spits out whole stanzas at a time, that may or may not be valid XML, but they are complete stanzas under the specified length limit

it's only counting, forward-only (never backtracking), not allocating ever, and stops at a pre-defined limit, I know these are famous last words but I don't think it could ever be vulnerable to anything :)

fun fact: a bug in the depth counting in aioxmpp led to a viable remote stanza smuggling attack :)

but that's an XML parser no? this is "here is a byte slice, if it's valid XML it's a whole stanza, not a partial one, have fun"

that was actually after the xml parser

just counting startelement/endelement can be surprisingly tricky

https://github.com/horazont/aioxmpp/commit/29ff0838a40f58efe30a4bbcea95aa8dab7da475 fwiw

the point is you can then use a dom parser, so it's basically like websocket then, you don't need a SAX parser to tell you when a stanza begins/ends

websocket also says "here is a byte slice, if it's valid XML it's a whole stanza, not a partial one, have fun"

moparisthebest, at leat someone will look at the libraries. if everyone uses their own implemention, then bugs will propably go unnoticed forever. Note that I was mentally excluding all C/C++ kind of libaries. I am not sure if any network facing application should ever use those, especially clients, but proably also server applications

How many years have people looked at expat, how many CVEs in the last year

But yes I agree in general that well tested XMPP-specific libraries in sane languages should be used widely

I haven't yet seen anything like rxml in other languages

maybe I should see if I can make a C interface for it?

while I don't see the need for XMPP specific XML and Unicode libraries, I am happy that we can at least aggree that code should be well-tested

that said, I wouldn't mind if XML parsers had different module like "XMPP restricted"

I know the evil unrestricted code would be still there, and depending on the paranoia level, this will bother some

C devs, the theory: I know how to manage my own memory, I won't write unsafe code

C devs, the practice: 85% of security vulnerabilites are unsafe memory management

XMPP devs, the theory: I know how to properly configure expat/my XML lib

XMPP devs, the practice: 85% of security vulnerabilities are mis-configured expat (ok I made up this % but I bet it's close :P)

Well, no, I actually believe first-time XMPP devs will often just grab the XML parser and be happy that it works

So we do have a similar situation here as we have with XHTML-IM: people just use the first tool that comes to their mind, and are happy that it works

that said, I believe software, especially libraries should be as restrictive as possible per default, and "explode" if the boundaries of the restrictions are crossed

then people can decide if they want to relax the restrictions

so lets deprecate xml parsers

every developer needs to write his own from now on

I don't see how XML libraries specialized for XMPP would help, in fact, I fear that this would further fragment the software ecosystem

flow, would you call prosody and ejabberd developers "first-time devs" ? because both have had misconfigured-expat bugs in the last few months

but, again, I wouldn't mind XML parser being restrictive by default and providing specialized modes

we can keep pretending like it won't ever happen again but we all know it will

moparisthebest, well, I did not claim that expert users do not run into this

it's not the fault of any of these devs by the way, it's impossible to sanely configure a beast like that

that statement strikes me as an exaggeration

but that may be because I am happy with my Java parsers :)

ok, let's revisit it if we can go a year without expat problems, let me know :P

(java xml parser exploit in Smack in 5, 4, 3, 2, …) ✏

sure, but I wonder if libxml2 isn't really the go to C(/C++) XML parser

isn't expat the only SAX-capable C/C++ XML parser?

hmm there is also Xerces

which claims to be SAX

which is even more exotic to me than expat fwiw

(also mind that expat is backing python's xml module)

dunno, i've heard and stumbled over xerces in a few places

first time I recall hearing about it

yeah, but I think it's the java flavor of xerces

xerces-c doesn't seem to have that much traction: https://github.com/apache/xerces-c/graphs/contributors

compared with

https://github.com/libexpat/libexpat/graphs/contributors

https://github.com/GNOME/libxml2/graphs/contributors

So, listen, I've just had a completely novel and crazy idea. How about we use something other than XML? I've heard great things about YAML...

cap'n'proto ftw

wow, this is worse than I thought, it's simple math really, let's guess which has more bugs:

$ ./scc libxml2/ ─────────────────────────────────────────────────────────────────────────────── Language Files Lines Blanks Comments Code Complexity ─────────────────────────────────────────────────────────────────────────────── C 107 279146 24353 46516 208277 55075 C Header 66 16451 1547 4402 10502 308

expat: C Header 23 3464 331 1545 1588 40 C 22 29409 2162 2838 24409 4621

rxml: Rust 25 16202 757 1944 13501 444

it's *absolutely astounding* that libxml2 has 10x the C code that expat does holy hell

well, expat doesn't have a DOM, does it. nor does it do xslt or xpath.

wonder how it factors code complexity cause each one is a few orders of magnitude off haha

jonas’, challenge: expat-compatible API for rxml, just no-op all the configuration functions :D

moparisthebest, I have that on my todo, actually, but only for lua-expat :)

flow, xerces: Java 832 260492 31434 86353 142705 30512 almost as many lines as libxml2 but 8x the files, god bless java

Welcome our Google Summer of Code contributors! - Patiga will work on more flexible file transfers in #Dino https://summerofcode.withgoogle.com/programs/2022/projects/z9ixHTWZ - PawBud will work towards adding support for A/V #communication via #Jingle in #ConverseJS https://summerofcode.withgoogle.com/programs/2022/projects/0nRwZN19 #XMPP #GSoC #Google #Standards https://fosstodon.org/web/@xmpp/108358826402429966 https://twitter.com/xmpp/status/1529199174729728000

emus: No one wants to work for Google.

rebeld22, excuse me what?

that's not exactly "welcoming"

jonas’: Sorry, but what you mean?

I assume it's time to say good night! 👻️

I'm in my bed already, but if someone volunteers to guide the user that unspecified asks for help below the Fosstodon tweet - that would be really great! 🙏❤

jonas’, known troll-type

ooh, finally an implementation of SFS

good luck, Patiga! ✏

ooh, that is full of foot-guns of the unlimited-sized-stream variety ala https://www.moparisthebest.com/httppppppppppp-upload/

moparisthebest, maybe you should find them on xmpp and help out?

will there be a muc for this work, or a repo

dino devs have a handle on it :D

heh