XMPP Council - 2022-02-18

  1. SouL has left

  2. moparisthebest has joined

  3. debacle has left

  4. Zash has left

  5. neox has left

  6. larma has left

  7. larma has joined

  8. Sam has left

  9. Sam has joined

  10. menel has joined

  11. ChronosX88 has joined

  12. SouL has joined

  13. ChronosX88 has left

  14. ChronosX88 has joined

  15. Tobias has joined

  16. me9 has joined

  17. marc0s has left

  18. marc0s has joined

  19. dwd has joined

  20. msavoritias has joined

  21. marc0s has left

  22. marc0s has joined

  23. me9 has left

  24. dwd has left

  25. vaulor has left

  26. debacle has joined

  27. vaulor has joined

  28. marc0s has left

  29. marc0s has joined

  30. marc0s has left

  31. marc0s has joined

  32. mdosch has left

  33. mdosch has joined

  34. ChronosX88 has left

  35. ChronosX88 has joined

  36. menel has left

  37. neox has joined

  38. debacle has left

  39. vaulor has left

  40. vaulor has joined

  41. marc0s has left

  42. marc0s has joined

  43. ChronosX88 has left

  44. ChronosX88 has joined

  45. debacle has joined

  46. neox has left

  47. neox has joined

  48. Zash has joined

  49. debacle has left

  50. menel has joined

  51. Kev has left

  52. Kev has joined

  53. menel has left

  54. Wojtek has joined

  55. Wojtek has left

  56. Wojtek has joined

  57. Wojtek has left

  58. Wojtek has joined

  59. marc0s has left

  60. marc0s has joined

  61. Wojtek has left

  62. Wojtek has joined

  63. Wojtek has left

  64. Wojtek has joined

  65. larma has left

  66. menel has joined

  67. Wojtek has left

  68. Wojtek has joined

  69. daniel has left

  70. daniel has joined

  71. Wojtek has left

  72. Wojtek has joined

  73. me9 has joined

  74. vaulor has left

  75. marc0s has left

  76. marc0s has joined

  77. larma has joined

  78. pprrks has joined

  79. vaulor has joined

  80. daniel has left

  81. daniel has joined

  82. menel has left

  83. menel has joined

  84. pprrks has left

  85. me9 has left

  86. Wojtek has left

  87. dwd has joined

  88. debacle has joined

  89. ChronosX88 has left

  90. ChronosX88 has joined

  91. daniel has left

  92. daniel has joined

  93. ChronosX88 has left

  94. ChronosX88 has joined

  95. ChronosX88 has left

  96. ChronosX88 has joined

  97. Tobias has left

  98. Tobias has joined

  99. me9 has joined

  100. Sam

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

  101. moparisthebest

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

  102. Zash

    We're living in a ~11 year time loop

  103. Sam

    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)

  104. Zash

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

  105. Sam

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

  106. Sam

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

  107. Sam

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

  108. Sam


  109. Zash

    '390 advancement?

  110. dwd has left

  111. SouL has left

  112. SouL has joined

  113. paul has left

  114. paul has joined

  115. SouL has left

  116. SouL has joined

  117. me9 has left

  118. dwd has joined

  119. dwd has left

  120. Tobias has left

  121. larma

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

  122. Sam

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

  123. larma

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

  124. larma

    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.

  125. larma

    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.

  126. mathieui

    Sam, isn’t the remediation XEP-039?

  127. mathieui

    Sam, isn’t the remediation XEP-0390?

  128. larma

    Still we should obviously move to 0390

  129. Sam

    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.

  130. pep.

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

  131. Link Mauve

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

  132. Sam

    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.

  133. pep.

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

  134. Zash

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

  135. Link Mauve

    Yeah, as usual. :(

  136. msavoritias has left

  137. Zash

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

  138. mathieui

    can probably bork quite a few feature detections

  139. Link Mauve

    Disable some features.

  140. Sam

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

  141. Zash

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

  142. Link Mauve

    Yet every single XEP still insists on that. ^^

  143. pep.

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

  144. Link Mauve

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

  145. Sam

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

  146. pep.

    There isn't anymore, that's the point

  147. Sam

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

  148. menel has left

  149. pep.

    Feature detection

  150. Sam

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

  151. Zash

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

  152. pep.

    (not my point*)

  153. Sam

    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

  154. SouL has left

  155. neox has left