XSF Discussion - 2022-05-24

  1. MattJ

    moparisthebest: sounds fine to me, but - why?

  2. jonas’

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

  3. moparisthebest

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

  4. Zash

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

  5. moparisthebest

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

  6. moparisthebest

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

  7. emus

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

  8. vanitasvitae

    The XML parser stuff might be interesting

  9. vanitasvitae

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

  10. vanitasvitae


  11. flow

    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

  12. vanitasvitae

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

  13. vanitasvitae

    Well, apparently its both :P

  14. flow

    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

  15. flow

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

  16. derdaniel

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

  17. moparisthebest

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

  18. Daniel

    A found it. Never mind

  19. moparisthebest

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

  20. Sam

    > 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

  21. Daniel

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

  22. jonas’

    the former

  23. jonas’

    use QUIC as a modern replacement for TCP+TLS

  24. jonas’

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

  25. moparisthebest

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

  26. jonas’

    aaand here I'm sad again

  27. moparisthebest

    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?

  28. jonas’

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

  29. jonas’


  30. moparisthebest

    I can't disagree with that

  31. jonas’

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

  32. moparisthebest

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

  33. jonas’

    so much damage for nothing

  34. jonas’

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

  35. moparisthebest

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

  36. Daniel

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

  37. moparisthebest

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

  38. jonas’

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

  39. jonas’

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

  40. moparisthebest

    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>"

  41. moparisthebest

    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)

  42. Daniel

    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)

  43. moparisthebest

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

  44. moparisthebest

    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

  45. Daniel

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

  46. Zash

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

  47. moparisthebest


  48. moparisthebest

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

  49. moparisthebest

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

  50. moparisthebest

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

  51. moparisthebest

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

  52. flow

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

  53. flow

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

  54. flow

    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

  55. moparisthebest

    yep ^

  56. flow

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

  57. moparisthebest

    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

  58. Daniel

    > 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

  59. flow

    isn't there just one QUIC library for java?

  60. moparisthebest

    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

  61. flow

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

  62. flow

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

  63. Daniel

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

  64. moparisthebest

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

  65. flow


  66. moparisthebest

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

  67. moparisthebest

    hard pass

  68. Zash

    > 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

  69. moparisthebest

    right, but all the maintained ones have that by now

  70. moparisthebest

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

  71. Alex

    Memberbot is online for our Q2 2022 elections.

  72. pep.

    Gloox is used by renga, on haiku

  73. pep.

    ^ pulkomandy

  74. pep.

    Dunno if he's here or just jdev

  75. moparisthebest

    thanks pep. , joined their muc and let them know

  76. moparisthebest

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

  77. flow

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

  78. moparisthebest

    > 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

  79. flow

    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

  80. flow

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

  81. flow

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

  82. Daniel

    flow: 👍

  83. flow

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

  84. moparisthebest

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

  85. Daniel

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

  86. flow

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

  87. moparisthebest

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

  88. moparisthebest

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

  89. stpeter

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

  90. flow

    he certainly has

  91. stpeter

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

  92. moparisthebest

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

  93. stpeter


  94. moparisthebest

    Could be CVS I guess

  95. Kev

    > 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)

  96. Kev

    Ah, Peter got here before me.

  97. stpeter waves to Kev

  98. Kev waves back

  99. moparisthebest

    Kev: what does swiften use for parsing XML?

  100. moparisthebest

    Seems like this class of bug could be rather widespread

  101. moparisthebest

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

  102. Kev

    Expat or libxml2 at user's choice.

  103. Kev

    libxml2 being the better choice.

  104. Kev

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

  105. moparisthebest

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

  106. flow

    Kev, why libxml2 >> Expat?

  107. moparisthebest

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

  108. Kev

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

  109. moparisthebest

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

  110. moparisthebest

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

  111. moparisthebest

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

  112. jonas’

    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.

  113. moparisthebest

    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

  114. moparisthebest

    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

  115. moparisthebest

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

  116. moparisthebest

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

  117. emus

    *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

  118. jonas’

    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.

  119. moparisthebest

    I suspect so also

  120. jonas’

    oh god

  121. jonas’

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

  122. jonas’

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

  123. Zash

    muh nice-looking atom feeds!

  124. moparisthebest

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

  125. jonas’

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

  126. jonas’

    (which is just barely better)

  127. moparisthebest

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

  128. jonas’

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

  129. moparisthebest

    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

  130. Zash

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

  131. jonas’

    Zash, uhhhh

  132. jonas’


  133. jonas’

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

  134. Zash

    which was what I gathered from that Zoom issue

  135. jonas’

    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* have been found by fuzzing, but you never know)

  136. jonas’

    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)

  137. moparisthebest

    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

  138. moparisthebest

    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

  139. moparisthebest

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

  140. jonas’

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

  141. moparisthebest

    no, it enforces stanza size limits without parsing XML

  142. jonas’

    it counts delimiters, which for me counts as parsing XML

  143. moparisthebest

    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

  144. moparisthebest

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

  145. jonas’

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

  146. moparisthebest

    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"

  147. jonas’

    that was actually after the xml parser

  148. jonas’

    just counting startelement/endelement can be surprisingly tricky

  149. jonas’

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

  150. moparisthebest

    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

  151. moparisthebest

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

  152. flow

    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

  153. moparisthebest

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

  154. moparisthebest

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

  155. jonas’

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

  156. jonas’

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

  157. flow

    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

  158. flow

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

  159. flow

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

  160. moparisthebest

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

  161. moparisthebest

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

  162. moparisthebest

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

  163. moparisthebest

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

  164. flow

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

  165. flow

    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

  166. flow

    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

  167. flow

    then people can decide if they want to relax the restrictions

  168. lovetox

    so lets deprecate xml parsers

  169. lovetox

    every developer needs to write his own from now on

  170. flow

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

  171. moparisthebest

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

  172. flow

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

  173. moparisthebest

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

  174. flow

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

  175. moparisthebest

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

  176. flow

    that statement strikes me as an exaggeration

  177. flow

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

  178. moparisthebest

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

  179. flow

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

  180. flow

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

  181. flow

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

  182. jonas’

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

  183. flow

    hmm there is also Xerces

  184. flow

    which claims to be SAX

  185. jonas’

    which is even more exotic to me than expat fwiw

  186. jonas’

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

  187. flow

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

  188. jonas’

    first time I recall hearing about it

  189. flow

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

  190. flow

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

  191. flow

    compared with

  192. flow


  193. flow


  194. Kev

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

  195. flow

    cap'n'proto ftw

  196. moparisthebest

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

  197. moparisthebest

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

  198. moparisthebest

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

  199. moparisthebest

    rxml: Rust 25 16202 757 1944 13501 444

  200. moparisthebest

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

  201. jonas’

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

  202. moparisthebest

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

  203. moparisthebest

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

  204. jonas’

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

  205. moparisthebest

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

  206. emus

    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

  207. rebeld22

    emus: No one wants to work for Google.

  208. jonas’

    rebeld22, excuse me what?

  209. jonas’

    that's not exactly "welcoming"

  210. rebeld22

    jonas’: Sorry, but what you mean?

  211. emus

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

  212. emus

    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! 🙏❤

  213. qy

    jonas’, known troll-type

  214. qy

    ooh, finally an implementation of SFS

  215. qy

    good luck, Pagita

  216. qy

    good luck, Patiga!

  217. moparisthebest

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

  218. qy

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

  219. qy

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

  220. moparisthebest

    dino devs have a handle on it :D

  221. qy