UnrealIRCd 6.1.4 release and hot-patch for crash issue

[Bram M. <sy...@un...>]

Hi everyone,

UnrealIRCd 6.1.0 through 6.1.3 contain a bug which makes it possible for 
a websocket user to crash the IRC server. For the issue to trigger you 
need to have a listen block with websockets enabled.

UnrealIRCd 6.1.4 has been released to fix this issue. However, *NIX 
users can also fix the issue without restart by using a "hot-patch". The 
hot-patch takes less than a minute to install and causes no downtime.

If you just want to apply the hot-patch on *NIX without reading all of 
below, the command to run in your unrealircd directory is:

./unrealircd hot-patch websocket61xcrash

The output should end with "Rehashed succesfully. Patch installed and 
server rehashed correctly. All should be good now!"

This issue was assigned CVE-2023-50784. For the full story with all 
details, see below.

Affected versions & configurations
UnrealIRCd 6.1.0 through 6.1.3 have a buffer overflow issue in the 
websocket handling code. For the issue to trigger you need to have 
websockets enabled, which is popular but not present in the 
default/example configuration.

Websockets are a nice feature to allow web chat directly from a browser 
to the IRC server without any intermediate gateways. If you are unsure 
if you have a listen block with websockets enabled, then search for 
"websocket" (without quotes) in your configuration file(s), such as 
unrealircd.conf. A websocket listen block looks like this in the config 
file:

listen {
     ip *;
     port 8888;
     options { websocket { type text; }; tls; }
}

If you have such a listen block for websockets and are using UnrealIRCd 
6.1.0 through 6.1.3 then you are affected by this bug. If you are using 
an older UnrealIRCd version or you have no listen block for websockets 
then you are not affected.

Besides normal websocket connections, the websocket handling code is 
also reachable by trusted JSON-RPC hosts (such as the UnrealIRCd admin 
panel), but in that case only after authentication by an rpc-user { } 
block. That particular scenario is likely of little interest since 
authenticated rpc-users already have complete power over the ircd, they 
can already gline and kill everyone. It is only mentioned here for 
completeness.

Triggering the bug

Any user who can connect to the websocket port can trigger this bug. The 
bug can be triggered pre-authentication, so before the user is online on 
IRC. This means allow block { } restrictions and similar restrictions 
(including glines) will not protect you.

Now that the patch is out we expect bad actors to read the patch, 
understand how to trigger the crash (which is relatively easy) and 
potentially crash IRC servers in the wild.

Effects of this issue

On all reasonably modern tested Linux distro's this issue is caught by 
"fortified functions", a security feature with which we compile by 
default since 2016, if the compiler supports this. Examples of tested 
safe distro's are Ubuntu 16.04/18.04/20.04/22.04 and Debian 9/10/11. 
When the bug is caught by fortified functions, the buffer overflow is 
prevented but it triggers a crash instead. When testing on FreeBSD and 
Windows, the overflow is not caught but the overflow seems to happen to 
other (harmless) buffers and there is no effect (no crash, nothing).

For 99%+ of the affected servers that have websockets enabled, the 
effect is a crash or no effect. When using very old compilers, or a 
compiler other than gcc/clang, and/or possibly non-Linux, and/or unusual 
architectures, when fortified functions do not catch the issue and in 
the unfortunate event that buffers may have a different layout than 
during our tests we cannot 100% rule out more grave issues. Technically, 
the buffer overflow happens with a "static char" variable which is in 
the isolated data segment of the websocket_common module (.so file), 
making further exploitation beyond a crash unlikely. Again, in none of 
our tests anything beyond a crash was possible.

Recommendations

If you have websockets enabled and are using an affected version, then 
we recommend applying the hot-patch or upgrading to 6.1.4.

The hot-patch will fix the issue without any downtime. To apply the 
hot-patch run the following command:

./unrealircd hot-patch websocket61xcrash

The script should end with the output: "Rehashed succesfully. Patch 
installed and server rehashed correctly. All should be good now!"

It is also safe to run the hot-patch command on unaffected UnrealIRCd 
versions, for example 6.0.7, in which case it will print "This 
UnrealIRCd version does not require that patch".

If you prefer upgrading to 6.1.4 you can download latest UnrealIRCd 
version from www.unrealircd.org <http://www.unrealircd.org>.

On versions 6.1.0 through 6.1.2.3 the hot-patch will fix the websocket 
crash issue. This is git commit b0e87dca 
<https://github.com/unrealircd/unrealircd/commit/b0e87dcafa75f8bced7a0b11dd335e9b7aa86334>.

On version 6.1.3 the hot-patch will fix the websocket crash issue 
(commit b0e87dca 
<https://github.com/unrealircd/unrealircd/commit/b0e87dcafa75f8bced7a0b11dd335e9b7aa86334>) 
and also fix another issue that does not cause a crash but prevents 
websockets from working properly in Chrome and other browsers (fa84174d 
<https://github.com/unrealircd/unrealircd/commit/fa84174d22251fec428b17c0cd1ba2f6a7cbaf86>). 
These two changes are the same two changes between 6.1.3 and 6.1.4.

Checking for the issue remotely
You would have to check for 3 things and all 3 must be true:

 1. A websocket port must be open
 2. UnrealIRCd version must be 6.1.0 through 6.1.3
 3. If you run "MODULE -all" on IRC (lots of output!) then look for the
    version number in the line for websocket_common. If it shows 6.1.4
    then you are patched, any lower version means unpatched.

It is important to point out that if any of the above is not true, then 
you are not vulnerable. For example when you run an old UnrealIRCd 6.0.x 
and MODULE -all outputs 6.0.0 for websocket_common then you are not 
affected.

If you have command line access, then just run the hot-patch commands 
under RECOMMENDATIONS.

Workaround
While not the preferred method of dealing with this, just mentioning for 
completeness:
If you don't want to patch and don't want to upgrade, a possible 
workaround is disabling any listen blocks for websockets.

Cause of the bug
For programmers and users who are curious how this happened. Websockets 
are a binary protocol so have completely different parsing than IRC. 
These packets can also be much longer than regular IRC protocol lines. 
This requires extreme caution when parsing messages. In the websocket 
parsing code, there are two functions: one does a length check to see if 
the packet is larger than the 1st buffer and then the secondary function 
did a memcpy without further length checks in a 2nd buffer. In 
UnrealIRCd 6.0.7 and earlier the length of the 1st buffer is less or 
equal to the 2nd buffer, which was intended, so any oversized packet is 
already rejected by the 1st function and this means the memcpy in the 
2nd function is safe and there is no issue. However, a change in 6.1.0 - 
completely unrelated to websockets - made the 1st buffer much larger 
without changing the size of the 2nd buffer. The same buffer sizes (same 
defines) should have been used at both places, but we didn't. An 
additional factor of confusion is that we have defines for 
"READBUF_SIZE" and "READBUFSIZE" with different sizes. If the one 
without the underscore would be used, there would have been no issue. In 
the final patch we opted for using a different define, to match the 
exact name in both functions which is how it should have been done, but 
that is besides this point.

The issue was not caught by our internal fuzzer because the fuzzer only 
dealt with a single websocket packet at a time. It did not try a 
multiple packets scenario (frame reassembly). After another bug was 
fixed (which had no security impact), the fuzzer was adjusted to also 
try multiple packets. When running the updated fuzzer, to verify the 
former issue was properly fixed, this new issue was triggered immediately.

CVSS score
Based on the crash scenario, the CVSS v3.1 base score is 7.5, temporal 
score 7.2, total score 7.2. 
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H/E:H/RL:O/RC:C

Timeline
2023-12-13: Issue discovered internally after fixing a related issue in 
a different module, CVE requested
2023-12-14: CVE-2023-50784 assigned, sent out pre-announcement / heads up
2023-12-16: Release of hot-patch and UnrealIRCd 6.1.4

Reference

This post (and any potential updates) is available at 
https://forums.unrealircd.org/viewtopic.php?t=9340