[OpenWrt-Devel] [PATCH] bzip2: Fix CVE-2019-12900

[Rosen Penev]

On Sun, Sep 1, 2019 at 11:34 AM Josef Schlehofer
<pepe.schlehofer at gmail.com> wrote:
>
> More details about this CVE:
> https://nvd.nist.gov/vuln/detail/CVE-2019-12900
>
> Signed-off-by: Josef Schlehofer <pepe.schlehofer at gmail.com>
> ---
This is for 18.06. Usually notes like that are placed here below the --- line.
>  package/utils/bzip2/Makefile                  |  2 +-
>  .../bzip2/patches/020-CVE-2019-12900.patch    | 65 +++++++++++++++++++
>  2 files changed, 66 insertions(+), 1 deletion(-)
>  create mode 100644 package/utils/bzip2/patches/020-CVE-2019-12900.patch
>
> diff --git a/package/utils/bzip2/Makefile b/package/utils/bzip2/Makefile
> index ea2fc76833..0bf168c229 100644
> --- a/package/utils/bzip2/Makefile
> +++ b/package/utils/bzip2/Makefile
> @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
>
>  PKG_NAME:=bzip2
>  PKG_VERSION:=1.0.6
> -PKG_RELEASE:=4
> +PKG_RELEASE:=5
>
>  PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
>  PKG_SOURCE_URL:=http://www.bzip.org/$(PKG_VERSION)
> diff --git a/package/utils/bzip2/patches/020-CVE-2019-12900.patch b/package/utils/bzip2/patches/020-CVE-2019-12900.patch
> new file mode 100644
> index 0000000000..3f08c789ea
> --- /dev/null
> +++ b/package/utils/bzip2/patches/020-CVE-2019-12900.patch
> @@ -0,0 +1,65 @@
> +From 812a898b7622de90e98f103ff7fed0984e4548e4 Mon Sep 17 00:00:00 2001
> +From: Mark Wielaard <mark at klomp.org>
> +Date: Wed, 3 Jul 2019 01:28:11 +0200
> +Subject: [PATCH] Accept as many selectors as the file format allows.
> +
> +But ignore any larger than the theoretical maximum, BZ_MAX_SELECTORS.
> +
> +The theoretical maximum number of selectors depends on the maximum
> +blocksize (900000 bytes) and the number of symbols (50) that can be
> +encoded with a different Huffman tree. BZ_MAX_SELECTORS is 18002.
> +
> +But the bzip2 file format allows the number of selectors to be encoded
> +with 15 bits (because 18002 isn't a factor of 2 and doesn't fit in
> +14 bits). So the file format maximum is 32767 selectors.
> +
> +Some bzip2 encoders might actually have written out more selectors
> +than the theoretical maximum because they rounded up the number of
> +selectors to some convenient factor of 8.
> +
> +The extra 14766 selectors can never be validly used by the decompression
> +algorithm. So we can read them, but then discard them.
> +
> +This is effectively what was done (by accident) before we added a
> +check for nSelectors to be at most BZ_MAX_SELECTORS to mitigate
> +CVE-2019-12900.
> +
> +The extra selectors were written out after the array inside the
> +EState struct. But the struct has extra space allocated after the
> +selector arrays of 18060 bytes (which is larger than 14766).
> +All of which will be initialized later (so the overwrite of that
> +space with extra selector values would have been harmless).
> +---
> + compress.c   |  2 +-
> + decompress.c | 10 +++++++-
> + 2 files changed, 8 insertions(+), 2 deletions(-)
> +
> +--- a/compress.c
> ++++ b/compress.c
> +@@ -454,7 +454,7 @@ void sendMTFValues ( EState* s )
> +
> +    AssertH( nGroups < 8, 3002 );
> +    AssertH( nSelectors < 32768 &&
> +-            nSelectors <= (2 + (900000 / BZ_G_SIZE)),
> ++            nSelectors <= BZ_MAX_SELECTORS,
> +             3003 );
> +
> +
> +--- a/decompress.c
> ++++ b/decompress.c
> +@@ -296,8 +296,14 @@ Int32 BZ2_decompress ( DState* s )
> +             j++;
> +             if (j >= nGroups) RETURN(BZ_DATA_ERROR);
> +          }
> +-         s->selectorMtf[i] = j;
> ++         /* Having more than BZ_MAX_SELECTORS doesn't make much sense
> ++            since they will never be used, but some implementations might
> ++            "round up" the number of selectors, so just ignore those. */
> ++         if (i < BZ_MAX_SELECTORS)
> ++           s->selectorMtf[i] = j;
> +       }
> ++      if (nSelectors > BZ_MAX_SELECTORS)
> ++        nSelectors = BZ_MAX_SELECTORS;
> +
> +       /*--- Undo the MTF values for the selectors. ---*/
> +       {
> --
> 2.20.1
>
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel