Date: Sun, 22 Oct 2017 16:05:05 +0200 From: Matthias Andree <mandree@FreeBSD.org> To: amdmi3@FreeBSD.org, danfe@FreeBSD.org, danilo@FreeBSD.org, dumbbell@FreeBSD.org, ehaupt@FreeBSD.org, FreeBSD@Shaneware.biz, gnome@FreeBSD.org, grog@FreeBSD.org, h2+fbsdports@fsfe.org, jamesb-bsd@excamera.com, kde@FreeBSD.org, multimedia@FreeBSD.org, rm@FreeBSD.org, thierry@FreeBSD.org, woodsb02@FreeBSD.org Cc: ports-secteam <ports-secteam@freebsd.org> Subject: HEADS UP: OpenEXR vulnerability and deprecation, call for assistance/input Message-ID: <e967451e-bba7-c2f2-023a-2a886825b9c5@FreeBSD.org>
next in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --f9JNETiC5HRQoOgMa7p9dL8VwSCRO42wi Content-Type: multipart/mixed; boundary="VtkLlNDcJED3oaW2Kj1mQRvLbG0aAPUX3"; protected-headers="v1" From: Matthias Andree <mandree@FreeBSD.org> To: amdmi3@FreeBSD.org, danfe@FreeBSD.org, danilo@FreeBSD.org, dumbbell@FreeBSD.org, ehaupt@FreeBSD.org, FreeBSD@Shaneware.biz, gnome@FreeBSD.org, grog@FreeBSD.org, h2+fbsdports@fsfe.org, jamesb-bsd@excamera.com, kde@FreeBSD.org, multimedia@FreeBSD.org, rm@FreeBSD.org, thierry@FreeBSD.org, woodsb02@FreeBSD.org Cc: ports-secteam <ports-secteam@freebsd.org> Message-ID: <e967451e-bba7-c2f2-023a-2a886825b9c5@FreeBSD.org> Subject: HEADS UP: OpenEXR vulnerability and deprecation, call for assistance/input --VtkLlNDcJED3oaW2Kj1mQRvLbG0aAPUX3 Content-Type: text/plain; charset=utf-8 Content-Language: de-DE Content-Transfer-Encoding: quoted-printable Greetings, [not yet Cc:d to ports@] I am the graphics/OpenEXR maintainer, and as some of you may already know, OpenEXR has been vulnerable for quite a while, including "execute arbitrary code" attacks. I don't have patches I dare apply, so OpenEXR is currently marked vulnerable and I intend to tighten things up and mark FORBIDDEN soon. Tech high-level detail, I wrote, in <http://vuxml.freebsd.org/freebsd/803879e9-4195-11e7-9b08-080027ef73ec.ht= ml>: > Brandon Perry reports: >=20 > [There] is a zip file of EXR images that cause segmentation faults in t= he OpenEXR library (tested against 2.2.0). >=20 > CVE-2017-9110 In OpenEXR 2.2.0, an invalid read of size 2 in the hufDec= ode function in ImfHuf.cpp could cause the application to crash. > CVE-2017-9111 In OpenEXR 2.2.0, an invalid write of size 8 in the store= SSE function in ImfOptimizedPixelReading.h could cause the application to= crash or execute arbitrary code. > CVE-2017-9112 In OpenEXR 2.2.0, an invalid read of size 1 in the getBit= s function in ImfHuf.cpp could cause the application to crash. > CVE-2017-9113 In OpenEXR 2.2.0, an invalid write of size 1 in the buffe= redReadPixels function in ImfInputFile.cpp could cause the application to= crash or execute arbitrary code. > CVE-2017-9114 In OpenEXR 2.2.0, an invalid read of size 1 in the refill= function in ImfFastHuf.cpp could cause the application to crash. > CVE-2017-9115 In OpenEXR 2.2.0, an invalid write of size 2 in the =3D o= perator function in half.h could cause the application to crash or execut= e arbitrary code. > CVE-2017-9116 In OpenEXR 2.2.0, an invalid read of size 1 in the uncomp= ress function in ImfZip.cpp could cause the application to crash. The upstream has been informed [1], and there is a proposed unreviewed patch[2], but the upstream hasn't yet accepted responsibility, only responded in a non-constructive way that patch, asking for a contributors license agreement and adjourning to later "see what we can do" or something, to which the contributor of the fixes answered he's not doing any further work for lack of progress.[2] [1]: <https://github.com/openexr/openexr/issues/232>; [2]: <https://github.com/openexr/openexr/pull/233>; Bottom line, to me, OpenEXR looks abandonware and we need to prepare for getting rid of it, but I don't want to pull the rug from underneath your feet without advance warning. I have written to Ed Hanway of IL&M today to ask about the support status, and have recently committed a DEPRECATED with an EXPIRATION_TIME of EOY which I am willing to extend to 2018-03-31 for any straw or halfway reasonable cause that either of you is going to present, after which I suggest we nuke OpenEXR support in the ports tree for good, and I intend to mark the port FORBIDDEN soon enough. How should we proceed? - are all of your ports good without OpenEXR, and support, for instance, 16-bit TIFF? - are there OpenEXR alternatives that your ports could use and that we could move - is either of your ports dependent on OpenEXR to be useful? - is anyone aware of another vendor auditing patches or actively distributing patches for OpenEXR, or a patched version, that they are supporting, and that we could rely on? I am loathe to use unaudited third party patches. This is a list generated from http://freshports.org/graphics/OpenEXR, sorted by maintainer - to me this appears to be the list of maintainer/port_origin pairs of ports that require OpenEXR by default. Thanks for your time. Regards, Matthias > FreeBSD@Shaneware.biz: graphics/blender > FreeBSD@Shaneware.biz: graphics/openimageio > FreeBSD@Shaneware.biz: graphics/openshadinglanguage > FreeBSD@Shaneware.biz: graphics/py-openimageio > amdmi3@FreeBSD.org: graphics/nvidia-texture-tools > danfe@FreeBSD.org: graphics/appleseed > danfe@FreeBSD.org: graphics/hdr_tools > danfe@FreeBSD.org: graphics/mitsuba > danilo@FreeBSD.org: graphics/vips > dumbbell@FreeBSD.org: graphics/darktable > ehaupt@FreeBSD.org: graphics/exrtools > gnome@FreeBSD.org: graphics/gegl > gnome@FreeBSD.org: graphics/gegl3 > grog@FreeBSD.org: graphics/enblend > grog@FreeBSD.org: graphics/hugin > h2+fbsdports@fsfe.org: graphics/luminance > h2+fbsdports@fsfe.org: graphics/luminance-qt5 > jamesb-bsd@excamera.com: graphics/py-openexr > kde@FreeBSD.org: editors/calligra > kde@FreeBSD.org: graphics/kf5-kimageformats > kde@FreeBSD.org: graphics/krita > kde@FreeBSD.org: x11/kde4-runtime > kde@FreeBSD.org: x11/kdelibs4 > multimedia@FreeBSD.org: graphics/gstreamer1-plugins-openexr > ports@FreeBSD.org: graphics/ampasCTL > ports@FreeBSD.org: graphics/aqsis > ports@FreeBSD.org: graphics/cinepaint > ports@FreeBSD.org: graphics/exact-image > ports@FreeBSD.org: graphics/fyre > ports@FreeBSD.org: graphics/pixie > ports@FreeBSD.org: graphics/simpleviewer > ports@FreeBSD.org: graphics/vigra > ports@FreeBSD.org: science/gwyddion > rm@FreeBSD.org: graphics/gimp-gmic-plugin > thierry@FreeBSD.org: graphics/cimg > woodsb02@FreeBSD.org: devel/synfig --VtkLlNDcJED3oaW2Kj1mQRvLbG0aAPUX3-- --f9JNETiC5HRQoOgMa7p9dL8VwSCRO42wi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZ7KWRAAoJEOQSsVbv84Vat9YQAJhoeAdIyc78IyRQ14EOil42 5PoTYlxi1jNQ/TD2pHzZp05CqN0V9LqPX58rgEh9zdy1A4v+UeoSLeZtUBX+rH1B iF/umzt2HmpG4FkTLbB+tTN9c1m1My/tlAF1vibwiyOpD5l7PsfxhwWlKLrV3Raq GPC1Uh3uxTH7/ynRK3ZHkH3LfRBlPJDIJnb8+S14W0isKd+gcJZL9Toto9vm06nO 4if+O4M+NgmSf0tkaA7g5M9U7qJ3UjEql3W1RhTtCO2retiqgTA9GuHfps9SeXiQ oAl1T1WyBTuzxYyGEGtmW8AUe+XUX6RsKnqqwa8/AngdKsTknOoUUPPJrexWJgWN mS5IzS2YwNskr4reFTBRIbn2dbViEBQJf5GykgrRtBTqh/lotkcdtXguycXJfA0C Yc4D1/YWN9abE5UU+BESP65zjciEZecOlnmVXKuBCXsDc64DmqQfJ1MnYw6gCmpY +nlj0ZxvhWdvLab98YJPYQ28efKPXVuaeMxii7NP+MWP+++fRfl35pPMms2VeFc7 lmnkGr2Zc4QfSrxPiTWqdCiyDAvgIWmN/sdAcC6pMFErKU8T2zNOq0+mv7HOE9um BTZ7bU93ljkt6DAQofWXMLb1jJaJPC2h+OmoYsJ6CWn/cbdB2nyRNuwTur8iMmzp dHEWNJd0uFCRKaKxjcFd =IDQ7 -----END PGP SIGNATURE----- --f9JNETiC5HRQoOgMa7p9dL8VwSCRO42wi--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e967451e-bba7-c2f2-023a-2a886825b9c5>