A vulnerability has been reported in libmodplug, which can be exploited by malicious people to compromise an application using the library.
The vulnerability is caused due to an integer overflow within the "CSoundFile::ReadMed()" function in src/load_med.cpp when loading MED files. This can be exploited to cause a heap-based buffer overflow by e.g. opening a specially crafted MED file in an application using the library.
The vulnerability is reported in versions prior to libmodplug 0.8.6.
gstreamer: Can we get a version building against the system modplug stable or backport the patch mentioned in bug 253485?
For reference: http://secunia.com/advisories/34797/
sound: To be a little more precise, please bump to 0.8.6.
gstreamer is waiting for a bumped and stabilized libmodplug, stabling of gstreamer then via bug 266986.
On Monday 27 April 2009, Jan Lieskovsky wrote:
> FYI Konstanty has added more checks (for // Sample Names
> potential overflow) and also null terminations for
> relevant strings (to ensure string safety) at:
> So new 0.8.7 release of libmodplug is available.
bumped to 0.8.7
Arches, please test and mark stable:
Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 sh x86"
Stable for HPPA: =media-libs/libmodplug-0.8.7. Please don't forget to readd firstname.lastname@example.org when gstreamer is ready.
Integer overflow in the CSoundFile::ReadMed function
(src/load_med.cpp) in libmodplug before 0.8.6, as used in
gstreamer-plugins and other products, allows context-dependent
attackers to execute arbitrary code via a MED file with a crafted (1)
song comment or (2) song name, which triggers a heap-based buffer
ppc, ppc64: You guys failed to actually mark the ebuild stable, bringing you back
libmodplug stable on alpha.
Alright, libmodplug is done. Now we'll have to wait for gstreamer.
Buffer overflow in the PATinst function in src/load_pat.cpp in
libmodplug before 0.8.7 allows user-assisted remote attackers to
cause a denial of service and possibly execute arbitrary code via a
long instrument name.