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.
This flag is necessary for hot certificate reload.
We need to know which servers are using the Meta certificate/key,
since we will only be able to live-reload SSL settings via SIGUSR1
for those servers. Servers that use their own SSL certificate/key
can't be reloaded via the SIGUSR1 mechanism.
This is because servers that use their own SSL certificate/key store
them in the database. Thus, it is only possible to update those via
RPC using the updateCertificate() method.
The sslCA option is used by people to specify extra CA certificates.
Before this patch series, the certificates from sslCA would be added
to the QSslSocket::defaultCaCertificates() list via MetaParams. Thus,
those certificates were automatically treated by QSslSocket as valid
root certificates -- by all QSslSocket instances in Murmur.
Since we've now stopped adding the sslCA certificates to the global
QSslSocket::defaultCaCertificates() list, we now have to add them to
each QSslSocket as necessary, for them to be treated as CA certificates.
One use-case for murmur.ini's sslCA option is to add extra CA
certificates in case the system CA store doesn't contain the necessary
certificates.
In Murmur, one place where CA certificates are used is when verifying
client certificats. In Murmur, if a user is using a valid CA-signed
certificate, that user has passed the 'strong' check.
As mentioned, before this patchset, all the certificates from the PEM
bundle pointed to by murmur.ini's sslCA option would be added to
QSslSocket's global default CA certificates list, which is available
via QSslSocket::defaultCaCertificates().
Thus, any CA certificates in sslCAs would be treated as CA certificates
when verifying client certificates of conecting clients.
To keep this behavior, we now add MetaParams's qlCAs to the CA list of
the each connecting client's QSslSocket.
This is useful if you are using private CA for signing
identities for Murmur. If you put your CA certificate into the PEM
bundle pointed to by sslCA, Murmur will treat users with a certificate
issued by that CA as having a valid ('strong') certificate.
Another useful use-case for this is if a user is running Murmur on an
unsupported OS, where certificate verification doesn't work due to Murmur
or Qt not being able to find the system's certificate store. In this
scenario, it is possible to point murmur.ini's sslCA option the sytem's
CA bundle, or a PEM copy of the Mozilla CA bundle. That way, verification
of client certificates from generally trusted certificate authorities is
restored.
The current implementation tries too hard to avoid duplication
of very few lines of code.
Instead, use two separate code paths, one for Windows, one for
Unix-like sytems.
This makes it more readable, and allows us to handle system-specific
quirks much easier. For example, SOCKET is unsigned on Windows, and
comparing it to -1 technically works (at least for two's complement
machines), but causes a compiler warning for a signed vs. unsigned
comparison.
Due to a regression in Qt 5, we can't use disconnectSocket(true)
to abort a handshake.
Use non-forceful disconnect to work around the Qt 5 bug.
See inline comment for more details.
Fixesmumble-voip/mumble#2334
