On Sat, Sep 30, 2017 at 08:17:50PM +0200, Guido Günther wrote: > Hi Ron, > Looking at > > > https://anonscm.debian.org/cgit/users/ron/mp3splt.git/commit/?id=18f018cd774cb931116ce06a520dc0c5f9443932 > > do you really mean CVE-2017-11333¹? Isn't this CVE-2017-11735²? Both where > reported in the same message. I can confirm that this fixes > CVE-2017-11735 for me.
Yes, it looks like you're right. This came to my attention through the CVE-2017-11333 report being discussed among Xiph folks, and it looks like I missed the fine print given in the details at: http://seclists.org/fulldisclosure/2017/Jul/82 as to those two issues actually being assigned separate CVEs ... When the second issue (really CVE-2017-11735) looked like it wasn't a bug in libvorbis, I put on my mp3splt maintainer hat and chased it down there. I don't see any other bug remaining for that particular issue and test case with the patch from above applied. > Security team, if the CVE is in mp3splt not libvorbis do we need to give > back the CVE and request a new one? Is doing this via > > https://cveform.mitre.org/ > > The right thing? I'm not sure what the administratively correct thing there is, but I can confirm CVE-2017-11735 really is an issue with mp3splt and not with libvorbis (and that it's not actually a NULL pointer dereference like the CVE claims, but rather a case of passing an uninitialised (and not NULL) struct with garbage values in it to libvorbis, after the error in the test file is correctly detected). Any file that caused mp3splt to error out early in opening the file would have done much the same thing. My first-blush analysis is that this one isn't a significant security risk - it's not acting on any attacker supplied data, just on the existing content of uninitialised memory returned by malloc when the code tries to exit if the attacker passes an invalid file - so it may crash instead of exiting cleanly, but that's about it. And this isn't very likely to be running as a network accessible service that people can remotely pass files to and DoS - it just won't split a file that was invalid and had nothing to be split in it anyway if a user gets such a file from somewhere and tries to split it before trying to pass it to any other decoder program. That said through, it's not clear to me if mp3splt still has an active upstream maintainer - the last release was in 2014, the last reply to the upstream list from Alex was over a year ago, and the one prior to that was more than 2 years ago now. It's still a bit early to say that the message I posted there reporting this a few days ago has had "no response", but it's definitely been pretty quiet there for quite some time now. So there could be some value in passing on a memo to other distro maintainers that if they want this fixed they should probably grab the patch above and apply it to mp3splt themselves for now. Thanks for catching my misattribution of the CVE number there, I'll fix that in the changelog for the next release to avoid future confusion. Just let me know if I should (also?) note it as something other than CVE-2017-11735 if a new report is issued instead of just updating the existing one. Best, Ron
