OS: Debian Bookworm amd64 ``` prosody trunk nightly build 1836 (2023-10-27, 8fbdd878fcf6) # Prosody directories Data directory: /var/lib/prosody Config directory: /etc/prosody Source directory: /usr/lib/prosody Plugin directories: /var/lib/prosody/custom_plugins /usr/lib/prosody/modules /var/lib/prosody/prosody-modules /usr/lib/prosody/modules/ # Operating system Linux 6.1.0-13-amd64 # Lua environment Lua version: Lua 5.4 Lua module search paths: /usr/local/share/lua/5.4/prosody/?.lua /usr/local/share/lua/5.4/?.lua /usr/local/share/lua/5.4/prosody/?/init.lua /usr/local/share/lua/5.4/?/init.lua /usr/local/lib/lua/5.4/prosody/?.lua /usr/local/lib/lua/5.4/?.lua /usr/local/lib/lua/5.4/prosody/?/init.lua /usr/local/lib/lua/5.4/?/init.lua /usr/share/lua/5.4/prosody/?.lua /usr/share/lua/5.4/?.lua /usr/share/lua/5.4/prosody/?/init.lua /usr/share/lua/5.4/?/init.lua ./prosody/?.lua ./?.lua ./prosody/?/init.lua ./?/init.lua /var/lib/prosody/custom_plugins/share/lua/5.4/?.lua /var/lib/prosody/custom_plugins/share/lua/5.4/?/init.lua Lua C module search paths: /usr/local/lib/lua/5.4/prosody/?.so /usr/local/lib/lua/5.4/?.so /usr/lib/x86_64-linux-gnu/lua/5.4/prosody/?.so /usr/lib/x86_64-linux-gnu/lua/5.4/?.so /usr/lib/lua/5.4/prosody/?.so /usr/lib/lua/5.4/?.so /usr/local/lib/lua/5.4/loadall.so ./prosody/?.so ./?.so LuaRocks: Not installed # Network Backend: epoll # Lua module versions LuaExpat: 1.5.1 LuaFileSystem: 1.8.0 LuaSec: 1.2.0 LuaSocket: 3.0.0 luaunbound: 1.0.0 readline: 3.1 # library versions libcrypto: OpenSSL 3.0.11 19 Sep 2023 libexpat: expat_2.5.0 libunbound: 1.17.1 ``` ``` Oct 31 19:00:08 c2s556eaa9b4e90 debug RECV: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='SCRAM-SHA-1-PLUS' xml:lang='en'>cD10bHMtZXhwb3J0ZXIsLG49amFlY2tlbCxyPTQ0NkQxQkJCRDg1OTg2NTg1QTlFQUUwOUExNjU0NTkyOTU1MDExRjQzRUVDRkU3MDI1 NDQ2RTQ4RjgyQ0UzRA==</auth> Oct 31 19:00:08 c2s556eaa9b4e90 debug Received[c2s_unauthed]: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='SCRAM-SHA-1-PLUS' xml:lang='en'> Oct 31 19:00:08 c2s556eaa9b4e90 debug Sending[c2s_unauthed]: <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> Oct 31 19:00:08 c2s556eaa9b4e90 debug SEND: <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>cj00NDZEMUJCQkQ4NTk4NjU4NUE5RUFFMDlBMTY1NDU5Mjk1NTAxMUY0M0VFQ0ZFNzAyNTQ0NkU0OEY4MkNFM0QzODY4MmQ0ZC1lY2VkLTRlMTItYTBjZC00NTJhOGYxZTBkN2Yscz1ZbU k1TVdKaU9UTXRNVEV6WmkwMFpqa3dMVGd3TlRrdE1qVTBZamd3T0RRNFlqWmgsaT0xMDAwMA==</challenge> Oct 31 19:00:08 c2s556eaa9b4e90 debug RECV: <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl' xml:lang='en'>Yz1jRDEwYkhNdFpYaHdiM0owWlhJc0xINmRFb3d5QTlzNzM2Q3NhUWtURUxrZE1yWXBGRlE1MDRtRzRUaVhoYVRvLHI9NDQ2RDFCQkJEODU5ODY1ODVBOUVBRTA5QTE2N TQ1OTI5NTUwMTFGNDNFRUNGRTcwMjU0NDZFNDhGODJDRTNEMzg2ODJkNGQtZWNlZC00ZTEyLWEwY2QtNDUyYThmMWUwZDdmLHA9YjljRUthdUpxRm93aGVxVjNLT2pMTlFKSzIwPQ==</response> Oct 31 19:00:08 c2s556eaa9b4e90 debug Received[c2s_unauthed]: <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl' xml:lang='en'> Oct 31 19:00:08 c2s556eaa9b4e90 debug Sending[c2s_unauthed]: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> Oct 31 19:00:08 c2s556eaa9b4e90 debug SEND: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><not-authorized/><text>The response provided by the client doesn't match the one we calculated.</text></failure> Oct 31 19:00:08 c2s556eaa9b4e90 debug RECV: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='SCRAM-SHA-1' xml:lang='en'>cD10bHMtZXhwb3J0ZXIsLG49amFlY2tlbCxyPUREODVDNTlCMjkxMjA3MTcxNkM1QTlDQzBGRkZFNzk2MEU0NjkzNUZCODhFQ0U5NTNFRUQ4N TQ2OEE5Qzg4OA==</auth> Oct 31 19:00:08 c2s556eaa9b4e90 debug Received[c2s_unauthed]: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='SCRAM-SHA-1' xml:lang='en'> Oct 31 19:00:08 c2s556eaa9b4e90 debug Sending[c2s_unauthed]: <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> Oct 31 19:00:08 c2s556eaa9b4e90 debug SEND: <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>cj1ERDg1QzU5QjI5MTIwNzE3MTZDNUE5Q0MwRkZGRTc5NjBFNDY5MzVGQjg4RUNFOTUzRUVEODU0NjhBOUM4ODg2ZDY4M2U2MS1jYzNhLTRiNWItYjQ0Zi05YzZmOGI1ZjdlZTcscz1ZbUk1TVdKaU9UTXRNVEV6WmkwMFpqa3dMVGd3TlRrdE1qVTBZamd3T0RRNFlqWmgsaT0xMDAwMA==</challenge> Oct 31 19:00:08 c2s556eaa9b4e90 debug RECV: <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl' xml:lang='en'>Yz1jRDEwYkhNdFpYaHdiM0owWlhJc0xINmRFb3d5QTlzNzM2Q3NhUWtURUxrZE1yWXBGRlE1MDRtRzRUaVhoYVRvLHI9REQ4NUM1OUIyOTEyMDcxNzE2QzVBOUNDMEZGRkU3OTYwRTQ2OTM1RkI4OEVDRTk1M0VFRDg1NDY4QTlDODg4NmQ2ODNlNjEtY2MzYS00YjViLWI0NGYtOWM2ZjhiNWY3ZWU3LHA9b3lvWFp3TXI5ZlBGOXdGQTJwcTc5VTBDeVdJPQ==</response> Oct 31 19:00:08 c2s556eaa9b4e90 debug Received[c2s_unauthed]: <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl' xml:lang='en'> Oct 31 19:00:08 runner6WTOdAuDDH5U debug changed state from ready to error (ready) Oct 31 19:00:08 c2s556eaa9b4e90 error Traceback[c2s]: /usr/lib/prosody/modules/mod_saslauth.lua:262: attempt to index a nil value (field 'userdata') stack traceback: /usr/lib/prosody/modules/mod_saslauth.lua:262: in field '?' /usr/share/lua/5.4/prosody/util/sasl/scram.lua:201: in function </usr/share/lua/5.4/prosody/util/sasl/scram.lua:93> (...tail calls...) /usr/lib/prosody/modules/mod_saslauth.lua:88: in function </usr/lib/prosody/modules/mod_saslauth.lua:78> (...tail calls...) /usr/share/lua/5.4/prosody/util/events.lua:81: in function </usr/share/lua/5.4/prosody/util/events.lua:77> (...tail calls...) /usr/share/lua/5.4/prosody/core/stanza_router.lua:143: in upvalue 'core_process_stanza' /usr/lib/prosody/modules/mod_c2s.lua:340: in upvalue 'func' /usr/share/lua/5.4/prosody/util/async.lua:144: in function </usr/share/lua/5.4/prosody/util/async.lua:142> ```
The channel binding initialization currently performed when offering stream features¹ needs to be repeated after resetting the SASL handler², or perhaps the 'userdata' should be kept across the :clean_clone() method? ¹ https://hg.prosody.im/trunk/file/8fbdd878fcf6/plugins/mod_saslauth.lua#l305 ² https://hg.prosody.im/trunk/file/8fbdd878fcf6/plugins/mod_saslauth.lua#l54 Likely affects every version since 0.10 when channel binding was first introduced. The lack of reports until now suggests this is rare, so perhaps the safer fix would be to simply close the connection on SASL failure?
OS: Debian Bookworm amd64 ``` prosody trunk nightly build 1836 (2023-10-27, 8fbdd878fcf6) # Prosody directories Data directory: /var/lib/prosody Config directory: /etc/prosody Source directory: /usr/lib/prosody Plugin directories: /var/lib/prosody/custom_plugins /usr/lib/prosody/modules /var/lib/prosody/prosody-modules /usr/lib/prosody/modules/ # Operating system Linux 6.1.0-13-amd64 # Lua environment Lua version: Lua 5.4 Lua module search paths: /usr/local/share/lua/5.4/prosody/?.lua /usr/local/share/lua/5.4/?.lua /usr/local/share/lua/5.4/prosody/?/init.lua /usr/local/share/lua/5.4/?/init.lua /usr/local/lib/lua/5.4/prosody/?.lua /usr/local/lib/lua/5.4/?.lua /usr/local/lib/lua/5.4/prosody/?/init.lua /usr/local/lib/lua/5.4/?/init.lua /usr/share/lua/5.4/prosody/?.lua /usr/share/lua/5.4/?.lua /usr/share/lua/5.4/prosody/?/init.lua /usr/share/lua/5.4/?/init.lua ./prosody/?.lua ./?.lua ./prosody/?/init.lua ./?/init.lua /var/lib/prosody/custom_plugins/share/lua/5.4/?.lua /var/lib/prosody/custom_plugins/share/lua/5.4/?/init.lua Lua C module search paths: /usr/local/lib/lua/5.4/prosody/?.so /usr/local/lib/lua/5.4/?.so /usr/lib/x86_64-linux-gnu/lua/5.4/prosody/?.so /usr/lib/x86_64-linux-gnu/lua/5.4/?.so /usr/lib/lua/5.4/prosody/?.so /usr/lib/lua/5.4/?.so /usr/local/lib/lua/5.4/loadall.so ./prosody/?.so ./?.so LuaRocks: Not installed # Network Backend: epoll # Lua module versions LuaExpat: 1.5.1 LuaFileSystem: 1.8.0 LuaSec: 1.2.0 LuaSocket: 3.0.0 luaunbound: 1.0.0 readline: 3.1 # library versions libcrypto: OpenSSL 3.0.11 19 Sep 2023 libexpat: expat_2.5.0 libunbound: 1.17.1 ``` ``` Oct 31 19:00:08 c2s556eaa9b4e90 debug RECV: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='SCRAM-SHA-1-PLUS' xml:lang='en'>cD10bHMtZXhwb3J0ZXIsLG49amFlY2tlbCxyPTQ0NkQxQkJCRDg1OTg2NTg1QTlFQUUwOUExNjU0NTkyOTU1MDExRjQzRUVDRkU3MDI1 NDQ2RTQ4RjgyQ0UzRA==</auth> Oct 31 19:00:08 c2s556eaa9b4e90 debug Received[c2s_unauthed]: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='SCRAM-SHA-1-PLUS' xml:lang='en'> Oct 31 19:00:08 c2s556eaa9b4e90 debug Sending[c2s_unauthed]: <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> Oct 31 19:00:08 c2s556eaa9b4e90 debug SEND: <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>cj00NDZEMUJCQkQ4NTk4NjU4NUE5RUFFMDlBMTY1NDU5Mjk1NTAxMUY0M0VFQ0ZFNzAyNTQ0NkU0OEY4MkNFM0QzODY4MmQ0ZC1lY2VkLTRlMTItYTBjZC00NTJhOGYxZTBkN2Yscz1ZbU k1TVdKaU9UTXRNVEV6WmkwMFpqa3dMVGd3TlRrdE1qVTBZamd3T0RRNFlqWmgsaT0xMDAwMA==</challenge> Oct 31 19:00:08 c2s556eaa9b4e90 debug RECV: <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl' xml:lang='en'>Yz1jRDEwYkhNdFpYaHdiM0owWlhJc0xINmRFb3d5QTlzNzM2Q3NhUWtURUxrZE1yWXBGRlE1MDRtRzRUaVhoYVRvLHI9NDQ2RDFCQkJEODU5ODY1ODVBOUVBRTA5QTE2N TQ1OTI5NTUwMTFGNDNFRUNGRTcwMjU0NDZFNDhGODJDRTNEMzg2ODJkNGQtZWNlZC00ZTEyLWEwY2QtNDUyYThmMWUwZDdmLHA9YjljRUthdUpxRm93aGVxVjNLT2pMTlFKSzIwPQ==</response> Oct 31 19:00:08 c2s556eaa9b4e90 debug Received[c2s_unauthed]: <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl' xml:lang='en'> Oct 31 19:00:08 c2s556eaa9b4e90 debug Sending[c2s_unauthed]: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> Oct 31 19:00:08 c2s556eaa9b4e90 debug SEND: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><not-authorized/><text>The response provided by the client doesn't match the one we calculated.</text></failure> Oct 31 19:00:08 c2s556eaa9b4e90 debug RECV: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='SCRAM-SHA-1' xml:lang='en'>cD10bHMtZXhwb3J0ZXIsLG49amFlY2tlbCxyPUREODVDNTlCMjkxMjA3MTcxNkM1QTlDQzBGRkZFNzk2MEU0NjkzNUZCODhFQ0U5NTNFRUQ4N TQ2OEE5Qzg4OA==</auth> Oct 31 19:00:08 c2s556eaa9b4e90 debug Received[c2s_unauthed]: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='SCRAM-SHA-1' xml:lang='en'> Oct 31 19:00:08 c2s556eaa9b4e90 debug Sending[c2s_unauthed]: <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> Oct 31 19:00:08 c2s556eaa9b4e90 debug SEND: <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>cj1ERDg1QzU5QjI5MTIwNzE3MTZDNUE5Q0MwRkZGRTc5NjBFNDY5MzVGQjg4RUNFOTUzRUVEODU0NjhBOUM4ODg2ZDY4M2U2MS1jYzNhLTRiNWItYjQ0Zi05YzZmOGI1ZjdlZTcscz1ZbUk1TVdKaU9UTXRNVEV6WmkwMFpqa3dMVGd3TlRrdE1qVTBZamd3T0RRNFlqWmgsaT0xMDAwMA==</challenge> Oct 31 19:00:08 c2s556eaa9b4e90 debug RECV: <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl' xml:lang='en'>Yz1jRDEwYkhNdFpYaHdiM0owWlhJc0xINmRFb3d5QTlzNzM2Q3NhUWtURUxrZE1yWXBGRlE1MDRtRzRUaVhoYVRvLHI9REQ4NUM1OUIyOTEyMDcxNzE2QzVBOUNDMEZGRkU3OTYwRTQ2OTM1RkI4OEVDRTk1M0VFRDg1NDY4QTlDODg4NmQ2ODNlNjEtY2MzYS00YjViLWI0NGYtOWM2ZjhiNWY3ZWU3LHA9b3lvWFp3TXI5ZlBGOXdGQTJwcTc5VTBDeVdJPQ==</response> Oct 31 19:00:08 c2s556eaa9b4e90 debug Received[c2s_unauthed]: <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl' xml:lang='en'> Oct 31 19:00:08 runner6WTOdAuDDH5U debug changed state from ready to error (ready) Oct 31 19:00:08 c2s556eaa9b4e90 error Traceback[c2s]: /usr/lib/prosody/modules/mod_saslauth.lua:262: attempt to index a nil value (field 'userdata') stack traceback: /usr/lib/prosody/modules/mod_saslauth.lua:262: in field '?' /usr/share/lua/5.4/prosody/util/sasl/scram.lua:201: in function </usr/share/lua/5.4/prosody/util/sasl/scram.lua:93> (...tail calls...) /usr/lib/prosody/modules/mod_saslauth.lua:88: in function </usr/lib/prosody/modules/mod_saslauth.lua:78> (...tail calls...) /usr/share/lua/5.4/prosody/util/events.lua:81: in function </usr/share/lua/5.4/prosody/util/events.lua:77> (...tail calls...) /usr/share/lua/5.4/prosody/core/stanza_router.lua:143: in upvalue 'core_process_stanza' /usr/lib/prosody/modules/mod_c2s.lua:340: in upvalue 'func' /usr/share/lua/5.4/prosody/util/async.lua:144: in function </usr/share/lua/5.4/prosody/util/async.lua:142> ```
The channel binding initialization currently performed when offering stream features¹ needs to be repeated after resetting the SASL handler², or perhaps the 'userdata' should be kept across the :clean_clone() method? ¹ https://hg.prosody.im/trunk/file/8fbdd878fcf6/plugins/mod_saslauth.lua#l305 ² https://hg.prosody.im/trunk/file/8fbdd878fcf6/plugins/mod_saslauth.lua#l54 Likely affects every version since 0.10 when channel binding was first introduced. The lack of reports until now suggests this is rare, so perhaps the safer fix would be to simply close the connection on SASL failure?
Changes