This module adds topic changes, nick changes, parts, joins, quits, kicks and
mode changes to the buffer playback.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1592 726aef4b-f618-498e-8847-2d620e286838
CSocket sometimes calls our select() wrapper with writeds == NULL and we didn't
handle this case at all which lead to a NULL pointer dereference.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1586 726aef4b-f618-498e-8847-2d620e286838
The source of commands is supposed to be a complete nick mask, but we only used
the nick.
Thanks to flakes for (kinda) noticing this.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1584 726aef4b-f618-498e-8847-2d620e286838
Without this we could cause a client desync (ZNC still got the correct
information).
Bug reported by tomaw and patch provided by flakes, thanks.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1583 726aef4b-f618-498e-8847-2d620e286838
autoconf automatically substitutes @PACKAGE_VERSION@, so there is not much point
into adding another substitute for this.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1582 726aef4b-f618-498e-8847-2d620e286838
- The last commit broke windows (= everything which uses libznc)
(sorry, copy&paste error)
- distclean left the .pc files behind
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1581 726aef4b-f618-498e-8847-2d620e286838
/version generates a 005 server reply. We used to cache this reply in the raw
buffer and the next user who logs in then received the same 005 reply multiple
times.
We fix this by adding CBuffer::UpdateExactLine() which does nothing if the exact
same line is already in the buffer. The only place where we (currently?) use
this is the raw 005 reply.
This should fix sf bug #2817124.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1579 726aef4b-f618-498e-8847-2d620e286838
The directory prefix checking which prevents path traversal exploits had a logic
error that made it always fail.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1574 726aef4b-f618-498e-8847-2d620e286838
You can upload files to znc via /dcc send *status. The files will be saved in
<datadir>/users/<user>/downloads/. The code for this didn't do any checking on
the file name at all and thus allowed directory traversal attacks by all znc
users (no admin privileges required!).
By exploiting this bug, attackers could e.g. upload a new ssh authorized_keys
file or upload a znc module which lets everyone gain shell access. Anything is
possible.
Again:
ONLY A NORMAL USER ACCOUNT NEEDED, no admin privileges.
THE ATTACKER GOT WRITE ACCESS TO ALL PLACES ZNC GOT WRITE ACCESS TO.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1570 726aef4b-f618-498e-8847-2d620e286838
A common pattern for checking directories in ZNC is the following:
sAbsolutePath = CDir::ChangeDir(sAllowedPath, sFile);
if (sAbsolutePath.Left(sAllowedPath.length()) != sAllowedPath)
Error;
But there is a problem: If sAllowedPath doesn't end with a slash, we are
vulnerable to an attack. If e.g. sAllowedPath = "/foo/bar", then
sFile = "../bartender" would result in sAbsolutePath = "/foo/bartender". Since
this path does begin with sAllowedPath, the code allowed it.
There shouldn't be any places where this can be exploited currently, but it is
still a security bug (path traversal).
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1569 726aef4b-f618-498e-8847-2d620e286838
The issue happened if off_t was a signed, 4 byte integer (x86). In this case
(off_t) 0xffffffff is -1 and a file size is always larger than -1 which
unconditionally caused the "File too large" error to trigger.
Thanks to [Deton8r] for reporting this bug and flakes for debugging it.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1568 726aef4b-f618-498e-8847-2d620e286838
This now states more explicitly that c-ares is not strictly required.
Thanks to flakes for noticing that the error messages needs improvement and to
w00t for improving the improved error message flakes and me came up with.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1565 726aef4b-f618-498e-8847-2d620e286838
Everything which isn't a CClient with a successful login counts as an
unidentified connection in this context. Modules who don't want this kind of
limit on their listening sockets can override CSocket::ConnectionFrom(), but
their sockets will still count towards this limit.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1561 726aef4b-f618-498e-8847-2d620e286838
We need to have an upper limit of the size of HTTP POST data. With the current
code you could just send 4 GiB of data to webadmin and ZNC would try to keep all
of this in memory.
This patch implements an upper limit for HTTP POST data of 1 MiB.
Thanks to cnu for finding this.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1559 726aef4b-f618-498e-8847-2d620e286838
If a user is deleted while it is trying to connect to an IRC server, the IRC
socket wasn't deleted together with the user. At some later point in time, the
IRC socket will try to use the user object, which was already freed by now.
Fix this by erasing IRC sockets together with their user object.
Thanks to cnu for reporting this.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1557 726aef4b-f618-498e-8847-2d620e286838
After the first attempt to lookup an address, Csocket already created the socket
used for communicating. Since at this point it wasn't yet known whether we will
yield a IPv4 or IPv6 address, Csocket just always used IPv4. This would then
later fail to connect() with 'Address family not supported by protocol'.
This patch fixes this by creating the socket fd only when the DNS lookup
completed successfully.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1556 726aef4b-f618-498e-8847-2d620e286838
Every socket which is based on CZNCSock will now use c-ares for its name
resolving. This is possible thanks to CSocket's Csock::GetAddrInfo() which
lets one override the DNS lookup.
This can be disabled with --disable-c-ares.
If IPv6 is enabled and Csocket didn't specify which kind of lookup (ipv4/ipv6)
it wants, we first do an ipv4 lookup. If that lookup doesn't yield any useful
result, we try again with an ipv6 lookup. If one wants to force ipv6 usage on a
domain which also resolves to an ipv4 address, he has to set an ipv6 vhost.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1551 726aef4b-f618-498e-8847-2d620e286838
Classes derived from Csock* can be casted implicitly to their base class, this
explicit casts are rather pointless.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1548 726aef4b-f618-498e-8847-2d620e286838
The following sequence triggered this bug:
/mode <chan> +ov-o <you> <you> <you>
The deop called CNick::RemPerm('@') which removed the '@' from the list of
perms via std::string::erase(<positiong of '@' in that string>). The bug was
that erase() by default erases till the end of the string, but we only wanted
to remove a single character. The fix is easy, just pass in '1' as a second
parameter. :)
Thanks to sp219 for finding and reporting this bug.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1547 726aef4b-f618-498e-8847-2d620e286838
psychon