[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[patch] kadmind buffer overrun
I recently reported what seemed like a bug in kadmin. I have since
realised that it is not kadmin which dumps on be but rather it is
kadmind. The bug is confounded further by not appearing on solaris7.
The short version is this (apply to kadmin/server.c):
--- server.c.orig Tue Jun 15 15:47:12 1999
+++ server.c Tue Jun 15 15:47:33 1999
@@ -387,7 +387,7 @@
int fd)
{
krb5_error_code ret;
- u_char tmp[4];
+ u_char tmp[len+1];
krb5_ticket *ticket;
krb5_principal server;
char *client;
I.e a fixed size buffer causes some stuff on the stack (in this case
the krb5_context) to get overwritten. I am sorry about the gccism in
the allocation -- you guys (assar & joda) can do it some other way
if you like ;-) The long story follows:
This is the situation:
* A fresh os install (a fresh FreeBSD 3.1 this time but I have been
able to reproduce it on Linux aswell) with heimdal 0.1g. The kdc works
as a charm btw -- my earlier report of problems with master key encryption
was bogosity itself
* I start kadmind -p 749 -d under gdb and run the client from another
host: I add a breakpoint at handle_v5 to show you what happens. Keep your
eyes glued to the context variable!
bash-2.02# gdb ./kadmind
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.16 (i386-unknown-freebsd),
Copyright 1996 Free Software Foundation, Inc...
(gdb) break handle_v5
Breakpoint 1 at 0x804a835: file server.c, line 396.
(gdb) run -d -p 749
Starting program: /usr/local/src/heimdal-0.1g/kadmin/./kadmind -d -p 749
Breakpoint 1, handle_v5 (context=0x807c000, ac=0x0, keytab=0x0, len=19, fd=0)
at server.c:396
396 krb5_net_read(context, &fd, tmp, len);
(gdb) p context
$1 = (krb5_context_data *) 0x807c000
(gdb) p *context
$2 = {etypes = 0x0, default_realm = 0x807f280 "MATEMATIK.SU.SE",
max_skew = 300, kdc_timeout = 3, max_retries = 3, kdc_sec_offset = 0,
kdc_usec_offset = 0, cf = 0x807f030, et_list = 0x807b0a0,
warn_dest = 0x807f290, cc_ops = 0x0, num_ops = 0, http_proxy = 0x0,
time_fmt = 0x80736e7 "%d-%b-%Y %H:%M:%S", log_utc = 0,
default_keytab = 0x80736c5 "FILE:/etc/krb5.keytab", use_admin_kdc = 0,
extra_addresses = 0x0, srv_lookup = 1, srv_try_txt = 0, srv_try_rfc2052 = 1,
fcache_vno = 0}
(gdb) s
krb5_net_read (context=0x807c000, p_fd=0xefbfdb68, buf=0xefbfdb4c, len=19)
at net_read.c:51
51 return net_read (fd, buf, len);
(gdb) n
52 }
(gdb) p context
$3 = (krb5_context_data *) 0x807c000
(gdb) n
handle_v5 (context=0x31565f48, ac=0x302e, keytab=0x0, len=19, fd=0)
at server.c:397
397 if(len != sizeof(KRB5_SENDAUTH_VERSION) ||
(gdb) p context
$4 = (krb5_context_data *) 0x31565f48
(gdb) p *context
Error accessing memory address 0x31565f48: Bad address.
(gdb)
Shortly hereafter context->default_realm causes a SIG:
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
krb5_get_default_realm (context=0x31565f48, realm=0xefbfdb10)
at get_default_realm.c:49
49 if (context->default_realm == NULL)
(gdb)
Anyways, I put a watch on context in handle_v5 and get this (this is
from a later run of gdb):
Old value = (krb5_context_data *) 0x807c000
New value = (krb5_context_data *) 0x31565f48
0x280ddfe4 in _read ()
(gdb) bt
#0 0x280ddfe4 in _read ()
#1 0x8070b9e in net_read (fd=0, buf=0xefbfdb1c, nbytes=19) at net_read.c:65
#2 0x8056047 in krb5_net_read (context=0x807c000, p_fd=0xefbfdb38,
buf=0xefbfdb1c, len=19) at net_read.c:51
#3 0x804a84b in handle_v5 (context=0x31565f48, ac=0x302e, keytab=0x0, len=19,
fd=0) at server.c:396
#4 0x54554144 in ?? ()
Error accessing memory address 0x4e45535f: Bad address.
In fact this is where you see the problem: len is 19 but the u_char
buffer set to handle the read is of length 4. The result is stack
pandemonium!
Cheers,
Leif Johansson Phone: +46 8 164541
Department of Mathematics Fax : +46 8 6126717
Stockholm University email: leifj@matematik.su.se
<This space is left blank for quotational and disclamatory purposes.>