Re: ircd-ratbox and Derivatives OOM by MONITOR Command

[William Pitcock <nenolod () dereferenced org>]

Hello,

On Sat, Oct 10, 2015 at 10:55 PM, Christine Dodrill
<me@christine.website> wrote:
> Elemental-IRCd Security Release: 2015-10-07
> ===========================================
>
> CVE-2015-5290
>
> Elemental-IRCd reference code: e50b0d59-f3c5-4472-a3cd-e2e07731417c
>
> Permanent link: http://elemental-ircd.com/security/e50b0d59-f3c5-4472-a3cd-e2e07731417c

LOL.

> Distribution of this document is unlimited and encouraged as long as it
> remains unchanged.
>
> ## Summary
>
> Elemental-IRCd is an Internet Relay Chat (IRC / RFC 1459) daemon intended
> for stable, secure deployments for both private and public-facing users. It
> provides quick messaging across servers, even when deployed on a global
> scale. One of the recent goals of the project has been to limit memory
> leaks and test functionality to ensure quality for all users.
>
> While looking for resource leaks and other things to test inside
> Elemental-IRCd git master, we stumbled on an unfortunate programming error
> in how the MONITOR command was handled that can lead to a system
> out-of-memory event if an attacker hammers at the MONITOR command over and
> over.

Sorry to derail your ego-trip, but it's just a pointer-sized memory
leak.  You have to spam it very aggressively to make it leak in any
sort of drastic way.

> ## Affected Daemons
>
> In our testing, the following IRC daemons were affected:
>
> ircd-ratbox 3.0.8, SVN trunk and older
> charybdis 3.5-dev and older
> ircd-seven 1.1.3 and older
> Elemental-IRCd 6.6.2 and older
> Other derivatives of these daemons will be affected as well unless for some
> reason they came across and fixed that issue before this release.

Thank you for your lack of upstream bug report.  Thankfully, this
isn't really a critical security problem, as you describe below:

> ## Vulnerability Information
>
> Public release date: 2015-10-07
> CVE: CVE-2015-5290
> CVSS v3:
> CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H/E:H/RL:W/RC:C/CR:H/IR:L/AR:H/MAV:N/MAC:L/MPR:N/MUI:N/MC:L/MI:N/MA:H
> CVSS score: 8.8 / 8.6 / 9.5
> Attack complexity: Trivial (less than 30 lines of code)

I'm totally quaking in my boots at this info-sec disaster, it must be
a security consultant's dream.

Again, people, it's just a relatively minor memory leak, in a codebase
with actual CVE-worthy bugs, mainly introduced by the developers who
"discovered" this one.

> ## Notes
>
> If applying these patches is somehow impossible, the attack can be
> completely mitigated by unloading the m_monitor.so module using the
> following command provided you have permission to load and unload modules:
>
>     /MODUNLOAD m_monitor.so
>
> The required privilege to do this is defined as the admin flag inside the
> flags section of the relevant operator{} block in the configuration
> (OLD:O:Line).
>
> This patch can be applied at runtime and will automatically garbage-collect
> any memory that has been leaked in the past.

Except it doesn't really work, because the affected objects are placed
on a magazine allocator, so you are just left with a fragmented
allocator.  At best, it will just ensure there is no further memory
leak.  But of course you could just not care and wait patiently for
the next release, because there are far more effective ways to take
down the product in question.

> A full set of technical details will be released as soon as it is confirmed
> that major IRC networks affected by this have been patched.

I'll save you the time, it's basically:

while(1) {
   send MONITOR + offline_nick
   send MONITOR - offline_nick
}

William