Bugzilla Bug 139319

Stack-based buffer overflow in MiMMS 0.0.9 allows remote attackers to cause a
denial of service (application crash) and possibly execute arbitrary code via
the (1) send_command, (2) string_utf16, (3) get_data, and (4) get_media_packet
functions, and possibly other functions.

yes, i confirm there is at least the string_utf16() issue. But i can't find,
for example, the first memcpy overflow.

See the debian patch in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=374577

Probably a good idea to CC maintainer.

http://xine.cvs.sourceforge.net/xine/xine-lib/src/input/mms.c?r1=1.59&r2=1.60
http://xine.cvs.sourceforge.net/xine/xine-lib/src/input/mmsh.c?r1=1.37&r2=1.38

I handle xine-lib myself, would have been simpler to find if you CCed me :)

This is what Matthias Hopf said on xine-devel:

--
unfortunately this only made it through after xine-lib 1.1.2 release:

There has been a vulnerability report about libmms on [vendor-sec].
(CVE-2006-2200)

Please note that the original patch from the Debian maintainer is
partially incorrect (it should read memset(dest,0,2*len)), but the memset
isn't really necessary and could be nuked anyway. The use of memset in
the patch certainly doesn't do any harm, though, and it fixes the
potential overflow.

Luckily, xine uses libmms in a way that these vulnerabilities cannot be
exploited (buffers are large enough), and the xine module even seems to
rely on the side effects of the memset of the 'broken' library. 

I handle xine-lib myself, would have been simpler to find if you CCed me :)

This is what Matthias Hopf said on xine-devel:

--
unfortunately this only made it through after xine-lib 1.1.2 release:

There has been a vulnerability report about libmms on [vendor-sec].
(CVE-2006-2200)

Please note that the original patch from the Debian maintainer is
partially incorrect (it should read memset(dest,0,2*len)), but the memset
isn't really necessary and could be nuked anyway. The use of memset in
the patch certainly doesn't do any harm, though, and it fixes the
potential overflow.

Luckily, xine uses libmms in a way that these vulnerabilities cannot be
exploited (buffers are large enough), and the xine module even seems to
rely on the side effects of the memset of the 'broken' library.  Note
that the library sources are included (not an externally linked
library).

While analyzing the source I found a couple of potential heap overflows,
though, which I'm pretty sure that they can be exploited with some
effort. They are fixed in CVS. I also attached the according patch. But
I'm pretty sure that I overlooked some additional ones.

This source is a wormhole.
Sorry, Thibaut, but then you maybe coded the glue layer only :-]
--

Will prepare a 1.1.2-r2 after lunch, or during lunch. -r2 in less than 24 hours
past release, sigh.

Thx Diego.

I assumed that you were on the media-video alias?

I am, I just assign different priorities to them :P
Depending on the quantity of new messages sometime i mark all as read on
aliases, but never on my own. Anyway, building xine-lib-1.1.2-r2 now.

1.1.2-r2 in portage. Stable marking shouldn't be an issue for most arches, as
this version has no big changes since last snapshots (as most of the patches
applied before are now merged upstream, and are the important changes in the
last month or so).

The only problem is with ~sh that is missing ffmpeg dependency, and ia64 that
still has 1.1.1 keyworded (vulnerable to other stuff too).

Thx for clearing that up Diego.

Arches please test and mark stable.

ppc stable

amd32*2 done.

x86 is all happy ^.^;;

stable on ppc64

SPARC, the keyword of time immortal.

 ______________
< alpha stable >
 --------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

Stable on hppa. Sorry for the delay.

Ready for GLSA

GLSA 200607-07

Does not affect current (2008.0) release. Removing release.