While developing (in a team (CCed) for a university project) and testing a
libtunepimp client program, I have found a buffer overflow (actually, 3
buffers can possibly be overflown) in libtunepimp 0.4.2. This bug is promptly
detected by the Fedora Core 5 security features, the program is terminated
with "*** stack smashing detected ***". Still, it might be exploitable on
other systems, possibly including older Fedora releases, so I thought it was
better to go through secalert. 3 stack variables are allocated with 255, 255
and 100 bytes respectively, yet 256 bytes are read into each.
Backtrace:
Thread 5 (Thread -1247491168 (LWP 13178)):
#0 0x00a4a402 in __kernel_vsyscall ()
#1 0x01b2d069 in raise () from /lib/libc.so.6
#2 0x01b2e671 in abort () from /lib/libc.so.6
#3 0x01b61a4b in __libc_message () from /lib/libc.so.6
#4 0x01be2785 in __stack_chk_fail () from /lib/libc.so.6
#5 0x03360d99 in __stack_chk_fail_local () from /usr/lib/libtunepimp.so.3
#6 0x03343135 in LookupTRM::lookup (this=0xb5a4c1e4) at lookuptools.cpp:205
#7 0x00000000 in ?? ()
I have verified that the attached patch fixes the issue. (The actual and
passed buffer sizes now match up, and the program works with no more stack
smashing and is fully functional.)
It turns out the 255->256 issue has already been reported, the much more serious 256->100 one hasn't though, and can be a more serious security issue.
I'm not sure if you're still maintaining 0.4.x nor if this affects 0.5.x, but in any case an advisory on the front page would be a good idea. (A fixed package has been pushed into Fedora Extras without waiting due to some misunderstanding, so keeping it secret won't help anyone.)
