Bug#719462: libmodplug: CVE-2013-4233 CVE-2013-4234
Hi, On 14 August 2013 16:17, Raphael Geissert geiss...@debian.org wrote: Looking at your fix in c4d4e0478, I'd look into fixing it in a way that doesn't imply that integers overflow, as that's undefined behavior and can be optimised away by compilers. None of the instructions can actually decrease j, so j + 1 can never be = 0 if integers don't overflow. Wouldn't it be better to just set a limit to j that is checked while calculating the amount of memory that is needed, and that is lower enough than INT_MAX that performing one more iteration won't overflow it? Attached patch does something like the above and performs a check on the value of i, which I believe can be made to point past the end of the buffer. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net 0001-Don-t-rely-on-the-behaviour-of-signed-integer-overfl.patch Description: Binary data
Bug#719462: libmodplug: CVE-2013-4233 CVE-2013-4234
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.
Bug#719462: libmodplug: CVE-2013-4233 CVE-2013-4234
Hi Konstanty, Looking at your fix in c4d4e0478, I'd look into fixing it in a way that doesn't imply that integers overflow, as that's undefined behavior and can be optimised away by compilers. None of the instructions can actually decrease j, so j + 1 can never be = 0 if integers don't overflow. Wouldn't it be better to just set a limit to j that is checked while calculating the amount of memory that is needed, and that is lower enough than INT_MAX that performing one more iteration won't overflow it? Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719462: libmodplug: CVE-2013-4233 CVE-2013-4234
Package: libmodplug Severity: grave Tags: security Justification: user security hole 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 Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
