ngircd-19.2 to ngircd-20 upgrade produces "Bad server password" for all connecting clients
Hello, After updating to ngircd-20 from ngircd-19.2 with the same build options, all connecting clients are rejected with "Bad server password". The configuration file remained unchanged between the ngircd-20 upgrade. Am I missing something obvious? The server password is made of [0-9A-Za-z\x5e]{22} ngircd-20 was compiled with the same flags as ngircd-19.2: ./configure --enable-ipv6 --with-openssl CFLAGS="-Wall -D_FORTIFY_SOURCE=2 -O2 -fPIE -pie -fstack-protector" Syslog support: yes Enable debug code: no zlib compression: yes IRC sniffer: no Use TCP Wrappers: no Strict RFC mode: no IDENT support: no IRC+ protocol: yes IPv6 protocol: yes I/O backend: "epoll(), select()" PAM support: no SSL support: openssl libiconv support: no No errors or oddities are reported in /var/log/syslog and the start-up looks to be normal. Revering to 19.2 restores connectivity despite the "password too long" warning. Dec 19 09:00:20 localhost ngircd[1906]: /usr/local/etc/ngircd.conf, line 33: Value of "Password" too long! Dec 19 09:00:20 localhost ngircd[1906]: ngIRCd 20-IPv6+IRCPLUS+SSL+SYSLOG+ZLIB-i686/pc/linux-gnu started. Dec 19 09:00:20 localhost ngircd[1906]: Using configuration file "/usr/local/etc/ngircd.conf" ... Dec 19 09:00:20 localhost ngircd[1906]: Configuration option "DHFile" not set! Dec 19 09:00:20 localhost ngircd[1906]: OpenSSL 1.0.1 14 Mar 2012 initialized. Dec 19 09:00:20 localhost ngircd[1906]: Changed root and working directory to "/var/chroot". Dec 19 09:00:20 localhost ngircd[1907]: Running as user unknown(65534), group unknown(65534), with PID 1907. Dec 19 09:00:20 localhost ngircd[1907]: Running with root directory "/var/chroot". Dec 19 09:00:20 localhost ngircd[1907]: IO subsystem: epoll (hint size 100, initial maxfd 100, masterfd 4). Dec 19 09:00:20 localhost ngircd[1907]: Created pre-defined channel "#channel" Dec 19 09:00:20 localhost ngircd[1907]: Now listening on [0::]:1643 (socket 7). Dec 19 09:00:20 localhost ngircd[1907]: Now listening on [192.168.1.1]:1643 (socket 8). Dec 19 09:04:51 localhost ngircd[3177]: /usr/local/etc/ngircd.conf, line 33: Value of "Password" too long! Dec 19 09:04:51 localhost ngircd[3177]: ngircd 19.2-SYSLOG+ZLIB+SSL+IRCPLUS+IPv6-i686/pc/linux-gnu started. Dec 19 09:04:51 localhost ngircd[3177]: Using configuration file "/usr/local/etc/ngircd.conf" ... Dec 19 09:04:51 localhost ngircd[3177]: Configuration option "SSLDHFile" not set! Dec 19 09:04:51 localhost ngircd[3177]: OpenSSL 1.0.1 14 Mar 2012 initialized. Dec 19 09:04:51 localhost ngircd[3177]: Changed root and working directory to "/var/chroot". Dec 19 09:04:51 localhost ngircd[3178]: Running as user unknown(65534), group unknown(65534), with PID 3178. Dec 19 09:04:51 localhost ngircd[3178]: Running with root directory "/var/chroot". Dec 19 09:04:51 localhost ngircd[3178]: IO subsystem: epoll (hint size 100, initial maxfd 100, masterfd 4). Dec 19 09:04:51 localhost ngircd[3178]: Created pre-defined channel "#channel" Dec 19 09:04:51 localhost ngircd[3178]: Now listening on [0::]:1643 (socket 7). Dec 19 09:04:51 localhost ngircd[3178]: Now listening on [192.168.1.1]:1643 (socket 8). Any insight or help is appreciated. Thank you for your time and efforts around ngircd. Respectfully, Nathan
On Wed, Dec 19, 2012 at 09:20:07AM -0600, lists@packetmail.net wrote:
Hello,
After updating to ngircd-20 from ngircd-19.2 with the same build options, all connecting clients are rejected with "Bad server password". The configuration file remained unchanged between the ngircd-20 upgrade. Am I missing something obvious? The server password is made of [0-9A-Za-z\x5e]{22}
Please verify that "ngircd --configtest" results in the expected values for the "Password" configuration variable with version 20.
No errors or oddities are reported in /var/log/syslog and the start-up looks to be normal. Revering to 19.2 restores connectivity despite the "password too long" warning.
This is quite "undefined behaviour": the server can't store your configured password, so it's quite uncertain with which password it will/can compare the passwords it receives from clients ... Do your clients pass in the "too long" password or the one cut off and used by ngIRCd? But all in all, you should fix your configuration :-) Regards Alex
On 12/19/2012 09:53 AM, Alexander Barton wrote:
Please verify that "ngircd --configtest" results in the expected values for the "Password" configuration variable with version 20.
v19.2: Truncated last two characters v20: Truncated last two characters Running --configtest shows both values are being the same.
This is quite "undefined behaviour": the server can't store your configured password, so it's quite uncertain with which password it will/can compare the passwords it receives from clients ...
Do your clients pass in the "too long" password or the one cut off and used by ngIRCd?
This one I'm not sure about because I'm using SSL and have compiled without 'sniffer'. I suspect they are passing the "too long" password and v19.2 was truncating the received password which would then match the configured password whereas v20 is not truncating received password resulting in a mismatch?
But all in all, you should fix your configuration :-)
Agree, I inherited this configuration from a friend during a network transition. :) That being said, with --configtest showing equal values for the password between v19.2 and v20, do you have any thoughts? Thanks, Nathan
On Wed, Dec 19, 2012 at 10:27:44AM -0600, lists@packetmail.net wrote:
On 12/19/2012 09:53 AM, Alexander Barton wrote:
Please verify that "ngircd --configtest" results in the expected values for the "Password" configuration variable with version 20.
v19.2: Truncated last two characters v20: Truncated last two characters
Running --configtest shows both values are being the same.
Ok, that's good to know in the first place :-)
Do your clients pass in the "too long" password or the one cut off and used by ngIRCd?
This one I'm not sure about because I'm using SSL and have compiled without 'sniffer'. I suspect they are passing the "too long" password and v19.2 was truncating the received password which would then match the configured password whereas v20 is not truncating received password resulting in a mismatch?
I suspect that this is the case, yes ...
But all in all, you should fix your configuration :-)
Agree, I inherited this configuration from a friend during a network transition. :) That being said, with --configtest showing equal values for the password between v19.2 and v20, do you have any thoughts?
If your clients pass in the "too long" password, there is not much we can do: the passwords don't match. But if they pass in the truncated password, it should work. I'll have a look at it later this evening ... Regards Alex
On 12/19/2012 11:09 AM, Alexander Barton wrote:
If your clients pass in the "too long" password, there is not much we can do: the passwords don't match. But if they pass in the truncated password, it should work. I'll have a look at it later this evening ...
Thank you Alex for your time regarding this as well as your detailed replies. I've been trying to diff 19.2 against 20 but nothing is standing out at me. Obviously you know the code much better than I. Cheers, Nathan
On Wed, Dec 19, 2012 at 11:14:33AM -0600, lists@packetmail.net wrote:
On 12/19/2012 11:09 AM, Alexander Barton wrote:
If your clients pass in the "too long" password, there is not much we can do: the passwords don't match. But if they pass in the truncated password, it should work. I'll have a look at it later this evening ...
Thank you Alex for your time regarding this as well as your detailed replies. I've been trying to diff 19.2 against 20 but nothing is standing out at me. Obviously you know the code much better than I.
Hm, I can't reproduce your problem ... I configured ngIRCd 20 with a password that's too long and becomes cut off after 20 characters: In ngircd.conf: Password = 1234567890abcdefghij1234567890abcdefghij1234567890 "ngircd --configtest" shows: test.conf, line 10: Value of "Password" too long! Password = 1234567890abcdefghij But I can still successfully log in using a) the cut of password of 20 characters length, b) and all passwords that differe only in character >20. IRC commands are (you can test this using "nc", "telnet", "gnutls-cli", or "openssl s_client"): PASS 1234567890abcdefghij NICK TestNick USER User . . :Real Name Or PASS 1234567890abcdefghijXYZ NICK TestNick USER User . . :Real Name So this all seems to be fine. But I don't have a clue whats wrong with your daemon!? Regards Alex
On 12/19/2012 01:55 PM, Alexander Barton wrote:
So this all seems to be fine. But I don't have a clue whats wrong with your daemon!?
Weird! ngircd-19.2, in configuration Password = 1AppleJuicefor3dLz^ABC PASS 1AppleJuicefor3dLz^ABC NICK Nathan_ USER User . . :Real Name :redacted 004 Nathan_ redacted ngircd-19.2 acCiorRswx beiIklmnoOPrRstvz ngircd-20, same configuration file (untouched) Password = 1AppleJuicefor3dLz^ABC PASS 1AppleJuicefor3dLz^ABC NICK Nathan_ USER User . . :Real Name ERROR :Access denied: Bad password? closed Basically, configuration file untouched. Both daemons built with same exact configure flags, make, make install. Weird eh? Could it be the use of the carat? Thanks, Nathan
On Wed, Dec 19, 2012 at 02:06:59PM -0600, lists@packetmail.net wrote:
ngircd-20, same configuration file (untouched) Password = 1AppleJuicefor3dLz^ABC
PASS 1AppleJuicefor3dLz^ABC NICK Nathan_ USER User . . :Real Name ERROR :Access denied: Bad password? closed
The same password and exactly this command sequence works (copy-paste!) for me, so ... WTF!? Could you post the first line of "ngircd --version" including the build time options, please? This should look like this: ngIRCd 20-IRCPLUS+SYSLOG+ZLIB-x86_64/apple/darwin12.2.0 And which platform, operating system, and configure options are you using? Alex
On 12/19/2012 02:17 PM, Alexander Barton wrote:
The same password and exactly this command sequence works (copy-paste!) for me, so ... WTF!?
Haha, crazy!
Could you post the first line of "ngircd --version" including the build time options, please? This should look like this:
ngIRCd 20-IRCPLUS+SYSLOG+ZLIB-x86_64/apple/darwin12.2.0
And which platform, operating system, and configure options are you using?
Absolutely. Wonder if PIE is causing the issues? ./configure --enable-ipv6 --with-openssl CFLAGS="-Wall -D_FORTIFY_SOURCE=2 -O2 -fPIE -pie -fstack-protector" Linux packetmail 3.2.0-35-generic-pae #55-Ubuntu SMP Wed Dec 5 18:04:39 UTC 2012 i686 i686 i386 GNU/Linux Ubuntu 12.04.1 LTS Here are banners when I was testing openssl s_client -connect: Dec 19 14:03:25 localhost ngircd[4579]: ngIRCd 20-IPv6+IRCPLUS+SSL+SYSLOG+ZLIB-i686/pc/linux-gnu started. Dec 19 14:04:04 localhost ngircd[4859]: ngircd 19.2-SYSLOG+ZLIB+SSL+IRCPLUS+IPv6-i686/pc/linux-gnu started. No SELinux and AppArmor doesn't show any issues/problems. Thanks, Nathan
On Wed, Dec 19, 2012 at 02:20:23PM -0600, lists@packetmail.net wrote:
On 12/19/2012 02:17 PM, Alexander Barton wrote:
The same password and exactly this command sequence works (copy-paste!) for me, so ... WTF!?
Haha, crazy!
Yeah. Me. Sorry for the confusion, but I was testing an old binary ... waaaaaaah :-( I _can_ reproduce your problem. And yes, ngIRCd 20 behaves differently: it tries to compare the cut off server password with the original "long" client password, which then isn't equal. This has been changed in commit 7df4c12d, "Dynamically allocate memory for connection password", and is the "Rigel thing" to do ... So basically there is no other option than to provide the correct password that the daemon uses -- that is, the cut off password. The only alternative would be to allocate the server password dynamically, too, and therefore to allow server passwords of arbitrary length ... Alex
On 12/19/2012 02:28 PM, Alexander Barton wrote:
The only alternative would be to allocate the server password dynamically, too, and therefore to allow server passwords of arbitrary length ...
So forgive my ignorance, but does the 20-byte password limitation stem from an RFC or this more observed/standard convention? I cruised the IRC RFC and didn't see the 20-byte maximum stated. Respectfully, Nathan
On Wed, Dec 19, 2012 at 03:36:53PM -0600, lists@packetmail.net wrote:
On 12/19/2012 02:28 PM, Alexander Barton wrote:
The only alternative would be to allocate the server password dynamically, too, and therefore to allow server passwords of arbitrary length ...
So forgive my ignorance, but does the 20-byte password limitation stem from an RFC or this more observed/standard convention? I cruised the IRC RFC and didn't see the 20-byte maximum stated.
Without deeply checking, I think it is an arbitrary length. If you build ngIRCd from source, you could change CLIENT_PASS_LEN in src/ngircd/defines.h and adjust its value (=maximum length + 1) to some other value. There are a few other variables depending on this value (like channel key length and the like), but adjusting it should do no harm there either. Regards Alex
On 12/19/2012 04:01 PM, Alexander Barton wrote:
change CLIENT_PASS_LEN in src/ngircd/defines.h and adjust its value (=maximum length + 1) to some other value.
Perfect, fixed and working. I set it to 30 and rebuilt. Alex, thank you very much and apologies for missing this setting. Cheers, Nathan
participants (2)
-
Alexander Barton -
lists＠packetmail.net