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.
