[syslog-ng]Security: syslog-ng 1.4.x and 1.5.x is vulnerable to buffer overflow

Katsuhiro Kondou kondou@isc.org
Fri, 04 Oct 2002 18:36:00 +0900 (JST)


In article <3D9D1811.nail1Z311GE@andromeda.rutgers.edu>,
	William Yodlowsky <wyodlows@andromeda.rutgers.edu> wrote;

} Program received signal SIGSEGV, Segmentation fault.
} 0xff141f74 in realfree () from /usr/lib/libc.so.1
} (gdb) bt                                                                                                                             
} #0  0xff141f74 in realfree () from /usr/lib/libc.so.1
} #1  0xff142880 in cleanfree () from /usr/lib/libc.so.1
} #2  0xff1419b4 in _malloc_unlocked () from /usr/lib/libc.so.1
} #3  0xff1418a8 in malloc () from /usr/lib/libc.so.1
} #4  0x2abf8 in xalloc ()
} #5  0x2adc0 in ol_space_alloc ()

As I wrote before mine was also dead at malloc().  I just
tried ugly patching not to zero sized allocation, which
means allocated size will be more than one byte if xalloc()
tries to allocate 0 like this;

  if (size == 0)
    size++;

Even with the patch, I still get the core;

(gdb) bt
#0  0xff141bec in realfree () from /usr/lib/libc.so.1
#1  0xff1424f8 in cleanfree () from /usr/lib/libc.so.1
#2  0xff14162c in _malloc_unlocked () from /usr/lib/libc.so.1
#3  0xff141520 in malloc () from /usr/lib/libc.so.1
#4  0x21cc0 in xalloc ()
#5  0x17840 in make_log_info (length=0, msg=0x0, prefix=0x0, flags=0)
    at log.c:272
#6  0x15ba4 in do_handle_line (self=0x55b68, length=164, 
    data=0x56490 "<150>Oct  4 17:29:47 local@ks0003 named[13188]: [ID 866145 local2.info] Oct 04 17:29:47.956security: client 10.17.0.25#58886: query 'ks0302.XXX.ne.jp/IN' denied\n<150>Oct  4 17:29:50 local@ks0003 n"..., addr=0x56490, 
    addrlen=0) at sources.c:68
#7  0x15d48 in do_read_line (h=0x56534, read=0xffbef998) at sources.c:138
#8  0x1ff54 in read_callback ()
#9  0x1fbcc in io_iter ()
#10 0x152d8 in main_loop (backend=0x39758) at main.c:192
#11 0x159c8 in main (argc=0, argv=0xffbefd04) at main.c:516
(gdb) frame 5
#5  0x17840 in make_log_info (length=0, msg=0x0, prefix=0x0, flags=0)
    at log.c:272
272             NEW_SPACE(self);

from above trace and my experience at other development
project, I think this is due to the memory handling problem
by the program bug.
-- 
Katsuhiro Kondou