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:
Code: Select all
./unrealircd hot-patch websocket61xcrashThis 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:
Code: Select all
listen {
ip *;
port 8888;
options { websocket { type text; }; tls; }
}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:
Code: Select all
./unrealircd hot-patch websocket61xcrash"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.
On versions 6.1.0 through 6.1.2.3 the hot-patch will fix the websocket crash issue. This is git commit b0e87dca.
On version 6.1.3 the hot-patch will fix the websocket crash issue (commit b0e87dca) and also fix another issue that does not cause a crash but prevents websockets from working properly in Chrome and other browsers (fa84174d). 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:
- A websocket port must be open
- UnrealIRCd version must be 6.1.0 through 6.1.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.
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