Date: Thu, 28 Aug 2014 18:42:23 +0200 From: Pierre Schweitzer <pierre@...ctos.org> To: oss-security@...ts.openwall.com Subject: Full disclosure: denial of service in srvx Hi all, ZeRoFiGhter and I (Pierre Schweitzer), at OnlineGamesNet.net discovered the following issue on OnlineGamesNet.net on the 14th of July. This is full disclosure of a denial of service security issue in srvx software (http://www.srvx.net/). Vendor was contacted a month ago (on the 16th of July) and acknowledge good reception of the issue and the patches. The issues is today still unfixed in development trunk. 1 - Description: ========= When configuring the HelpServ bots in srvx, there is not bound check for intervals in which various functions are executed (for instance the EmptyInterval parameter). These parameters can be accessed and set by either IRCops (with access to OpServ bot) or by HelpServ bot managers (who do not require to be IRCops). Putting an extremely high value to these parameters, such as 184467440723049 will lead to an integer overflow. When attempting to queue the function execution, srvx will add it in the past, will attempt to execute it immediately and thus will loop forever on this, and will finally crash due to memory exhaustion. Furthermore, any restart of the service will not be possible, as the value is stored in the configuration file. It will be required to manually edit the configuration file to correct the wrongly set values for the bot. 2 - How to reproduce: ============= Simply create a bot with HelpServ module. Set the high value: ?helpserv set HelpServ EmptyInterval 184467440723049 To fasten the coming crash: ?writeall and then ?restart srvx will not show up again, it will crash on boot. 3 - Risks: ===== Low. HelpServ module needs to be activated on your server. Furthermore, only supposedly trusted people can change these settings (bot managers & IRCops). 4 - Available fixes: =========== See the two patches attached (generated against the development trunk). These two patches are not dependent and can be applied separately and both fix the issue. 0001-Ensure-that-timeq-added-function-isn-t-added-in-the-.patch: most generic fix. It is here to deny any function adding in the past. In such case, it will be dropped. This patches fixes any issue linked to integer overflow for timeq functions execution. Applied alone it fixes the said issue. 0002-Bound-check-for-intervals-in-mod-helpserv.-This-prev.patch: the bound check fix. It adds controls to the input of the users for the function interval execution. And thus, prevents any overflow. It's set to 2y, a widely used value in srvx for intervals (see timed bans). Applied alone it fixes the said issue. 5 - Mitigation: ======== Inform concerned people (ie, with enough accesses) about the risks. 2y is enough for maximum bound. Reduce accesses to not trusted enough people. 6 - Affected versions: ============= 1.3.1 Development trunk With my best regards, -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. View attachment "0001-Ensure-that-timeq-added-function-isn-t-added-in-the-.patch" of type "text/x-patch" (647 bytes) View attachment "0002-Bound-check-for-intervals-in-mod-helpserv.-This-prev.patch" of type "text/x-patch" (3557 bytes) Download attachment "smime.p7s" of type "application/pkcs7-signature" (3968 bytes)
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.