oss-sec mailing list archives
Re: ircd-ratbox and Derivatives OOM by MONITOR Command
From: William Pitcock <nenolod () dereferenced org>
Date: Sun, 11 Oct 2015 19:25:49 -0500
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
Current thread:
- ircd-ratbox and Derivatives OOM by MONITOR Command Christine Dodrill (Oct 10)
- Re: ircd-ratbox and Derivatives OOM by MONITOR Command William Pitcock (Oct 11)