Re: CVE-2017-11735 in mp3split / libvorbis
Hi Ron,
On Sun, Oct 01, 2017 at 06:53:51AM +1030, Ron wrote:
> 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.
I've added a link to your patch here:
https://gitlab.xiph.org/xiph/vorbis/issues/2331
and I'll check with Salvatore if it's appropriate to inform oss-security
once we got a new CVE for mp3splt.
Thanks for detailed response (and the patch)!
-- Guido
>
>
> 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
>
>
Reply to: