Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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.