This commit fixes both issues discussed in #4277 which were related to
the fact that any socket connection was allocated an ID and marked as
a user. This bug allowed for a malicious user to lock out all users of
a server regardless of server password usage. This change simply moves ID
allocation to after a connection is marked as Authenticated.
FIXES: #4277
This commit fixes both issues discussed in #4277 which were related to
the fact that any socket connection was allocated an ID and marked as
a user. This bug allowed for a malicious user to lock out all users of
a server regardless of server password usage. This change simply moves ID
allocation to after a connection is marked as Authenticated.
FIXES: #4277
When changing the welcome text via Ice, Murmur would broadcast the new text to all connected clients. It is a matter of opinion if this is proper behavior or not, but it seems too proactive of an action. Let the clients see the new welcometext when they next connect, or let the Murmur administrator explicitly perfor a sendMessage() to all connected clients after changing the welcometext.
Closes: #4788
Co-Authored-By: Robert Adam <dev@robert-adam.de> <krzmbrzl@gmail.com>
Co-Authored-By: Robert Adam <dev@robert-adam.de> <krzmbrzl@users.noreply.github.com>
Before this commit, the code on the server made sure that a
ChannelListener would always receive audio that was being shouted to a
channel. It didn't respect though if the shout was actually restricted
to be received by only a specific group.
This patch now makes sure that listeners are also checked for their
group so that a listener that doesn't belong to the target group (if one
is set) won't receive the audio either.
This allows:
- The client to find servers advertized via zeroconf without the need for Bonjour to be installed.
- The server to advertize itself via zeroconf without the need for Bonjour to be installed.
The Win32 API was introduced in the version 10.0.18362.0 (1903/19H1) of Windows SDK. Before that, only the UWP interface was available (introduced in Windows 10 1507).
This commit was successfully tested on Windows 10 1809, which probably means that the API can be used on previous versions as well.
Even if that isn't the case, it's not a problem: if the code fails to load the required symbols, it falls back to Bonjour.
"Q_OS_WIN64" is used instead of "Q_OS_WIN" because of an issue that appears when certain DNS functions are used in an x86 (32 bit) build: https://developercommunity.visualstudio.com/content/problem/1191345/some-dns-api-functions-cause-lnk2019-errors-in-32.html
This means that until the issue is fixed we can safely use the native mDNS-DNS-SD API only on x86_64 (64 bit).
This should make it more clear that we don't include Bonjour-related stuff in our project. We use external libraries depending on the OS.
For compatibility, the server option is still called "bonjour". We should probably add a new option called "zeroconf" and then handle the old one if present in the configuration file.
Compiling with Boost a somewhat recent version of Boost would produce
warnings about deprecated usage of boost::bind.
These have been fixed now.
The warning was
The practice of declaring the Bind placeholders (_1, _2, ...) in the
global namespace is deprecated. Please use
<boost/bind/bind.hpp> + using namespace boost::placeholders, or
define BOOST_BIND_GLOBAL_PLACEHOLDERS to retain the current behavior.
Fixes#4295
With the old qmake buildsystem we used to set QT_NO_CAST_FROM_ASCII (for
the Mumble client) in order to avoid problems with character encodings
in our Strings. This was not done in the new cmake system yet.
Instead of the aforementioned macro, this commit sets (for all targets)
QT_RESTRICTED_CAST_FROM_ASCII instead in order to be able to
automatically convert direct String literals to QString as these usually
don't contain any problematic characters (non-ASCII) in the first place.
And this allows to e.g. compare a QString against a String literal or do
something like
QString myString = "This is a test";
which we know to be unproblematic.
Note however that (quote from Qt's docs)
"Using this macro together with source strings outside the 7-bit range,
non-literals, or literals with embedded NUL characters is undefined."
Commit bdb12c6 added a regression for servers built with QT older than version
5.15. After this commit these servers do not serve intermediate certificates
anymore. This happens because the QSslConfiguration is retrieved before adding
the CA certificates to the socket and is reinserted into the socket again after
adding the CA certificates, thereby overwriting the CA certificates added in
between.
This commit fixes that by retrieving the QSslConfiguration just after setting
the CA certificates in case an older QT version than 5.15 is used.
Before this commit the packet size for packets sent through the
UDPTunnel was not checked for whether it exceeded the maximum allowed
size. This might open Mumble for attacks of some sort as the code
usually expects the packets to be of at most that size.
This option allows to set a threshold on how long a user's channel
should be remembered. This is useful for scenarios where users usually
don't want their channel to be remembered by the server unless they had
a disconnect (aka have ot re-connect after a short period of time).
Implements #4143
One unexpected behavior of Qt's SSL backend is: it will add the key pair
it uses in a connection into the default keychain, and when access the private
key afterwards, a pop up will show up asking for user's permission.
In some case (OS X 10.15.5), this pop up will be suppressed somehow and no private
key is returned.
This env variable will avoid Qt directly adding the key pair into the default keychain,
using a temporary keychain instead.
See #4298 and https://codereview.qt-project.org/c/qt/qtbase/+/184243Fixes#4298
This option allows to set a threshold on how long a user's channel
should be remembered. This is useful for scenarios where users usually
don't want their channel to be remembered by the server unless they had
a disconnect (aka have ot re-connect after a short period of time).
Implements #4143
Previously the certificates were added to the QSslSocket object directly
but Qt 5.15 added this functionality to the QSslConfiguration object and
deprecated the ones in QSslSocket.
Qt 5.14 has introduced Qt::SplitBehavior which now holds the flag that
were previously contained in the QString class. The fields still exist
in QString but they are deprecated since Qt 5.15.
OCB2 is known to be broken under certain conditions:
https://eprint.iacr.org/2019/311
To execute the universal attacks described in the paper, an attacker needs
access to an encryption oracle that allows it to perform encryption queries with
attacker-chosen nonce. Luckily in Mumble the encryption nonce is a fixed counter
which is far too restrictive for the universal attacks to be feasible against
Mumble.
The basic attacks do not require an attacker-chosen nonce and as such are more
applicable to Mumble. They are however of limited use and do require an en- and
a decryption oracle which Mumble seemingly does not provide at the same time.
To be on the safe side, this commit implements the counter-cryptanalysis
measure described in the paper in section 9 for the sender and receiver side.
This way if either server of client are patched, their communication is almost
certainly (merely lacking formal proof) not susceptible to the attacks described
in the paper.
Before you weren't able to place a listener proxy (ChannelListener) into
the same channel that you're currently in and if you joined a channel
that you were listening to before, your listener proxy would be removed
from that channel.
It was brought to my attention though that there are cases in which a
person wants to hear what's going on in several channels and thus places
listener proxies into them. However if that same person needs to
constantly hop between these listened channels (e.g. to talk to the
folks in there), it gets very annoying as that person constantly has to
think about re-adding the listener proxy into the channel it just left.
If you placed a listener proxy into an empty channel and someone was
shouting to that channel, you'd still not hear any of that. This is
because the old processing logic was injected into the code for the
normal shouting feature. However if there is no user in the channel, the
shouting feature won't do anything.
This commit added the listener targets as a separate entry in the
WhisperTargetCache in order for it to be processed independently of
normal shouts. It also had to tweak the logic for how and when to clean
the WhisperTargetCache in order for this to work nicely with
ChannelListeners as well.
The idea here is that sometimes you really do have a lot of folks connecting from a single IP,
and if those connections are successful you don't want to ban any of them.
However, in cases where the server needs to guard against malicious users attempting a DDOS
by reconnecting their valid user account over and over, we need to be able to configure the
server to still ban those successful attempts.
This implements #3319 by allowing users to "listen" to a channel they
have not joined. Doing so will place a "listener proxy" (in other
software this is sometimes known as a "phantom") in that channel which
will look like a normal user except that it'll have the same name as the
user listening to that channel and an ear-icon instead of the normal
avatar-icon. It will also always show a muted-icon next to it.
If a listener proxy is in a channel, the server will route all audio
packets from that channel to the user the proxy belongs to (as if that
user was in the channel). Note though that the opposite of this is not
true: The users in the channel will not hear audio from the listening
user unless that user decides to join the channel.
Furthermore it is possible to set a local volume adjustment for each
individual proxy that will be applied to all audio that is received
through it.
A severe bug was introduced in qt/qtbase@93a803a6de: q_SSL_shutdown() causes Qt to emit "error()" from unrelated QSslSocket(s), in addition to the correct one.
The issue causes Server::connectionClosed() to disconnect random authenticated clients.
The workaround consists in ignoring a specific OpenSSL error:
"Error while reading: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init [20]"
Definitely not ideal, but it fixes a critical vulnerability. Details on how to trigger it are deliberately omitted.
This allows users to connect to Murmur with CA-signed certificates
without a complete certificate chain.
Such cases will be treated as non-strong, just like self-signed
certificates.
Before this, if a client attempted to connect to Murmur with a
client certificate from an OS-trusted CA, but forgot to include
the correct intermediate certificates, the client would not be
allowed in -- and got no proper warning.
With this change, the user is let in. However, because Murmur
can't verify the certificate against the CA store, it is deemed
non-strong.
Ideally, the certificate wizard should warn about cases where
an incomplete certificate chain is used, but I believe this is
a good first step.
Try to remove the ability to join a full channel by
creating a temporary sub channel then joining it
and removing it (discovered by @Natenom).
Check isChannelFull in addition to existing
hasPermissions ChanACL::Enter check.
This commit adds all the missing includes when the PCH header is not used.
Also, some includes are reordered and/or made consistent (e.g. "#include <QtEndian>" -> "#include <QtCore/QtEndian>").
According to Qt's documentation the PCH header doesn't need to be included.
From https://doc.qt.io/qt-5/qmake-precompiledheaders.html:
"To make your project use precompiled headers, you only need to define the PRECOMPILED_HEADER variable in your project file."
"qmake will handle the rest, to ensure the creation and use of the precompiled header file. You do not need to include the precompiled header file in HEADERS, as qmake will do this if the configuration supports precompiled headers."
This adds messagelimit and messageburst to the configuration file murmur.ini as
well as the ability to set these live.
Though adjusting these live is entirely possible, they only take effect for new connections.
Having to many channels on a server can impact performance to the point
of making the instance unusably slow. This can be a problem for hosters
that allow their users unlimited channel creation.
This patch introduces a new per-server configuration parameter
channelcountlimit which can be used to configure a maximum number of
channels that may be created on each of the virtual servers. Once the
limit is reached channel creation will be rejected with permission
denied.
To allow a translated error message we have to bump the client version
to 1.3.1 to be able to use a fallback message for older clients.
As usual dbus, ice and grpc can ignore this limit. It is only enforced
against clients.
0b5579c755 erroneously replaced the
variable (letter) l with the integer 1.
Revert this change and use a more descriptive variable name `len`.
Fixes#3325
This commit fixes various problems discovered by building on Debian buster
which uses GCC 7. Building on buster gave various -Wimplicit-fallthrough warnings.
In Group.cpp and Server.cpp, we now use if statements instead of a switch with fallthrough.
This improves readability of the code, and fixes the implicit fallthroughs.
In PulseAudio.cpp, we had unintended fallthroughs in a switch statement, which have been
fixed.
In Cert.cpp, we had a potential fallthrough which was impossible to trigger at runtime,
fixed by adding an error return, like the surrounding code.
Fixes#3306.
