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.)
Kde please advise and patch as necessary.
0.4.x series is masked already because there are other problems, too. 0.5.x series won't be in portage anytime soon I think, as that breaks once again API and ABI compatibility, and no software currently supports 0.5 a part picard itself. If 0.3.x series is not affected, I suppose we can simply drop 0.4.x series and skip it until (if) 0.5.x can be used.
@Diego: 0.3.0 contains the the same variable with the same buffer sizes: 55 char error[255], data[255], trackURI[256], 164 // Pull back the release date and release country 165 if (mb_GetResultData(o, MBE_ReleaseGetDate, data, 256))
So I could fix this, or simply decide we don't need tunepimp/musicbrainz anymore. 0.3 is likely not to work for much longer, as the service seems to be ready to drop the old "audio fingerprint" method for the one in series 0.5 (that is currently not supported by anything for what I know).
Considering 0.3/0.4 are legacy, 0.4 has troubles, 0.5 is not supported by anything we have in portage at the moment (it's required by picard but that's not in portage yet). So my solution is: drop musicbrainz useflag from juk, kdemultimedia, amarok, kid3, mask tunepimp and trm (its client), and send last rites to remove them in 30 days. Finally, make sure that _nothing_ lesser than 0.5 enters portage anymore. I would also think that it should _not_ re-enter portage till upstream decides on an API for more than a couple of months.
Ok, please post a comment when it is done.
Masked, last rites sent, all musicbrainz useflags dropped.
Thx Diego. This one is ready for masking GLSA.
GLSA 200607-11 Thanks everybody! (keeping open as enhancement because we masked this)
I recommend that this package be version bumped to 0.5.0 instead of removed. The SVN version of Amarok is using the new 0.5 API, so at some point within the next few weeks we'll have a new version of Amarok in ~x86 that can use libtunepimp again.
Now that amarok-1.4.2 has been released and uses libtunpimp-0.50 should this version be added back into portage or does the vulnerability still exist?
Are we sure this is fixed in 0.5, in the first place? About Amarok support, I'd be waiting on upstream telling me about it, libtunepimp is not API stable and I don't want to do this mess once again next month or the one after....
musicbrainz bug link says this bug is fixed
yes, 0.4.3 corrects this issue. kde-team, please bump this new revision when you can libtunepimp ChangeLog: ---------------------- version 0.4.3: - Fixed check for TagLib 1.4 in configure.in + few other build system fixes. - Fixed buffer overflow in lookuptools.cpp (patch by urs_fleisch at yahoo dot de). - Fixed memleaks in the WMA plugin.
No bump will be done, I don't want to return to the infinite cycle to add, remove, patch, and so on because upstream takes months to fix a simple issue, and in the mean time we need to act. MusicBrainz support will remain disabled, and if I'm not able to find the cause of the crash of Amarok and fix it, 0.5 series might be dropped maintenance.
Iirc 0.4.x wasn't API compatible either. Fixing the 0.3 vulnerability wouldn't be the problem, but to slot the package we'd need to move/adjust include/lib paths - and that for 0.3 as well as all packages using it. Even though I used to use Juk and its musicbrainz functionality, I'm not annoyed enough to do it. If someone is so keen about it, that he does the patches, I wouldn't mind restoring 0.3, though.
I unmasked libtunepimp 0.5.1 and modified the ebuild to compile Amarok 1.4.3 with musicbrainz. Everything seems to be working fine here...even better than before. Older versions never crashed Amarok for me it just didn't always return with a response and would hang. I can auto fill my tags using musicbrainz again!
Ahem, invulnerable tunepimp-0.5.x is out of package.mask since 10/06. Time to update security status, I suppose...
KDE herd to security: PING.
Sorry for not taking care of this sooner. Please just ping me way sooner next time. Fixed in CVS.
