XMPP Council - 2022-02-18

/cc council, please discuss this or alternate remediation measures again. Thanks. https://github.com/xsf/xeps/pull/1168

what's with all the recent re-discovery of 11+ year old security vulns ? :P

We're living in a ~11 year time loop

Yah, I had a vague recollection that this was a thing, but apparently it never got documented so I wrote an implementation and didn't even do the bare minimum to cover this because the security considerations literally says "don't worry, using this algorithm protects against this kind of attack" (paraphrasing, obviously)

What can you really do with an attack on '115 anyway?

You can fix 1 and 4, the others you can't do anything about.

But that doesn't mean the XEP should ignore them and even claim it's safe.

I'd be inclined to say "just delete the XEP and go back to disco#info rush to encourage someone to implement a replacement".

s/delete/obsolete/

'390 advancement?

Sam, fixing attack 1 is already a MUST in 0115, no?

larma: yes, that's the only one that's mentioned

Attack 4 isn't relevant in practice I guess, because it requires `/` in either @xml:lang or @name, which doesn't happen in practice.

Attack 3 can be prevented (for feature names with http(s)://) by disallowing empty identity @type, which is not allowed under 0030. Features with namespaces that don't have a / are not affected.

For Attack 2 there is a practical way to handle it: for all purposes of service discovery, consider FORM_TYPE of a service discovery extension as if it also was present as <feature> as long as it's sorted behind all actual <feature>. If a given string is ever considered a valid <feature>, it being present as a FORM_TYPE of a services discovery extension and the feature actually not being supported is very unlikely.

Sam, isn’t the remediation XEP-0390? ✏

Still we should obviously move to 0390

mathieui: yes, ideally, but that hasn't been touched, deployed, or discussed for so long that I had completely forgotten this problem existed until someone pointed out that I had just implemented it earlier and that it was probably broiken.

There's an implementation of 390 in xmpp-parsers. And also there's a mod_inject_ecaps2 no?

We have already deployed mod_inject_ecaps2 at JabberFR fyi, in the hope to kickstart its adoption by at least letting developers try it.

Oh nice! I was going to ask if anyone had a public server with an example, I'll have to give that a go at some point.

Yeah this module is 4yo already.. I've also enabled it on my server I think

Suppose the _real_ way to get things moving would be to develop an actual exploit and wave it around threateningly 😈️

Yeah, as usual. :(

What can you even do, in practical terms? Cause some PEP +notify confusion?

can probably bork quite a few feature detections

Disable some features.

Sure, it's not an RCE or anything, but a DOS is still not great.

But we don't have feature detection anymore because of MAM and Carbons (and MUC and offline messages), so...

Yet every single XEP still insists on that. ^^

That's generally the argument but then why do we do caps at all

Also, wrong room, please everyone move to xsf@.

Wait, what? I didn't follow that, how do those things relate to feature detection?

There isn't anymore, that's the point

What do you mean "there isn't"? There isn't what?

Feature detection

Of course there is, everything implements caps; what does MAM have to do with there not being feature detection?

Sam, that you can't know what features someone will have in the future when they read stuff from e.g. MAM

(not my point*)

I guess my brain is broken, because that sentence didn't compute either. Why would I know something in the future? Caps is just about knowing what JIDs support right now. Eg. can I display the call icon because one or more of their resources supports it. I don't see what MAM has to do with it