Bug#776086: vorbis-tools: CVE-2014-9638 CVE-2014-9639 CVE-2014-9640

[Salvatore Bonaccorso]

Hi Martin,

On Sun, Jan 25, 2015 at 06:35:14PM +0100, Martin Steghöfer wrote:
> retitle 776086 CVE-2014-9638 CVE-2014-9639
> thanks
> 
> 
> Dear Salvatore,
> 
> thank you for reporting this!
> 
> 
> Salvatore Bonaccorso wrote:
> >CVE-2014-9638[0]:
> >Oggenc division by zero issue
> 
> Confirmed with 1.4.0-6 as well as with the current git head. There doesn't
> seem to be a fix yet, so I am going to look into it.
> 
> >CVE-2014-9639[1]:
> >Oggenc channel integer overflow
> 
> Confirmed with 1.4.0-6 as well as with the current git head. There doesn't
> seem to be a fix yet, so I am going to look into it.
> 
> >
> >CVE-2014-9640[2]:
> >segfault when trying to encode trivial raw input
> 
> This one is a duplicate of Debian bug #771363, which we fixed in December in
> version 1.4.0-6 (which made it into Jessie). No idea why the Debian security
> tracker lists 1.4.0-6 as vulnerable. This should be changed, but I don't
> know how.

Wooops, apologies I missed this! Btw, the tracker does not update the
information automatically, but is verified by team members and
updated. I just have adjusted the entry for CVE-2014-9640.

> Since it's classified as a security issue now, we should probably backport
> the fix to stable, shouldn't we?

My gut feeling is that the impact is low for these three issues
(unless I missed something). So no DSA on it's own is needed, but
actually would be great to see it fixed in stable as well through a
stable-proposed-update (maybe once fixes are also available for the
other two issues to include them). Do you agree on this conclusion,
and if yes, could you contact the release team for a fix through the
next stable point release?

https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable

> >If you fix the vulnerabilities please also make sure to include the
> >CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
> 
> Will do, at least for the remaining 2 issues. For CVE-2014-9640 there was no
> CVE identifier when we fixed it.

Yes that is fine (you can also adjust the entry for #771363 adding the
CVE retrospectively; but it is not strictly required).

Regards,
Salvatore