Summary: | media-libs/tunepimp buffer overflow (CVE-2006-3600) | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | Sune Kloppenborg Jeppesen (RETIRED) <jaervosz> |
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
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 | ||
URL: | http://bugs.musicbrainz.org/ticket/1764 | ||
Whiteboard: | B2 [glsa] jaervosz | ||
Package list: | Runtime testing required: | --- |
Description
Sune Kloppenborg Jeppesen (RETIRED)
2006-07-12 23:23:34 UTC
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. |