Re: CVE-2017-11735 in mp3split / libvorbis
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
Reply to: