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]
Message-ID: <9870a8150512300646u3b90e5b0m@mail.gmail.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ