A relay client could send data with no end-of-line (an unterminated method
or header line) and dribble its payload, making WeeChat accumulate it in the
partial message buffer that grew without limit, until all memory was
exhausted. This path is reachable before authentication during websocket
initialization with the "weechat" and "irc" protocols.
The accumulated partial message is now bounded by
RELAY_HTTP_PARTIAL_MESSAGE_MAX_LENGTH: once the limit is reached, the extra
data is ignored.
A relay client could announce a huge websocket frame (or HTTP body via
"Content-Length") and dribble its payload, making WeeChat accumulate it
in a buffer that grew without limit, until all memory was exhausted. The
websocket frame path is reachable before authentication with the
"weechat" and "irc" protocols.
The announced websocket frame length and HTTP "Content-Length" are now
bounded by WEBSOCKET_FRAME_MAX_LENGTH and RELAY_HTTP_BODY_MAX_LENGTH: an
oversized websocket frame closes the connection, and an oversized body is
rejected.
A malicious or compromised IRC server could send data with no end-of-line
(or a flood of "005" messages), making WeeChat accumulate it in a buffer
that grew without limit, until all memory was exhausted.
The unterminated received message and the accumulated "005" (ISUPPORT)
data are now bounded by IRC_SERVER_RECV_MSG_MAX_LENGTH and
IRC_SERVER_ISUPPORT_MAX_LENGTH: extra data is ignored once the limit is
reached.
The IRC relay protocol's PASS handler compared the server password with
the client-supplied value using strcmp, leaking the password byte-by-byte
via response timing. This is the same class of bug fixed for the api and
weechat protocols, on a separate code path that did not go through
relay_auth_check_password_plain.
Extract the HMAC-then-constant-time-compare logic from
relay_auth_check_password_plain into relay_auth_password_equals, then
use it in both the plain-auth wrapper and the IRC PASS handler.
The relay authentication used non-constant-time comparisons (strcasecmp,
strcmp) to verify password hashes and plaintext passwords, allowing an
attacker to derive the expected hash byte-by-byte from response timing
and then authenticate without knowing the password.
- SHA/PBKDF2 hex hash comparisons: normalize the client-supplied hash to
uppercase and compare in constant time over the fixed expected length.
- Plaintext password comparison: HMAC-SHA256 both passwords with a fresh
per-call random key and compare the fixed-size MACs in constant time,
hiding both per-byte timing and the password length.
Add string_memcmp_constant_time helper in core, exposed via the plugin
API. Bump WEECHAT_PLUGIN_API_VERSION accordingly.
An authenticated relay client using the permessage-deflate websocket
extension could send a small compressed frame that decompresses to an
unbounded amount of data, exhausting all memory and crashing WeeChat.
The output buffer in relay_websocket_inflate is now capped to
WEBSOCKET_INFLATE_MAX_SIZE: frames decompressing beyond this limit are
rejected and the connection is closed.
This reverts commit e64ab3c675.
This was causing incorrect conversion of strings "0x..." to pointers on systems
like Solaris/illumos.
And as a side effect, buffers were sometimes empty in weechat relay clients
like glowing-bear.
Building WeeChat 4.6.0 on OpenBSD failed with the following error.
> /usr/ports/pobj/weechat-4.6.0/weechat-4.6.0/src/plugins/perl/weechat-perl.c:356:13: error: expected ')'
> function) < 0)
> ^
> /usr/ports/pobj/weechat-4.6.0/weechat-4.6.0/src/plugins/perl/weechat-perl.c:352:9: note: to match this '('
> if (weechat_asprintf (
> ^
> /usr/ports/pobj/weechat-4.6.0/weechat-4.6.0/src/plugins/perl/../weechat-plugin.h:1312:31: note: expanded from macro 'weechat_asprintf'
> (weechat_plugin->asprintf)(__result, __fmt, ##__argz)
On further inspection, the line in question was recently altered in
099e11d7b8, where a comma was forgotten in the
else branch of the MULTIPLICITY ifdef.
After adding the comma, WeeChat builds as usual.
At the moment, building WeeChat triggers several thousand -Wstrict-prototypes
diagnostics. This is due to its source code using an empty argument list for
functions and function pointers that take no arguments, instead of explicitly
declaring that they take no arguments by using a void list.
This commit replaces all empty argument lists with a void list.
Note that Ruby's headers also suffer the same problem, which WeeChat can't
do anything to fix. Thus, building WeeChat with the Ruby plugin enabled
will still issue approximately 30 such diagnostics.
New default key:
- Alt+Ctrl+l (L): toggle execution of commands: remote/local
New options:
- relay.api.remote_input_cmd_local: text displayed for command executed locally
- relay.api.remote_input_cmd_remote: text displayed for command executed on the
remote WeeChat
This follows the recommendation from Pythons documentation for
PyModule_GetDict where it says:
It is recommended extensions use other PyModule_* and PyObject_*
functions rather than directly manipulate a module’s __dict__.
This value determines the size of the per-module memory area. Setting
this value to -1 as it was before this change means that the module has
global state and therefore does not support subinterpreters.
However, subinterpreters are used to run the Python scripts, so the
weechat module has to support subinterpreters. Therefore we should set
this value to 0 as no per-module memory is required.
This seems to fix the crash reported in #2046 without the need for the
workaround added in commit 85c7494dc (it does for me when testing with
Python 3.12.0 at least).
This change came up as a suggestion in cpython's issue tracker where it
was pointed out that using modules with m_size set to -1 is not
supported in subinterpreters. See these two comments:
https://github.com/python/cpython/issues/116510#issuecomment-2377915771https://github.com/python/cpython/issues/116510#issuecomment-2389485369
It's not completely clear to me what is required for a module to support
subinterpreters and re-initialization (which is required for setting
m_size to 0), but https://peps.pythondiscord.com/pep-0489/ says:
A simple rule of thumb is: Do not define any static data, except
built-in types with no mutable or user-settable class attributes.
The only static data we define is of type int and str, so I think it
should be fine.
aizu-m