XMPP Council - 2022-03-02

'tis time

1) Roll Call

o/

do we get a Ge0rG and/or a larma?

we have a Ge0rG

alright, that's a quorum

2) Agenda Bashing

nothing apparently

3) Editor's Update

nada

4) Items for Voting

emptyset

5) Pending Votes

Ge0rG ... :)

Yeah, tis me.

Ge0rG, you are pending on https://github.com/xsf/xeps/pull/1163, removal of GC 1.0 mentions from '45

It looks like the 0045 editorial f'up has been cleaned up, so I'm +1 on #1163

(expiring this week)

excellent

you are also pending on https://xmpp.org/extensions/inbox/muc-affiliations-versioning.html

muc-affiliations-versioning looks good enough for experimental, but I'd rename "since" to "after" to make it less confusable with timestamps

please raise that feedback on the mailing list

also the namespace attribute debate. I'd prefer a sub-element of the <x/>

next up: https://github.com/xsf/xeps/pull/1168

Ge0rG, that was a +1, wasn't it?

jonas’: +1 to muc-affiliations-versioning

ack

is there a CVE for 0115?

do we even do CVEs for protocol vulnerabilities?

I don't think that CVEs apply to protocols

there's been 1 that I know of for a library (mellium)

that would be more like CWEs

I can't get a response out of gajim or pidgin devs so I'm going to try to create CVEs for them I guess...

+1

+1 to allocating CVEs or +1 to #1168?

they've acknowledged it in MUCs and are trivially vulnerable to undetectable MITM, but no idea on when a fix might arise if ever

+1 to #1168

ack

then we've got https://github.com/xsf/xeps/pull/1158 for you, Ge0rG

(Remove _xmppconnect DNS method from XEP-0156 and add warnings)

+1

(oops I was talking about 1158 anyway...)

Ge0rG, and finally, https://github.com/xsf/xeps/pull/1159

+1

ack

6) Date of Next

+1w wfm

Ge0rG, moparisthebest?

+1w wfm

+1W WFM

excellent

7) AOB

none here

I still have the open AOB about A/V council meetings, but I'd like to postpone that until we have full house.

any other AOB?

taking the silence as a no

8) Ite Meeting Est

thanks all

thanks jonas’ !

thanks jonas’

even if it felt like a criminal interrogation of me only :)

:D

I take that as a compliment ✏

Yes, inspector jonas’

haha yes rather rough meeting for Ge0rG :P

… and do not bring us into temptation …

as a related aside, do you all have experience creating CVEs and know what to put in various boxes like "vendor" etc ?

I've pulled a bunch of those numbers over the years, and it was a different process each time

IIRC there wasn't even anything formal the last times

Vendor is just whomever makes it (I forget the specific problem you were having the other day though, so apologies if I'm restating this); if it's an XEP, it would be the XSF. If it's something else, look up the company or use the name of the project. It might help to look up other CVEs for the same thing and see what's listed

Ge0rG, moparisthebest, the last CVE I pulled (in january) worked via a webform with mitre again

I got stuck on https://cveform.mitre.org/ "vendor" it has a link to a list of vendors that is broken...

so is vendor "gajim" or "ubuntu, debian, redhat, etc etc" ?

I think I put in "Prosody" (in january)

and that was ok

or did I

I guess I can try that and they can just reject it

actually it was eventually assigned by distros@, I'm not sure

They won't reject it for a minor problem with the vendor. It's just informational stuff, this part doesn't even really matter. Just put the name of whomever makes the thing.

The vendor would be Gajim, not every possible distro that repackages it if Gajim is the software the vulnerability is in.

I'll give it another shot thank you all :)

> An attacker who can spoof DNS responses can MITM connections to XMPP servers undetectable because the target domain was validated for the wrong domain name in the certificate.

can anyone help on this language? it doesn't sound quite right...

for the suggested CVE text

obviously undetectably*

s/MITM/intercept/?

moparisthebest, CWE things are typically a handy reference for this

> An attacker who can spoof DNS responses can redirect a client connection to a malicious server. The client will perform TLS certificate verification of the malicious domain name instead of the original XMPP service domain, allowing the attacker to take over control over the XMPP connection and to obtain user credentials and all communication content. ✏

so much better, thanks very much Ge0rG

moparisthebest: you're welcome. Years of writing vulnerability reports finally pay off! :D

Mine probably isn't detailed enough, and yours sounds fine to me, but feel free to steal from it: https://nvd.nist.gov/vuln/detail/CVE-2022-24968

Sam: fine and concise

submitted

oof I probably should have put a link to that CVE in references...

You can update it whenever, doesn't need to be perfect on first submission

ah and yours is specific to WebSocket while gajim (depending on version) and libpurple (always) uses BOSH

Yah, transport doesn't matter though; it's the same issue.

more or less.

yep, and it lets an attacker mitm *any* connection attempt even if your server doesn't support xep-156 or websocket or bosh

actually with a small change my xmpp-proxy will let you do this kind of MITM easily...