Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 140184

Summary: media-libs/tunepimp buffer overflow (CVE-2006-3600)
Product: Gentoo Security Reporter: Sune Kloppenborg Jeppesen (RETIRED) <jaervosz>
Component: VulnerabilitiesAssignee: Gentoo Security <security>
Severity: enhancement CC: ansla80, bluelightning, daff, federico.granata, gentoo.2019, james.ausmus, jan, joe.k963, kde, lastrainson, m.debruijne, moixa, pbienst, rdalek1967, tcunha, triffid_hunter
Priority: High    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard: B2 [glsa] jaervosz
Package list:
Runtime testing required: ---

Description Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2006-07-12 23:23:34 UTC
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/
 #2 0x01b2e671 in abort () from /lib/
 #3 0x01b61a4b in __libc_message () from /lib/
 #4 0x01be2785 in __stack_chk_fail () from /lib/
 #5 0x03360d99 in __stack_chk_fail_local () from /usr/lib/
 #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.)
Comment 1 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2006-07-12 23:24:42 UTC
Kde please advise and patch as necessary.
Comment 2 Diego Elio Pettenò (RETIRED) gentoo-dev 2006-07-13 06:59:35 UTC
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.
Comment 3 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2006-07-23 08:43:22 UTC
@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))
Comment 4 Diego Elio Pettenò (RETIRED) gentoo-dev 2006-07-24 19:58:14 UTC
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).
Comment 5 Diego Elio Pettenò (RETIRED) gentoo-dev 2006-07-24 20:21:19 UTC
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.
Comment 6 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2006-07-25 00:12:06 UTC
Ok, please post a comment when it is done.
Comment 7 Diego Elio Pettenò (RETIRED) gentoo-dev 2006-07-25 03:54:40 UTC
Masked, last rites sent, all musicbrainz useflags dropped.
Comment 8 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2006-07-25 04:02:35 UTC
Thx Diego.

This one is ready for masking GLSA.
Comment 9 Stefan Cornelius (RETIRED) gentoo-dev 2006-07-28 13:23:09 UTC
GLSA 200607-11

Thanks everybody!

(keeping open as enhancement because we masked this)
Comment 10 Soren Harward 2006-08-07 11:32:57 UTC
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.
Comment 11 Scott Jubenville 2006-08-22 16:26:01 UTC
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?
Comment 12 Diego Elio Pettenò (RETIRED) gentoo-dev 2006-08-31 07:42:54 UTC
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....
Comment 13 Triffid Hunter 2006-09-08 03:48:44 UTC
musicbrainz bug link says this bug is fixed
Comment 14 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2006-09-08 05:18:28 UTC
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 + 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.
Comment 15 Diego Elio Pettenò (RETIRED) gentoo-dev 2006-09-08 05:41:03 UTC
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.
Comment 16 Carsten Lohrke (RETIRED) gentoo-dev 2006-09-09 16:17:20 UTC
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.
Comment 17 James Johnson 2006-09-22 08:59:25 UTC
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!
Comment 18 Carsten Lohrke (RETIRED) gentoo-dev 2007-03-17 15:26:10 UTC
Ahem, invulnerable tunepimp-0.5.x is out of package.mask since 10/06. Time to update security status, I suppose...
Comment 19 Wulf Krueger (RETIRED) gentoo-dev 2007-05-31 20:51:14 UTC
KDE herd to security: PING.
Comment 20 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2007-06-01 06:09:57 UTC
Sorry for not taking care of this sooner. Please just ping me way sooner next time.

Fixed in CVS.