Created attachment 171224 [details] Upstream patch for issue Open for tracking. Upstream patch attached.
A commit references this bug: Author: junovitch Date: Thu Jun 9 03:27:56 UTC 2016 New revision: 416579 URL: https://svnweb.freebsd.org/changeset/ports/416579 Log: textproc/expat2: address two CVEs reported by upstream PR: 210155 Reported by: Sebastian Pipping <sebastian@pipping.org> Approved by: ports-secteam (with hat) Security: CVE-2012-6702 Security: CVE-2016-5300 Security: https://vuxml.FreeBSD.org/freebsd/c9c252f5-2def-11e6-ae88-002590263bf5.html MFH: 2016Q2 Changes: head/textproc/expat2/Makefile head/textproc/expat2/files/patch-cve-2012-6702-plus-cve-2016-5300-v1
A commit references this bug: Author: junovitch Date: Thu Jun 9 03:28:07 UTC 2016 New revision: 416580 URL: https://svnweb.freebsd.org/changeset/ports/416580 Log: Document two expat CVEs reported by upstream PR: 210155 Reported by: Sebastian Pipping <sebastian@pipping.org> Security: CVE-2012-6702 Security: CVE-2016-5300 Security: https://vuxml.FreeBSD.org/freebsd/c9c252f5-2def-11e6-ae88-002590263bf5.html Changes: head/security/vuxml/vuln.xml
A commit references this bug: Author: junovitch Date: Thu Jun 9 03:28:49 UTC 2016 New revision: 416581 URL: https://svnweb.freebsd.org/changeset/ports/416581 Log: MFH: r416579 textproc/expat2: address two CVEs reported by upstream PR: 210155 Reported by: Sebastian Pipping <sebastian@pipping.org> Approved by: ports-secteam (with hat) Security: CVE-2012-6702 Security: CVE-2016-5300 Security: https://vuxml.FreeBSD.org/freebsd/c9c252f5-2def-11e6-ae88-002590263bf5.html Changes: _U branches/2016Q2/ branches/2016Q2/textproc/expat2/Makefile branches/2016Q2/textproc/expat2/files/patch-cve-2012-6702-plus-cve-2016-5300-v1
Fix title. Assign under emulation@ now to check status of Linux packages impacted and add ports-secteam@ on CC for followup.
A commit references this bug: Author: junovitch Date: Thu Jun 9 03:39:24 UTC 2016 New revision: 416582 URL: https://svnweb.freebsd.org/changeset/ports/416582 Log: Fill in <freebsdpr> tag on last entry; I staged it prior to opening the PR for tracking and forgot to fill it in pre-commit. PR: 210155 Changes: head/security/vuxml/vuln.xml
Fedora10 ports are End of Life, so there'll never be an update. Marking them insecure in vuln.xml is the best we can do. CentOS 6 ports are currently in Limbo as CentOS has released 6.8. I do not have the desire (nor time) to port that one, maybe if bofh@ or dchagin@ are interested :-) we can move this forward.
I'm still seeing "under investigation" at https://access.redhat.com/security/cve/CVE-2016-5300 so even with CentOS 6.8 in as of r417169 this is a vulnerable version. I think we are on hold for the moment.
A commit references this bug: Author: tijl Date: Sun Nov 6 13:34:17 UTC 2016 New revision: 425491 URL: https://svnweb.freebsd.org/changeset/ports/425491 Log: Undocument linux-*-expat vulnerabilities. linux-*-expat is only used by linux-*-fontconfig to read configuration files written in XML and by dbus-binding-tool(1) from linux-*-dbus-glib, a development tool that generates C code from an Introspection XML file to expose a GObject via D-Bus. These vulnerabilities are therefore not believed to be exploitable on FreeBSD and only cause annoying warnings and prevent installation of linux-*-expat. It also does not look like Red Hat will provide fixes for these any time soon. PR: 210155 Changes: head/security/vuxml/vuln.xml
Is undocumenting a vulnerability like this the right thing to do? There's nothing to say a 3rd party linux package doesn't need linux expat and might use it in a way that triggers the vulnerability.
(In reply to John Hein from comment #9) It's certainly not ideal, but currently the vulnerability checking mechanism in the ports tree is overzealous and blocks installation of vulnerable ports unless people set DISABLE_VULNERABILITIES. After complaints from users I considered this blocking to be worse than the vulnerabilities. Recently Red Hat released a fix for one of the vulnerabilities so that one has been documented again.
Ok. Maybe requiring DISABLE_VULNERABILITIES isn't bad. It's not unreasonable to force people to think twice and explicitly set a knob before installing a potentially vulnerable port. Maybe the vulnerability warning should grow an option to prompt the user to continue building anyway. Anyway, I understand your position. I just didn't want to see us head too far down the slippery slope of ignoring vulnerabilities because they are inconvenient.