ngIRCd Users

ngircd@lists.barton.de

424 Diskussionen

ngIRCd 0.9.0-pre1
by Alexander Barton 09 Jul '05

09 Jul '05

Hi all! A new pre-release version of ngIRCd, version 0.9.0-pre1, is available for testing and can be downloaded from: <ftp://Arthur.Ath.CX/pub/Users/alex/ngircd/ngircd-0.9.0-pre1.tar.gz> The GnuPG signature and a patch from 0.7.7 is available and can be downloaded from here: <ftp://Arthur.Ath.CX/pub/Users/alex/ngircd/> Please test & report any bug you find to this list. Thanks! :-)) The 0.9.x branch has been tagged as "branch-0-9-x" in CVS, this pre- release is tagged as "rel-0-9-0-pre1". Changes since ngIRCd 0.8.3 are: - Fixed maximum length of user names, now allow up to 9 characters. - Cut off oversized IRC messages that should be sent to the network instead of shuttding down the (wrong) connection. - Don't generate error messages for unknown commands received before the client is registered with the server (like the original ircd). - Never run with root privileges but always switch the user ID. - Make "netsplit" messages RFC compliant. - Fix handling of QUIT Messages: send only one message, even if the client is member of multiple channels. - Don't exit server if closing of a socket fails; instead ignore it and pray that this will be "the right thing" ... - Implemented the IRC function "WHOWAS". - Don't enable assert() calls when not ./configure'd with --enable- debug. - Fixed ./configure test for TCP Wrappers: now it runs on Mac OS X as well. - Enhanced configure script: now you can pass an (optional) search path to all --with-XXX parameters, e. g. "--with-ident=/opt/ident". - Removed typedefs for the native C datatypes. Use stdbool.h / inttypes.h if available. - New configuration option "OperServerMode" to enable a workaround needed when running an network with ircd2 servers and "OperCanUseMode" enabled to prevent the ircd2 daemon to drop mode changes of IRC operators. Patch by Florian Westphal, <westphal(a)foo.fh-furtwangen.de>. - Implemented support for "secret channels" (channel mode "s"). - New configuration option "Mask" for [Operator] sections to limit OPER commands to users with a specific IRC mask. Patch from Florian Westphal. - Write "error file" (/tmp/ngircd-XXX.err) only if compiled with debug code ("--enable-debug") and running as daemon process. - Don't create version information string each time a client connects but instead on server startup. By Florian Westphal. - New configuration variable "PidFile", section "[Global]": if defined, the server writes its process ID (PID) to this file. Default: off. Idea of Florian Westphal, <westphal(a)foo.fh-furtwangen.de>. - Code cleanups from Florian Westphal, <westphal(a)foo.fh- furtwangen.de>. - Raised the maximum length of passwords to 20 characters. - Fixed a memory leak when resizing the connection pool and realloc() failed. Now we don't fall back to malloc(), which should be sane anyway. Patch from Florian Westphal, <westphal(a)foo.fh-furtwangen.de>. - Added support for the Howl (http://www.porchdogsoft.com/products/ howl/) Rendezvous API, in addition to the API of Apple (Mac OS X). The available API will be autodetected when you call "./configure --with- rendezvous". - Made ngIRCd compile on HP/UX 10.20 with native HP pre-ANSI C compiler and most probably other older C compilers on other systems. - When the daemon should switch to another user ID (ServerID is defined in the configuration file) and is not running in a chroot environment, it changes its working directory to the home directory of this user. This should enable the system to write proper core files when not running with root privileges ... Regards Alex -- Alexander Barton, Freiburg, Germany http://www.barton.de/, alex(a)barton.de

1 0

How to track development?
by Alexander Barton 10 Apr '05

10 Apr '05

Hi all! Here are some hints for those interested in tracking the ongoing development of ngIRCd: - You can visit <http://cia.navi.cx/stats/project/ngIRCd> to review all the latest changes committed to the CVS ("Concurrent Versions Systems", the software used to manage the source files of ngIRCd). - You can subscribe to the RSS feed located at <http://cia.navi.cx/stats/project/ngIRCd/.rss> to be notified of all CVS commits (as displayed at the page above). - And you can subscript to the "ngIRCd-CVS" mailing list to receive an email each time changes become committed to the CVS. The homepage of this list is located at <http://arthur.ath.cx/cgi-bin/mailman/listinfo/ngircd-cvs-ml>. You'll "only" get the changelog of the affected files this way, not the complete patch. - Use the "ViewCVS" interface located at <http://arthur.ath.cx/cgi-bin/viewcvs.cgi/ngircd/> to review the current CVS repository, including the possibility to review all old versions of all files, to generate specific patches and to download a current archive ("tarball"). All "regular" releases will be announced via this mailing list, on the homepage <http://arthur.ath.cx/~alex/ngircd/>, and on freshmeat.net where you can subscribe to be notified on new releases via email: <http://freshmeat.net/projects/ngircd/>. Regards Alex -- Alexander Barton, Freiburg, Germany alex(a)barton.de, http://www.barton.de/

1 0

Re: [ngIRCd-ML] IRC Services
by Stefan Johnson 21 Mär '05

21 Mär '05

--- Alexander Barton <alex(a)barton.de> wrote: > Hi Stefan! > > > I got to looking around and > > discovered this little gem of a server. I > downloaded > > it, compiled it (no problems what-so-ever) and > > installed it without a single hitch. I even went > in > > and found the correct line in the defines.h file > to > > modify the nick length quickly because the code is > > clean and self documenting. KUDOS. > > Thanks :-) No problem. I don't speak or read German, but your code is self-documenting and I can understand what's going on without bothering with the comments :) > > > It's my understanding that services work by > connecting > > to the IRC servers they service as "just another > IRC > > server." The servers don't know anything about > the > > services server other than it's another IRC server > on > > the network. > > This is one possibility. And this one should/could > already work with > the ngIRCd. I agree. I haven't found a service package to try this with as of yet. Hybserv2 acts as another server on the network as I described. Hybrid7 doesn't have support for the service related commands by default, and may not have them at all. > > The alternative is that the service registers itself > as "service" using > the SERVICE command as defined by RFC 2812, section > 3.1.6. This variant > isn't implemented by the ngIRCd at the moment. I've never actually seen a service implemented this way, although I do remember seeing this section in the RFC's while I was learning the protocol to write my own IRC bot. I just looked in to this and it looks like it wouldn't take too much to add this kind of functionality to ngIRCd. I looked at the client.c file, and I know another wrapper needs to be added to Client_New() called Client_NewRemoteService(). I'll dig deeper and see if I can't implement this. I'd rather find an IRC server that has this working already to test how the protocol is suppose to work, but *something* is better than *nothing* :) and I'm sure people will correct anything I do wrong if I get this working and submit the appropriate patches. By the way, I compiled this on a Tru64 5.1b box as well without problems. Can't remember if it's in the list of reported "working" or not, but if it's not, now it can be added. Thanks again, Stefan Johnson __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

1 0

IRC Services
by Stefan Johnson 19 Mär '05

19 Mär '05

Hi, I'm new to the list. I run hybrid7 with hybserv2 services on my linux server at home. I recently acquired an HP C3000 workstation (PA-RISC) with HP-UX 11i installed. I installed the GNU C compiler suite, and tried to install hybrid7 to no avail. It seems the only time hybrid7 has been successfully compiled on HP-UX is via HP's ansi-c compiler ($1500.00 or so price tag for that.) I got to looking around and discovered this little gem of a server. I downloaded it, compiled it (no problems what-so-ever) and installed it without a single hitch. I even went in and found the correct line in the defines.h file to modify the nick length quickly because the code is clean and self documenting. KUDOS. I was browsing the mailing list archive and discovered that I'm not the only one interested in IRC services. The last discussion I remember reading on it is from January of this year. It seems noone was quite sure how the services actually work. I'd like to introduce 2 concepts of how services are suppose to work (from my experience... guesswork, but the end result would be the same) plus I'd like to give an idea for "faking" services using something as simple as an eggdrop irc bot. It's my understanding that services work by connecting to the IRC servers they service as "just another IRC server." The servers don't know anything about the services server other than it's another IRC server on the network. The difference is this... The services "server" "cheats" by sending nick change events for users, disconnecting users, and such depending on what commands are given by a user who has authenticated with those services. In order to write the services, someone might consider starting with ngircd and cutting out the "user can connect" portions, and modifying it to keep an authentication database for users, channels, services ops, and memos (if a memo service is desired.) I'd be happy to help whomever is wanting to write the services, but my time is somewhat limited, so if I end up writing them alone, it will take quite a while to complete. The pseudo-services idea I have is a little more "dangerous" and requires a thorough understanding of how to set up and manage an eggdrop or other irc bot. The irc bot should be running on a server that only trusted users have access to. The bot should be set up to NOT allow "bot op" connections, telnet connections from "any ip," or otherwise present any way for arbitrary users to connect to it and give it commands. The bot should be stripped of non-services scripts. The last part (and this is WHY the tight security) is that the bot should be able to (and must) have OPER privileges on the irc server it connects to. Why? The setting that allows IRC operators to make themselves CHANNEL operators makes this a god-send for "quick and dirty" services-via-bot setups. Scripts can be written to handel "chanserve" functionality with little effort. Modifications to ngircd would need to be made to allow IRC Operators the ability to change other users' nicknames on the fly for NickServe functionality to exist, but this may (or may not) be easily accomplished. Anyway, these are the ideas I've had, and hopefully they'll help someone out. Comments, flames, and other verbage are welcome :) Stefan __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

2 1

Fwd: ngIRCd <= v0.8.2 Format String Vulnerability
by Alexander Barton 04 Feb '05

04 Feb '05

For your information. Regards Alex > Von: CoKi <coki(a)nosystem.com.ar> > Datum: 3. Februar 2005 3:09:09 Uhr MEZ > An: bugtraq(a)securityfocus.com > Betreff: ngIRCd <= v0.8.2 Format String Vulnerability > X-Mailer: MIME-tools 5.411 (Entity 5.404) > > > > ------------------------------------------------- > No System Group - Advisory #11 - 03/02/05 > ------------------------------------------------- > Program: ngIRCd > Homepage: http://arthur.ath.cx/~alex/ngircd/ > Operating System: Linux and Unix-Compatible > Vulnerable Versions: ngIRCd v0.8.2 and prior > Risk: High > Impact: Remote Format String Vulnerability > ------------------------------------------------- > > > - DESCRIPTION > ------------------------------------------------- > ngIRCd is a portable IRC daemon written from scratch. > It is easy to configure, supports server links (even > with original ircds) and runs on hosts with changing > IP addresses (such as dial-in networks). Currently > supported platforms are AIX, A/UX, Darwin/Mac OS X, > FreeBSD, HP-UX, IRIX, Linux, NetBSD, SunOS/Solaris, > and Windows with Cygwin. > > More informations at: http://arthur.ath.cx/~alex/ngircd/ > > > - DETAILS > ------------------------------------------------- > Exist a format string bug in the Log_Resolver() function > of log.c when parses erroneous arguments to the syslog() > function. This may give a remote shell with privileges of > ngIRCd, it's 'root' by default. > > ----------- log.c ------------ > 261: vsnprintf( msg, MAX_LOG_MSG_LEN, Format, ap ); > 262: va_end( ap ); > 263: > 264: /* Output */ > 265: if( NGIRCd_NoDaemon ) > 266: { > 267: /* Output to console */ > 268: fprintf( stdout, "[%d:%d] %s\n", (INT)getpid( ), > Level, msg ); > 269: fflush( stdout ); > 270: } > 271: #ifdef SYSLOG > 272: else syslog( Level, msg ); > 273: #endif > ----------- log.c ------------ > > Here we can look that exist a format string vulnerability > in 272 line of log.c > > > - EXPLOIT > ------------------------------------------------- > To obtain a successful exploitation, we need that > ngIRCd has been compiled with IDENT, logging to > SYSLOG and DEBUG enabled. > > We now will look a part of the code of resolve.c: > > ----------- resolve.c ------------ > 96: /* For sub-process */ > 97: pid = fork( ); > 98: if( pid > 0 ) > 99: { > 100: /* Main process */ > 101: Log( LOG_DEBUG, "Resolver for %s created (PID > %d).", inet_ntoa( Addr->sin_addr ), pid ); > 102: FD_SET( s->pipe[0], &Resolver_FDs ); > 103: if( s->pipe[0] > Conn_MaxFD ) Conn_MaxFD = > s->pipe[0]; > 104: s->pid = pid; > 105: s->stage = 0; > 106: s->bufpos = 0; > 107: return s; > 108: } > > [...] > > 230: #ifdef IDENTAUTH > 231: /* Do "IDENT" (aka "AUTH") lookup and write result to > parent */ > 232: Log_Resolver( LOG_DEBUG, "Doing IDENT lookup on socket %d > ...", Sock ); > 233: res = ident_id( Sock, 10 ); > 234: Log_Resolver( LOG_DEBUG, "Ok, IDENT lookup on socket %d > done: \"%s\"", Sock, res ? res : "" ); > 235: > 236: /* Write IDENT result into pipe to parent */ > 237: len = strlen( res ? res : "" ); > 238: if( res != NULL ) res[len] = '\n'; > 239: len++; > 240: if( (size_t)write( w_fd, res ? res : "\n", len ) != > (size_t)len ) > 241: { > 242: Log_Resolver( LOG_CRIT, "Resolver: Can't write to > parent (IDENT): %s!", strerror( errno )); > 243: close( w_fd ); > 244: } > 245: free( res ); > 246: #endif > ----------- resolve.c ------------ > > At 97 lines of resolve.c we can see that is > created a new process with fork() function, > this will allow us to obtain the exact address > of RET of automatic way without ircd dies. > We can see too that this process do IDENT lookup > when a host is connected to the ircd daemon, > and using the vulnerable function for logging > with syslog at 242 lines of this code. > > I have written a code exploit that use this > method for obtain a root shell in the target. > > http://www.nosystem.com.ar/exploits/ngircd_fsexp.c > > root@servidor:/home/coki/audit# ./ngircd_fsexp -h victim -t 1 -o 10000 > > ngIRCd <= 0.8.2 remote format string exploit > by CoKi <coki(a)nosystem.com.ar> > > [*] host : victim > [*] system : Slackware Linux 10.0 > [*] ircd version : ngircd-0.8.2.tar.gz > [*] syslog GOT address : 0x08068094 > [*] verifying host : 10.0.0.2 > > [*] trying RET address : 0x0806d710 (offset 10000) > [*] building evil buffer : done! > [*] running fake ident server : 0.0.0.0:113 > > [*] connecting to ircd... : 10.0.0.2:6667 connected > [*] waiting for answer... : 10.0.0.1:43260 connected > [*] sending evil ident... : done! > [*] checking for shell... : done! > > [!] you have a shell :) > > Linux victim 2.4.26 #29 Mon Jun 14 19:22:30 PDT 2004 i686 unknown > unknown GNU/Linux > uid=0(root) gid=0(root) > groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(flop > py) > > > - SOLUTIONS > ------------------------------------------------- > The patch is included here: > > --- src/ngircd/log.c 2004-06-26 06:06:27.000000000 -0300 > +++ src/ngircd/log.c.patch 2005-02-02 12:53:33.000000000 -0300 > @@ -269,7 +269,7 @@ > fflush( stdout ); > } > #ifdef SYSLOG > - else syslog( Level, msg ); > + else syslog( Level, "%s", msg ); > #endif > } /* Log_Resolver */ > > > - REFERENCES > ------------------------------------------------- > http://www.nosystem.com.ar/advisories/advisory-11.txt > > > - CREDITS > ------------------------------------------------- > Discovered by CoKi <coki(a)nosystem.com.ar> > > No System Group - http://www.nosystem.com.ar -- Alexander Barton, Freiburg, Germany http://www.barton.de/, alex(a)barton.de

1 0

ngIRCd 0.8.2
by Alexander Barton 03 Feb '05

03 Feb '05

Hi All! ngIRCd 0.8.2, the "hey there are contributors" release has just hit the ground :-) Many thanks go to Florian Westphal for his work! Everybody running an older version of ngIRCd should upgrade to this version because some remotely exploitable security related bugs (that could cause the daemon to crash) have been fixed! Note: if you are using the CVS HEAD branch then you should run an CVS update and use the current code base. Changes since version 0.8.1 are: - Added doc/SSL.txt to distribution. - Fixed a buffer overflow that could cause the daemon to crash. Bug found by Florian Westphal, <westphal(a)foo.fh-furtwangen.de>. - Fixed a possible buffer underrun when reading the MOTD file. Thanks to Florian Westphal, <westphal(a)foo.fh-furtwangen.de>. - Fixed detection of IRC lines which are too long to send. Detected by Florian Westphal, <westphal(a)foo.fh-furtwangen.de>. - Fixed return values of our own implementation of strlcpy(). The code has been taken from rsync and they fixed it, but we didn't until today :-/ It has only been used when the system didn't implement strlcpy by itself, not on "modern" systems. Florian Westphal, <westphal(a)foo.fh-furtwangen.de>. You can download ngIRCd 0.8.2 (~271 KB) from: - <http://download.berlios.de/ngircd/ngircd-0.8.2.tar.gz> - <ftp://ftp.berlios.de/pub/ngircd/ngircd-0.8.2.tar.gz> - <ftp://Arthur.Ath.CX/pub/Users/alex/ngircd/ngircd-0.8.2.tar.gz> And the patch from 0.8.1 to 0.8.2 (~3 KB) as well as GnuPG signatures can be found here: - <ftp://ftp.berlios.de/pub/ngircd/> - <ftp://Arthur.Ath.CX/pub/Users/alex/ngircd/> This release has been tagged as "rel-0-8-2" in the CVS. Regards Alex -- Alexander Barton, Freiburg, Germany http://www.barton.de/, alex(a)barton.de

2 7

ngIRCd 0.8.3
by Alexander Barton 03 Feb '05

03 Feb '05

Hi All! An other exploitable bug in ngIRCd has been found, so here is jet an other update: ngIRCd 0.8.3 has been released! The bug is only exploitable when the daemon is compiled to do IDENT lookups, which is not the default configuration. If you don't use IDENT lookups with your ngIRCd, you are safe. All other should update as soon as possible as this bugs allows remote attackers to execute arbitrary code with the priviledges of the ngIRCd. The only change since version 0.8.2 is: - Fixed a bug that could case a root exploit when the daemon is compiled to do IDENT lookups and is logging to syslog. Bug discovered by CoKi, <coki(a)nosystem.com.ar>, thanks a lot! (http://www.nosystem.com.ar/advisories/advisory-11.txt) You can download ngIRCd 0.8.3 (~271 KB) from: - <ftp://ftp.berlios.de/pub/ngircd/ngircd-0.8.3.tar.gz> - <ftp://Arthur.Ath.CX/pub/Users/alex/ngircd/ngircd-0.8.3.tar.gz> - <http://download.berlios.de/ngircd/ngircd-0.8.3.tar.gz> [soon ...] And the patch from 0.8.2 to 0.8.3 (~3 KB) as well as GnuPG signatures can be found here: - <ftp://ftp.berlios.de/pub/ngircd/> - <ftp://Arthur.Ath.CX/pub/Users/alex/ngircd/> This release has been tagged as "rel-0-8-3" in the CVS. Regards Alex -- Alexander Barton, Freiburg, Germany alex(a)barton.de, http://www.barton.de/

1 0

Fwd: [ GLSA 200501-40 ] ngIRCd: Buffer overflow
by Alexander Barton 29 Jan '05

29 Jan '05

For your information. But now the bug is published, so all servers should really be updated as fast as possible. Regards Alex > Von: Thierry Carrez <koon(a)gentoo.org> > Datum: 28. Januar 2005 23:07:30 Uhr MEZ > An: gentoo-announce(a)lists.gentoo.org > Cc: bugtraq(a)securityfocus.com, full-disclosure(a)lists.netsys.com, > security-alerts(a)linuxsecurity.com > Betreff: [ GLSA 200501-40 ] ngIRCd: Buffer overflow > User-Agent: Mozilla Thunderbird 1.0 (X11/20041208) > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Gentoo Linux Security Advisory GLSA 200501-40 > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > http://security.gentoo.org/ > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > Severity: High > Title: ngIRCd: Buffer overflow > Date: January 28, 2005 > Bugs: #79705 > ID: 200501-40 > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > Synopsis > ======== > > ngIRCd is vulnerable to a buffer overflow that can be used to crash the > daemon and possibly execute arbitrary code. > > Background > ========== > > ngIRCd is a free open source daemon for Internet Relay Chat (IRC). > > Affected packages > ================= > > ------------------------------------------------------------------- > Package / Vulnerable / Unaffected > ------------------------------------------------------------------- > 1 net-irc/ngircd < 0.8.2 >= 0.8.2 > > Description > =========== > > Florian Westphal discovered a buffer overflow caused by an integer > underflow in the Lists_MakeMask() function of lists.c. > > Impact > ====== > > A remote attacker can exploit this buffer overflow to crash the ngIRCd > daemon and possibly execute arbitrary code with the rights of the > ngIRCd daemon process. > > Workaround > ========== > > There is no known workaround at this time. > > Resolution > ========== > > All ngIRCd users should upgrade to the latest version: > > # emerge --sync > # emerge --ask --oneshot --verbose ">=net-irc/ngIRCd-0.8.2" > > References > ========== > > [ 1 ] ngIRCd Release Annoucement > > http://arthur.ath.cx/pipermail/ngircd-ml/2005-January/000228.html > > Availability > ============ > > This GLSA and any updates to it are available for viewing at > the Gentoo Security Website: > > http://security.gentoo.org/glsa/glsa-200501-40.xml > > Concerns? > ========= > > Security is a primary focus of Gentoo Linux and ensuring the > confidentiality and security of our users machines is of utmost > importance to us. Any security concerns should be addressed to > security(a)gentoo.org or alternatively, you may file a bug at > http://bugs.gentoo.org. > > License > ======= > > Copyright 2005 Gentoo Foundation, Inc; referenced text > belongs to its owner(s). > > The contents of this document are licensed under the > Creative Commons - Attribution / Share Alike license. > > http://creativecommons.org/licenses/by-sa/2.0 -- Alexander Barton, Freiburg, Germany http://www.barton.de/, alex(a)barton.de

1 0

Custom Features?
by Josh Coombs 22 Jan '05

22 Jan '05

Got a couple oddball feature requests I'd like to bounce off you... 1 - External Auth Mechanism Currently, ngircd supports a single global server password option. I'd like to be able to do specific user/pass pairs on connect. Either setting them up in the conf, an external flat file, or the option to call an external script, pass it the user/pass pair, and allow the connect if it returns without error (allowing radius/ldap/etc based auth without having to support it directly in ngricd) would be slick. 2 - Toggle to restrict use of /nick and channel creation to those with +o. By itself this doesn't do much, but in combination with the above, this allows much more control of the ircd's use, making it appropriate to use in an internal LAN/buisiness environment. One last question, have the services provisions been fleshed out enough to warrant trying third party service apps, or are they still too rough? Joshua Coombs

2 2

[Patch] +s (secret) channel mode
by Florian Westphal 22 Jan '05

22 Jan '05

Hi, this simple patch adds support for secret '+s' channels to ngircd. A "secret" channel does not show up in /LIST output (unless user is on that channel) Florian

2 1

Springe zur Seite:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

ngIRCd Users