full-disclosure - PTnet IRCD heap exhaustion and integer overflow

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date: Fri Dec 30 17:48:31 2005
From: ficheironegro at gmail.com (yeah right)
Subject: PTnet IRCD heap exhaustion and integer overflow

Synopsis : Potential heap exhaustion and an integer overflow
Product  : PTnet IRCD
Version  : 1.6, 1.5 (partially)
Date  : February, 3rd 2005
Author  : blackfile

 o introduction --

  The PTnet IRCD is a DALnet dreamforge fork. This IRCD has been hardly
 modified to fit the network user's needs. Since version 1.5 only some
channels
 were locked due to security measures. But from version 1.6 onwards this
problem
 seem to be somewhat problematic. Some channels like #PTnet, #PTnoticias and
all
 #*.log channels were locked.
 Note: One should keep in mind that you need special privileges to join
these channels.

 o details --

  Since PTnet has a closed source philosophy and I don't have access to
 neither the IRCD's binary nor the sources, I had to make some hard guesses
and
 some reverse engineering.  So it will seem normal if some of my guesses
and/or
 ideas about this problem could be wrong. When one attempts to join one of
these
 charmed channels and if not properly identified as an IRCOP a warning is
displayed
 (Permission denied- You do not have the proper IRC operator privileges).
Although,
 the channel is opened with no one inside, so a few Kilobytes of memory are
allocated
 and right after this an integer that says how many channels have been
opened is
 incremented by one.  You can confirm if the channel is opened by typing
 (/quote MODE #channel).

 Technical overview:

 See channel.c/m_join() :

  At the beginning of the for() loop statement there are a few conditions
that
 check the channel's length and other misc operations.  Just after those
tests another
 is made to check if the channel we are joining is a charmed channel or
not.  But,
 instead of returing in case of an error, the loop is broken and the rest of
the
 code is executed and the channel is successfully opened with no one inside
of it.

 o exploitation --

  Just create a bunch of bots and start opening random #*.log channels.

 o proof-of-concept --

  Soon.

 o impact --

  If properly exploited, the process runs out of heap space and therefore
 making the IRCD call the outofmemory() function... which will lead to a
hell-freezing
 restart.

 o disclaimer --

  This document may not be (re)distributed.  This file is released "AS IS"
without
 any kind of warranties.  The author may not be held responsable by one's
misusage of this  information and/or program(s).
 This information and/or source code is provided for
 educational purposes only.

 o vendor notification --

  None, due to their negligence towards the users, none will be made.

 o final notes --

  Open your radio.  There are moths everywhere, I'm sure of it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20051230/2d642180/attachment.html