Hi Zed, (all), Thanks for forwarding the error. I've applied some fixes for these CVE's. Being a library, I think it is a bit difficult to report a warning (at least there is no API call to get this out).
I've added bounds checking on populating the h->gchord and h->drum variables, and conceptually it will just skip any additional drum/chord flags after 80 have been reached (in practice this might be only 40 as a number '1' if appended to each if it does not already exist). Also, I've committed + synced some other bugs in libmodplug (some evaluation might be needed whether a CVE is needed for some of them as well). https://sourceforge.net/p/modplug-xmms/git/ci/master/tree/ Also, for the purposes of packaging, I've split out libmodplug into its own git tree. https://github.com/Konstanty/libmodplug Let me know if you notice any problems with any of these patches, Konstanty On Wed, Aug 14, 2013 at 11:07 AM, Zed Pobre <z...@resonant.org> wrote: > Hi Konstanty, this is your friendly Debian maintainer. > > I had a security issue in libmodplug sent to me, and I wanted to make > sure you saw it: > > On Mon, Aug 12, 2013 at 08:24:33AM +0200, Moritz Muehlenhoff wrote: > > Hi, > > please see > http://blog.scrt.ch/2013/07/24/vlc-abc-parsing-seems-to-be-a-ctf-challenge/ > > > > For the CVE assignments: > > http://seclists.org/oss-sec/2013/q3/343 > > At first glance, it looks like the first one can be solved just by > replacing 'j+1' with '(j+1) || j' (though maybe it would be better to > explicitly check to see if someone is attempting an overflow and exit > with a warning instead), but on the others I'm afraid I don't know > where to start. Can you work out what the real maximum size is that > can be generated by those attacks and just up the buffer to that, or > is there something more systemic involved? > > Regards, > > -- > Zed Pobre <z...@resonant.org> a.k.a. Zed Pobre <z...@debian.org> > PGP key and fingerprint available on finger; encrypted mail welcomed. >
