[<prev] [next>] [thread-next>] [day] [month] [year] [list]
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.
