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

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

There is a new 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: 5717 bytes --]

From 71820d31151b697598645c7de8991074578ad357 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-2018-20030.patch | 115 +++++++++++++++++++
 srcpkgs/libexif/template                     |   2 +-
 2 files changed, 116 insertions(+), 1 deletion(-)
 create mode 100644 srcpkgs/libexif/patches/CVE-2018-20030.patch

diff --git a/srcpkgs/libexif/patches/CVE-2018-20030.patch b/srcpkgs/libexif/patches/CVE-2018-20030.patch
new file mode 100644
index 00000000000..58afe69b4e8
--- /dev/null
+++ b/srcpkgs/libexif/patches/CVE-2018-20030.patch
@@ -0,0 +1,115 @@
+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/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..cfc458720cf 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"

             reply index

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-11  1:44 voidlinux-github [this message]
2019-11-11  2:15 ` [PR PATCH] [Updated] " voidlinux-github
2019-11-11  5:57 ` 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=gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-16345@inbox.vuxu.org \
    --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