TkServ IRC Service Contains Several Vulnerabilities That Could Be Used to Remotely Cause the Server to Crash or to Execute Arbitrary Commands or Code
SecurityTracker Alert ID: 1001080|
SecurityTracker URL: http://securitytracker.com/id/1001080
(Links to External Site)
Date: Mar 13 2001
Denial of service via network, User access via network|
Version(s): tkserv.c v1.3.0 and previous versions|
There are reportedly several bugs in the TkServ IRC service daemon. The vulnerabilities include a buffer overflow, a memory leak, and a format string vulnerability that can be used to crash the server or cause arbitrary code to be executed on the server. TkServ is an IRC service featuring temporary k-lines.|
While querying tklines, a buffer overflow may occur in the "void squery_tkline(char **args)" module in tkserv.c. Sending a specially crafted tkline squery to TkServe may result in the execution of arbitrary code on the server. See the original report for more details on the location of the overflow and restrictions on the exploit scenario.
A memory leak may occur in "int must_be_opered()". The report indicates that stressing the TkServ with many unauthorized squery requests may result in excessive memory usage.
A format string bug may occur while reading the IRCd's config file. There is a vulnerable call to "fprintf" such that the inclusion of format characters in the config file may be improperly interpreted.
A user may remotely cause the server to crash or could cause the server to remotely execute arbitrary commands or code.|
No solution was available at the time of this entry.|
Vendor URL: home.snafu.de/kl/tkserv/ (Links to External Site)
Boundary error, Input validation error, Resource error|
|Underlying OS: Linux (Any), UNIX (Any)|
This archive entry has one or more follow-up message(s) listed below.|
Source Message Contents
Subject: Remote buffer overflow,|
There are 3 major bugs in the current IRCd distribution (as used on the
IRCnet for example). The included service daemon 'tkserv' (tkserv.c v1.3.0 and all previous
versions) suffers from:
a) remote exploitable buffer overflow while querying tklines
b) memory leck due to strdup'ing a string and not freeing the mem
c) format string bug while reading the ircd's config file
a) There is an buffer overflow in the 'void squery_tkline(char **args)' from tkserv.c. The bad part
/* User wants to add tkline(s). */
if (lifetime > 0)
passwd = args;
pattern = args;
(*) strcpy(reason, args);
i = 8;
/* I know... */
while(args[i] && *args[i])
strncat(reason, " ", TKS_MAXKILLREASON - strlen(reason) - 1);
strncat(reason, args[i], TKS_MAXKILLREASON - strlen(reason) - 1);
where reason is defined to be a static char buffer 'char reason[TKS_MAXKILLREASON]' and
TKS_MAXKILLREASON is defined to be only 128 characters. Sending an carefully crafted tkline squery
to vulnerable tkserv may result in remote code execution and further compromise. Indeed after
at a running tkserv in gdb, I found that exploitation of this flaw should be very easy. There are
only few conditions to meet, e.g. the *args[i] part...
We also need to meet the condition 'must_be_opered()' which is checked before the vulnerable code is
entered by tkserv. This occurs, if in the tkserv.access file there is at least one access line _not_
containing "!" as the first character, which means that the corresponding user@host pair do _not_
need to have OPER priviledges prior to use tkserv. Or in other words, requesting at least one
user@host pair in tkserv.access to have OPER priviledges prior to using tkserv results in remote
buffer overflow vulnerability.
Of course, having a matching user@host pair, but no tkserv access (which is not so uncommon, believe
me.. there are some configuration pitfalls concerning the user@host lines, which I don't want to
reveal ;-) the vulnerability can be exploited too.
So overflowing 'reason' results in overwriting saved EIP with well known consequences.
b) The bad part is (**):
/* if the access file exists, check for auth */
if ((fp = fopen(TKSERV_ACCESSFILE, "r")) != NULL)
char *access_uh, *token, *uh;
while (fgets(buffer, TKS_MAXBUFFER, fp))
uh = (char *) (strchr(nuh, '!') + 1);
token = (char *) strtok(buffer, " ");
(**) access_uh = (char *) strdup(token);
the pointer returned by strdup is never a subject a free() call. So stressing the tkserv with many
unauthorized (!) squery's results in excessive memory usage in effectively in denying the service
and maybe other services running on the vulnerable box.
c) While the tkserv parses the ircd.conf file, e.g. after requesting a new k-line (the original
ircd.conf is read line-by-line and the modified copy written to ircd.conf.tmp, which is copied to
ircd.conf after tkserv has finished reading the original config file) there is a vulnerable call to
int check_tklines(char *host, char *user, int lifetime)
FILE *iconf, *iconf_tmp;
if ((iconf = fopen(CPATH, "r")) && (iconf_tmp = fopen(TKSERV_IRCD_CONFIG_TMP, "w")))
int count = 0, found = 0;
/* just in case... */
chmod(TKSERV_IRCD_CONFIG_TMP, S_IRUSR | S_IWRITE);
now = time(NULL);
while (fgets(buffer, TKS_MAXBUFFER, iconf))
if ((*buffer != 'K') || (!strstr(buffer, "tkserv")))
(***) fprintf(iconf_tmp, buffer);
the original ircd.conf is fprint'ed line by line to a temporary copy, so if one can include some
format conversion operators there, the code will fail (hm, what about /timer1234 99999 5 /msg
someoper hey moron... ok, I know, with current BIND it wouldn't work...). I think, this is not
exploitable in the wild.
See discussion. Do not request opered access to your tkserv. Update as soon as possible.
IhaQueR Security Research.
Go to the Top of This SecurityTracker Archive Page