Github messages for voidlinux
 help / color / Atom feed
From: voidlinux-github@inbox.vuxu.org
To: ml@inbox.vuxu.org
Subject: Re: [PR PATCH] [Updated] libexif: fix CVE-2018-20030.
Date: Mon, 11 Nov 2019 03:15:08 +0100
Message-ID: <20191111021508.S6S7ToCywP75bj-ewgrNXwUDn9YxrAnld9gqgV6wsXE@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-16345@inbox.vuxu.org>

[-- Attachment #1: Type: text/plain, Size: 326 bytes --]

There is an updated pull request by travankor against master on the void-packages repository

https://github.com/travankor/void-packages libexif
https://github.com/void-linux/void-packages/pull/16345

libexif: fix CVE-2018-20030.
None

A patch file from https://github.com/void-linux/void-packages/pull/16345.patch is attached

[-- Warning: decoded text below may be mangled --]
[-- Attachment #2: github-pr-libexif-16345.patch --]
[-- Type: text/x-diff, Size: 7732 bytes --]

From f1fcbfc931e8401d7bb480a28aa10df6104a9074 Mon Sep 17 00:00:00 2001
From: travankor <travankor@tuta.io>
Date: Sun, 10 Nov 2019 18:43:22 -0700
Subject: [PATCH] libexif: fix CVE-2018-20030.

---
 srcpkgs/libexif/patches/CVE-2017-7544.patch  |  22 +++-
 srcpkgs/libexif/patches/CVE-2018-20030.patch | 127 +++++++++++++++++++
 srcpkgs/libexif/template                     |   3 +-
 3 files changed, 147 insertions(+), 5 deletions(-)
 create mode 100644 srcpkgs/libexif/patches/CVE-2018-20030.patch

diff --git a/srcpkgs/libexif/patches/CVE-2017-7544.patch b/srcpkgs/libexif/patches/CVE-2017-7544.patch
index 7e2fb121291..cad85cc4b12 100644
--- a/srcpkgs/libexif/patches/CVE-2017-7544.patch
+++ b/srcpkgs/libexif/patches/CVE-2017-7544.patch
@@ -1,6 +1,21 @@
---- libexif/exif-data.c	12 Jul 2012 17:28:26 -0000	1.131
-+++ libexif/exif-data.c	25 Jul 2017 21:34:06 -0000
-@@ -255,6 +255,12 @@
+From c39acd1692023b26290778a02a9232c873f9d71a Mon Sep 17 00:00:00 2001
+From: Marcus Meissner <marcus@jet.franken.de>
+Date: Tue, 25 Jul 2017 23:38:56 +0200
+Subject: [PATCH] On saving makernotes, make sure the makernote container tags
+ has a type with 1 byte components.
+
+Fixes (at least):
+	https://sourceforge.net/p/libexif/bugs/130
+	https://sourceforge.net/p/libexif/bugs/129
+---
+ libexif/exif-data.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/libexif/exif-data.c b/libexif/exif-data.c
+index 67df4db..91f4c33 100644
+--- a/libexif/exif-data.c
++++ b/libexif/exif-data.c
+@@ -255,6 +255,12 @@ exif_data_save_data_entry (ExifData *data, ExifEntry *e,
  			exif_mnote_data_set_offset (data->priv->md, *ds - 6);
  			exif_mnote_data_save (data->priv->md, &e->data, &e->size);
  			e->components = e->size;
@@ -12,4 +27,3 @@
 +			}
  		}
  	}
- 
diff --git a/srcpkgs/libexif/patches/CVE-2018-20030.patch b/srcpkgs/libexif/patches/CVE-2018-20030.patch
new file mode 100644
index 00000000000..ee7a6df123d
--- /dev/null
+++ b/srcpkgs/libexif/patches/CVE-2018-20030.patch
@@ -0,0 +1,127 @@
+From 6aa11df549114ebda520dde4cdaea2f9357b2c89 Mon Sep 17 00:00:00 2001
+From: Dan Fandrich <dan@coneharvesters.com>
+Date: Fri, 12 Oct 2018 16:01:45 +0200
+Subject: [PATCH] Improve deep recursion detection in
+ exif_data_load_data_content.
+
+The existing detection was still vulnerable to pathological cases
+causing DoS by wasting CPU. The new algorithm takes the number of tags
+into account to make it harder to abuse by cases using shallow recursion
+but with a very large number of tags.  This improves on commit 5d28011c
+which wasn't sufficient to counter this kind of case.
+
+The limitation in the previous fix was discovered by Laurent Delosieres,
+Secunia Research at Flexera (Secunia Advisory SA84652) and is assigned
+the identifier CVE-2018-20030.
+---
+ NEWS                |  1 +
+ libexif/exif-data.c | 45 +++++++++++++++++++++++++++++++++++++--------
+ 2 files changed, 38 insertions(+), 8 deletions(-)
+
+diff --git a/NEWS b/NEWS
+index b98e718..f1528c1 100644
+--- a/NEWS
++++ b/NEWS
+@@ -3,6 +3,7 @@ libexif-0.6.x:
+   * Updated translations for most languages
+   * Fixed C89 compatibility
+   * Fixed warnings on recent versions of autoconf
++  * Fix for recursion DoS CVE-2018-20030
+ 
+ libexif-0.6.21 (2012-07-12):
+   * New translations: en_AU, uk
+diff --git a/libexif/exif-data.c b/libexif/exif-data.c
+index e35403d..a6f9c94 100644
+--- a/libexif/exif-data.c
++++ b/libexif/exif-data.c
+@@ -35,6 +35,7 @@
+ #include <libexif/olympus/exif-mnote-data-olympus.h>
+ #include <libexif/pentax/exif-mnote-data-pentax.h>
+ 
++#include <math.h>
+ #include <stdlib.h>
+ #include <stdio.h>
+ #include <string.h>
+@@ -350,6 +351,20 @@ if (data->ifd[(i)]->count) {				\
+ 	break;						\
+ }
+ 
++/*! Calculate the recursion cost added by one level of IFD loading.
++ *
++ * The work performed is related to the cost in the exponential relation
++ *   work=1.1**cost
++ */
++static unsigned int
++level_cost(unsigned int n)
++{
++    static const double log_1_1 = 0.09531017980432493;
++
++	/* Adding 0.1 protects against the case where n==1 */
++	return ceil(log(n + 0.1)/log_1_1);
++}
++
+ /*! Load data for an IFD.
+  *
+  * \param[in,out] data #ExifData
+@@ -357,13 +372,13 @@ if (data->ifd[(i)]->count) {				\
+  * \param[in] d pointer to buffer containing raw IFD data
+  * \param[in] ds size of raw data in buffer at \c d
+  * \param[in] offset offset into buffer at \c d at which IFD starts
+- * \param[in] recursion_depth number of times this function has been
+- * recursively called without returning
++ * \param[in] recursion_cost factor indicating how expensive this recursive
++ * call could be
+  */
+ static void
+ exif_data_load_data_content (ExifData *data, ExifIfd ifd,
+ 			     const unsigned char *d,
+-			     unsigned int ds, unsigned int offset, unsigned int recursion_depth)
++			     unsigned int ds, unsigned int offset, unsigned int recursion_cost)
+ {
+ 	ExifLong o, thumbnail_offset = 0, thumbnail_length = 0;
+ 	ExifShort n;
+@@ -378,9 +393,20 @@ exif_data_load_data_content (ExifData *data, ExifIfd ifd,
+ 	if ((((int)ifd) < 0) || ( ((int)ifd) >= EXIF_IFD_COUNT))
+ 	  return;
+ 
+-	if (recursion_depth > 30) {
++	if (recursion_cost > 170) {
++		/*
++		 * recursion_cost is a logarithmic-scale indicator of how expensive this
++		 * recursive call might end up being. It is an indicator of the depth of
++		 * recursion as well as the potential for worst-case future recursive
++		 * calls. Since it's difficult to tell ahead of time how often recursion
++		 * will occur, this assumes the worst by assuming every tag could end up
++		 * causing recursion.
++		 * The value of 170 was chosen to limit typical EXIF structures to a
++		 * recursive depth of about 6, but pathological ones (those with very
++		 * many tags) to only 2.
++		 */
+ 		exif_log (data->priv->log, EXIF_LOG_CODE_CORRUPT_DATA, "ExifData",
+-			  "Deep recursion detected!");
++			  "Deep/expensive recursion detected!");
+ 		return;
+ 	}
+ 
+@@ -422,15 +448,18 @@ exif_data_load_data_content (ExifData *data, ExifIfd ifd,
+ 			switch (tag) {
+ 			case EXIF_TAG_EXIF_IFD_POINTER:
+ 				CHECK_REC (EXIF_IFD_EXIF);
+-				exif_data_load_data_content (data, EXIF_IFD_EXIF, d, ds, o, recursion_depth + 1);
++				exif_data_load_data_content (data, EXIF_IFD_EXIF, d, ds, o,
++					recursion_cost + level_cost(n));
+ 				break;
+ 			case EXIF_TAG_GPS_INFO_IFD_POINTER:
+ 				CHECK_REC (EXIF_IFD_GPS);
+-				exif_data_load_data_content (data, EXIF_IFD_GPS, d, ds, o, recursion_depth + 1);
++				exif_data_load_data_content (data, EXIF_IFD_GPS, d, ds, o,
++					recursion_cost + level_cost(n));
+ 				break;
+ 			case EXIF_TAG_INTEROPERABILITY_IFD_POINTER:
+ 				CHECK_REC (EXIF_IFD_INTEROPERABILITY);
+-				exif_data_load_data_content (data, EXIF_IFD_INTEROPERABILITY, d, ds, o, recursion_depth + 1);
++				exif_data_load_data_content (data, EXIF_IFD_INTEROPERABILITY, d, ds, o,
++					recursion_cost + level_cost(n));
+ 				break;
+ 			case EXIF_TAG_JPEG_INTERCHANGE_FORMAT:
+ 				thumbnail_offset = o;
diff --git a/srcpkgs/libexif/template b/srcpkgs/libexif/template
index f8898968101..a66fdcb4b2d 100644
--- a/srcpkgs/libexif/template
+++ b/srcpkgs/libexif/template
@@ -1,7 +1,7 @@
 # Template file for 'libexif'
 pkgname=libexif
 version=0.6.21
-revision=5
+revision=6
 build_style=gnu-configure
 configure_args="ac_cv_path_DOXYGEN=false"
 short_desc="EXIF file library"
@@ -10,6 +10,7 @@ license="LGPL-2.1-or-later"
 homepage="http://sourceforge.net/projects/libexif"
 distfiles="${SOURCEFORGE_SITE}/${pkgname}/${pkgname}-${version}.tar.bz2"
 checksum=16cdaeb62eb3e6dfab2435f7d7bccd2f37438d21c5218ec4e58efa9157d4d41a
+patch_args="-Np1"
 
 libexif-devel_package() {
 	depends="${sourcepkg}>=${version}_${revision}"

  reply index

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-11  1:44 [PR PATCH] " voidlinux-github
2019-11-11  2:15 ` voidlinux-github [this message]
2019-11-11  5:57 ` [PR PATCH] [Updated] " voidlinux-github
2019-11-11 18:54 ` [PR PATCH] [Merged]: " voidlinux-github

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191111021508.S6S7ToCywP75bj-ewgrNXwUDn9YxrAnld9gqgV6wsXE@z \
    --to=voidlinux-github@inbox.vuxu.org \
    --cc=ml@inbox.vuxu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Github messages for voidlinux

Archives are clonable: git clone --mirror http://inbox.vuxu.org/voidlinux-github

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.github.voidlinux


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git