Aaron Jones [Thu, 5 Jul 2018 14:06:06 +0000 (14:06 +0000)]
modules/crypto/pbkdf2v2: fix regression from v7.2.9
Interoperability tests were performed between 7.2.9 and master,
and 7.2.10 and master, but not 7.2.9 and 7.2.10. 7.2.10 and
master use base64-encoded salts for new hashes, and master has
a verify function which doesn't require string-equal output.
However, 7.2 doesn't have that feature, so crypt() must output
a string-equal hash to all of the previous outputs over all
versions. What I failed to notice was that crypt() was assuming
the salt was base64-encoded, so if it wasn't, password
verification would fail; the hash is the same byte-wise, but it
is encoded as a string differently.
While we're at it, make sure the parameter upgrade system takes
account of various salt lengths, allow the user to configure a
different salt length (as if on master), and make sure we erase
the password from the stack after we're done with it.
Aaron Jones [Wed, 28 Feb 2018 11:50:04 +0000 (11:50 +0000)]
modules/crypto/argon2d.c: argon2d_hash_raw(): fix uninitialised data path
If the first blake2b_long() call in argon2d_hash_raw() fails, it would pass
uninitialised data in bhash_bytes[] to argon2d_load_block(). Similarly if
the second call fails, same thing. Lastly, the return value should depend on
whether the final call succeeds.
Fix this by testing if it fails, and add a function attribute to all boolean
functions that will result in a diagnostic if their return value is not
tested (or under Clang, explicitly discarded). Adjust other callers of those
functions to also test for failure.
This issue was found by the Clang static analyzer.
groupserv/main: write out group definitions before their access lists
If a group '!a' includes an access list entry for group '!b' (which is
lexicographically after) then upon read-back (when restarting services)
the access list contains an entry for a (for the moment) non-existent
group which is ignored. This results in data loss.
The fix is simple: Write out all group definitions (& their flags and
metadata) and then all group access lists.
Reported-by: Samuel Hoffman <redacted> (sjh) Reported-by: Aaron M. D. Jones <redacted> (amdj) Reviewed-by: Janik Kleinhoff <redacted> (ilbelkyr)
modules/crypto/pbkdf2v2: don't ask OpenSSL for digest length
We know it's only ever going to be SHA1 (20 bytes), SHA2-256 (32 bytes)
or SHA2-512 (64 bytes), and we're already in a switch() statement
converting a PRF ID into a digest algorithm, so we may as well set the
digest length in there too.
Aaron Jones [Sun, 22 Oct 2017 02:24:39 +0000 (02:24 +0000)]
modules/crypto/pbkdf2v2: reduce size of sscanf(3) buffers
0x2000 (8 KiB) is definitely sufficient to mitigate any potential
inadvertant overflow, and an attacker with a crafted malicious
database would have been able to overflow the old 0x8000 (32 KiB)
buffers anyway.
Aaron Jones [Sun, 22 Oct 2017 02:24:18 +0000 (02:24 +0000)]
modules/crypto/argon2d: reduce size of sscanf(3) buffers
0x2000 (8 KiB) is definitely sufficient to mitigate any potential
inadvertant overflow, and an attacker with a crafted malicious
database would have been able to overflow the old 0x8000 (32 KiB)
buffers anyway.
Aaron Jones [Sun, 15 Oct 2017 14:31:46 +0000 (14:31 +0000)]
modules/crypto/pbkdf2v2: add support for HMAC-SHA1
The master branch (what will become 7.3) got this too, but it was
added there for future possibility of implementing SASL SCRAM support.
We will not be implementing support for SCRAM in version 7.2, but
people who used the pbkdf2v2 module with SHA1 in version 7.3 might
want to downgrade to version 7.2, so we need support for verifying
those hashes too.
Aaron Jones [Sun, 15 Oct 2017 11:01:45 +0000 (11:01 +0000)]
modules/crypto/argon2d: don't mix format strings for scanning & printing
The inttypes.h header provides format specifier macros for scanning, so
use those for parsing instead of the printing ones, just incase we're
building on a machine where they are different.
Aaron Jones [Thu, 5 Oct 2017 22:56:41 +0000 (22:56 +0000)]
modules/crypto/posix: fix potential NULL deref on password verify
If we have an encrypted password from the database that does not
contain a '$' in it (as is the case for the original deprecated
pbkdf2 module) then when posix tries to verify the hash it will
segfault because we assume a '$' is present.
Aaron Jones [Wed, 4 Oct 2017 23:44:03 +0000 (23:44 +0000)]
verify_password(): more error checking, better logic, fix minor bug
* ci->crypt() and ci->salt() can return NULL in rare circumstances
* don't duplicate logic for generating a new password hash
* when the user's password is encrypted but a crypto module is not
loaded, don't complain if the /encrypted password/ is '*', not
if the /user-supplied password/ is '*'.
* remove extra line at end of file
Jos Ahrens [Sun, 9 Oct 2016 20:04:21 +0000 (20:04 +0000)]
email templates: Fix leading whitespace
The leading whitespace is barely visible in many email clients
and was often cause for sending the message directly to the channel
for clients that do not interpret " /command" as a command. This
was most notable for qwebirc.
Janik Kleinhoff [Tue, 9 Dec 2014 13:48:49 +0000 (13:48 +0000)]
chanserv/help: include INFO in short help instead of RECOVER
The RECOVER command should rarely be needed unless handing out channel
access like popcorn is the norm in some channel, in which case we can't
really help them anyway; as such there's little point in listing it by
default. INFO on the other hand is widely used as *the* way to ask
services for basic information on a channel, so it makes sense to be in
the short help (which nickserv/help does as well).
(In fact, on freenode, the most common use of RECOVER seems to be by
people who use it as the primary way to get opped, given that network's
recommendation to avoid auto-op and their default flag set reflecting
this. I suppose some people misinterpret this as having lost control of
their channel. Presumably it's debatable who's to blame here, but maybe
removing RECOVER from the default short help listing will help avoid
that sort of problem. Either way, it shouldn't hurt.)
Max Teufel [Sat, 10 Sep 2016 14:25:28 +0000 (16:25 +0200)]
help/default/nickserv/cert: clarification about fingerprints
Add a note about the fact that the CertFP implementation is agnostic
with regards to the fingerprint algorithm used by the IRCd. Otherwise,
users could be confused due to the examples.