CVE-2017-11577 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-11577): FontForge 20161012 is vulnerable to a buffer over-read in getsid (parsettf.c) resulting in DoS or code execution via a crafted otf file. CVE-2017-11576 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-11576): FontForge 20161012 does not ensure a positive size in a weight vector memcpy call in readcfftopdict (parsettf.c) resulting in DoS via a crafted otf file. CVE-2017-11575 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-11575): FontForge 20161012 is vulnerable to a buffer over-read in strnmatch (char.c) resulting in DoS or code execution via a crafted otf file, related to a call from the readttfcopyrights function in parsettf.c. CVE-2017-11574 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-11574): FontForge 20161012 is vulnerable to a heap-based buffer overflow in readcffset (parsettf.c) resulting in DoS or code execution via a crafted otf file. CVE-2017-11573 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-11573): FontForge 20161012 is vulnerable to a buffer over-read in ValidatePostScriptFontName (parsettf.c) resulting in DoS or code execution via a crafted otf file. CVE-2017-11572 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-11572): FontForge 20161012 is vulnerable to a heap-based buffer over-read in readcfftopdicts (parsettf.c) resulting in DoS or code execution via a crafted otf file. CVE-2017-11571 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-11571): FontForge 20161012 is vulnerable to a stack-based buffer overflow in addnibble (parsettf.c) resulting in DoS or code execution via a crafted otf file. CVE-2017-11570 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-11570): FontForge 20161012 is vulnerable to a buffer over-read in umodenc (parsettf.c) resulting in DoS or code execution via a crafted otf file. CVE-2017-11569 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-11569): FontForge 20161012 is vulnerable to a heap-based buffer over-read in readttfcopyrights (parsettf.c) resulting in DoS or code execution via a crafted otf file. CVE-2017-11568 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-11568): FontForge 20161012 is vulnerable to a heap-based buffer over-read in PSCharStringToSplines (psread.c) resulting in DoS or code execution via a crafted otf file.
I think these are resolved in fontforge-20170731. We should be all set to stabilize that version.
(In reply to Mike Gilbert from comment #1) > I think these are resolved in fontforge-20170731. We should be all set to > stabilize that version. Awesome, @Arches please test and mark stable
According to the github issue in URL (thanks!), most of the CVEs have been addressed, but there are a couple that have not been. Anyway, it is certainly worth stabilizing the current version regardless.
Stable on amd64
x86 stable
hppa stable
ia64 stable
ppc stable
ppc64 stable
Stable on alpha.
@ Maintainer(s): Stabilization is complete, please clean the vulnerable versions from the tree. @ Security: Please vote on glsa.
GLSA Vote: No
I suggest creating a new bug report for CVE-2017-11570 and CVE-2017-11573. These issues have NOT been fixed upstream, and are therefore not fixed in fontforge-20170731 in Gentoo.
(In reply to Mike Gilbert from comment #13) > I suggest creating a new bug report for CVE-2017-11570 and CVE-2017-11573. > > These issues have NOT been fixed upstream, and are therefore not fixed in > fontforge-20170731 in Gentoo. Thank you Mike, bug 637136 will handle those two CVEs
> @ Maintainer(s): Stabilization is complete, please clean the vulnerable versions from the tree. This is false; ARM has yet to mark the package stable.
Oh, I see that ARM is not "supported". Regardless, I cannot cleanup old versions without triggering a repoman error since ARM has stable profiles defined. This policy mismatch seems pretty retarded to me.
I de-keyworded 20160404 for everything but arm and stable. It would be helpful if you would update your boiler-plate cleanup text to include a warning that not all "stable" arches have been stabilized. This would help prevent tree breakage when maintainers assume that "stabilization is complete" actually means "complete" and not "done for the arches that security cares about".
(In reply to Mike Gilbert from comment #17) > I de-keyworded 20160404 for everything but arm and stable. > > It would be helpful if you would update your boiler-plate cleanup text to > include a warning that not all "stable" arches have been stabilized. > > This would help prevent tree breakage when maintainers assume that > "stabilization is complete" actually means "complete" and not "done for the > arches that security cares about". arm and sparc should have stayed in this bug as a STABLEREQ. If the maintainer decided to remove the vulnerable without their stabilization then that is on them. It is not that we do not care about that arch, but that arch has either taken to long or is not supported. You can see this across many bugs that are out there. I apologize that this was handled in such a way. Thank you for taking the appropriate action to secure the other arches.
(In reply to Aaron Bauman from comment #18) > arm and sparc should have stayed in this bug as a STABLEREQ. If the > maintainer decided to remove the vulnerable without their stabilization then > that is on them. It is not that we do not care about that arch, but that > arch has either taken to long or is not supported. I removed the vulnerable versions because comment 11 said "stabilization complete". I had to revert this to fix repoman. I then created a separate bug for arm and sparc because I was afraid the security team would mark this bug RESOLVED without arm and sparc being finished. Arch teams don't look at RESOLVED bugs.
(In reply to Mike Gilbert from comment #19) > (In reply to Aaron Bauman from comment #18) > > arm and sparc should have stayed in this bug as a STABLEREQ. If the > > maintainer decided to remove the vulnerable without their stabilization then > > that is on them. It is not that we do not care about that arch, but that > > arch has either taken to long or is not supported. > > I removed the vulnerable versions because comment 11 said "stabilization > complete". I had to revert this to fix repoman. > > I then created a separate bug for arm and sparc because I was afraid the > security team would mark this bug RESOLVED without arm and sparc being > finished. Arch teams don't look at RESOLVED bugs. All arches have the fixed version stable now. @maintainer, can it be cleaned now?
Cleaned!
(In reply to Mike Gilbert from comment #21) > Cleaned! Thanks, Mike!
