[Buildroot] [PATCH 1/2] package/gzip: security bump to 1.12

[Buildroot] [PATCH 1/2] package/gzip: security bump to 1.12

[Marcus Hoffmann]

Fixes the following security issues:

CVE-2022-1271: arbitrary-file-write vulnerability

zgrep applied to a crafted file name with two or more newlines
can no longer overwrite an arbitrary, attacker-selected file.
[bug introduced in gzip-1.3.10]

https://www.openwall.com/lists/oss-security/2022/04/07/8

Other changes:

** Changes in behavior

  'gzip -l' no longer misreports file lengths 4 GiB and larger.
  Previously, 'gzip -l' output the 32-bit value stored in the gzip
  header even though that is the uncompressed length modulo 2**32.
  Now, 'gzip -l' calculates the uncompressed length by decompressing
  the data and counting the resulting bytes.  Although this can take
  much more time, nowadays the correctness pros seem to outweigh the
  performance cons.

  'zless' is no longer installed on platforms lacking 'less'.

** Bug fixes

  zgrep now names input file on error instead of mislabeling it as
  "(standard input)", if grep supports the GNU -H and --label options.

  'zdiff -C 5' no longer misbehaves by treating '5' as a file name.
  [bug present since the beginning]

  Configure-time options like --program-prefix now work.

Release Announcement:
https://lists.gnu.org/r/bug-gzip/2022-04/msg00011.html

Signed-off-by: Marcus Hoffmann <marcus.hoffmann@othermo.de>
---
 package/gzip/gzip.hash | 4 ++--
 package/gzip/gzip.mk   | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/package/gzip/gzip.hash b/package/gzip/gzip.hash
index 1cf73ff912..80b86f4797 100644
--- a/package/gzip/gzip.hash
+++ b/package/gzip/gzip.hash
@@ -1,6 +1,6 @@
 # Locally calculated after checking pgp signature
-# https://ftp.gnu.org/gnu/gzip/gzip-1.11.tar.xz.sig
+# https://ftp.gnu.org/gnu/gzip/gzip-1.12.tar.xz.sig
 # using key 155D3FC500C834486D1EEA677FD9FCCB000BEEEE
-sha256  9b9a95d68fdcb936849a4d6fada8bf8686cddf58b9b26c9c4289ed0c92a77907  gzip-1.11.tar.xz
+sha256  ce5e03e519f637e1f814011ace35c4f87b33c0bbabeec35baf5fbd3479e91956  gzip-1.12.tar.xz
 # Locally calculated
 sha256  8ceb4b9ee5adedde47b31e975c1d90c73ad27b6b165a1dcd80c7c545eb65b903  COPYING
diff --git a/package/gzip/gzip.mk b/package/gzip/gzip.mk
index 92588fcdb8..2092df363c 100644
--- a/package/gzip/gzip.mk
+++ b/package/gzip/gzip.mk
@@ -4,7 +4,7 @@
 #
 ################################################################################
 
-GZIP_VERSION = 1.11
+GZIP_VERSION = 1.12
 GZIP_SOURCE = gzip-$(GZIP_VERSION).tar.xz
 GZIP_SITE = $(BR2_GNU_MIRROR)/gzip
 # Some other tools expect it to be in /bin
-- 
2.25.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 2/2] package/xz: backport CVE-2022-1271 security fix

[Marcus Hoffmann]

Fixes the following security issue:

CVE-2022-1271/ZDI-22-619/ZDI-CAN-16587: arbitrary-file-write vulnerability

Malicious filenames can make xzgrep to write to arbitrary files
or (with a GNU sed extension) lead to arbitrary code execution.

xzgrep from XZ Utils versions up to and including 5.2.5 are
affected. 5.3.1alpha and 5.3.2alpha are affected as well.
This patch works for all of them.

This bug was inherited from gzip's zgrep. gzip 1.12 includes
a fix for zgrep.

This vulnerability was discovered by:
cleemy desu wayo working with Trend Micro Zero Day Initiative

https://www.mail-archive.com/xz-devel@tukaani.org/msg00551.html
https://www.zerodayinitiative.com/advisories/ZDI-22-619/
https://www.openwall.com/lists/oss-security/2022/04/07/8
Signed-off-by: Marcus Hoffmann <marcus.hoffmann@othermo.de>
---
 package/xz/0001-xzgrep-ZDI-CAN-16587.patch | 96 ++++++++++++++++++++++
 1 file changed, 96 insertions(+)
 create mode 100644 package/xz/0001-xzgrep-ZDI-CAN-16587.patch

diff --git a/package/xz/0001-xzgrep-ZDI-CAN-16587.patch b/package/xz/0001-xzgrep-ZDI-CAN-16587.patch
new file mode 100644
index 0000000000..78ee9640f0
--- /dev/null
+++ b/package/xz/0001-xzgrep-ZDI-CAN-16587.patch
@@ -0,0 +1,96 @@
+From 69d1b3fc29677af8ade8dc15dba83f0589cb63d6 Mon Sep 17 00:00:00 2001
+From: Lasse Collin <lasse.collin@tukaani.org>
+Date: Tue, 29 Mar 2022 19:19:12 +0300
+Subject: [PATCH] xzgrep: Fix escaping of malicious filenames (ZDI-CAN-16587).
+
+Malicious filenames can make xzgrep to write to arbitrary files
+or (with a GNU sed extension) lead to arbitrary code execution.
+
+xzgrep from XZ Utils versions up to and including 5.2.5 are
+affected. 5.3.1alpha and 5.3.2alpha are affected as well.
+This patch works for all of them.
+
+This bug was inherited from gzip's zgrep. gzip 1.12 includes
+a fix for zgrep.
+
+The issue with the old sed script is that with multiple newlines,
+the N-command will read the second line of input, then the
+s-commands will be skipped because it's not the end of the
+file yet, then a new sed cycle starts and the pattern space
+is printed and emptied. So only the last line or two get escaped.
+
+One way to fix this would be to read all lines into the pattern
+space first. However, the included fix is even simpler: All lines
+except the last line get a backslash appended at the end. To ensure
+that shell command substitution doesn't eat a possible trailing
+newline, a colon is appended to the filename before escaping.
+The colon is later used to separate the filename from the grep
+output so it is fine to add it here instead of a few lines later.
+
+The old code also wasn't POSIX compliant as it used \n in the
+replacement section of the s-command. Using \<newline> is the
+POSIX compatible method.
+
+LC_ALL=C was added to the two critical sed commands. POSIX sed
+manual recommends it when using sed to manipulate pathnames
+because in other locales invalid multibyte sequences might
+cause issues with some sed implementations. In case of GNU sed,
+these particular sed scripts wouldn't have such problems but some
+other scripts could have, see:
+
+    info '(sed)Locale Considerations'
+
+This vulnerability was discovered by:
+cleemy desu wayo working with Trend Micro Zero Day Initiative
+
+Thanks to Jim Meyering and Paul Eggert discussing the different
+ways to fix this and for coordinating the patch release schedule
+with gzip.
+
+Signed-off-by: Marcus Hoffmann <marcus.hoffmann@othermo.de> 
+---
+ src/scripts/xzgrep.in | 20 ++++++++++++--------
+ 1 file changed, 12 insertions(+), 8 deletions(-)
+
+diff --git a/src/scripts/xzgrep.in b/src/scripts/xzgrep.in
+index b180936..e5186ba 100644
+--- a/src/scripts/xzgrep.in
++++ b/src/scripts/xzgrep.in
+@@ -180,22 +180,26 @@ for i; do
+          { test $# -eq 1 || test $no_filename -eq 1; }; then
+       eval "$grep"
+     else
++      # Append a colon so that the last character will never be a newline
++      # which would otherwise get lost in shell command substitution.
++      i="$i:"
++
++      # Escape & \ | and newlines only if such characters are present
++      # (speed optimization).
+       case $i in
+       (*'
+ '* | *'&'* | *'\'* | *'|'*)
+-        i=$(printf '%s\n' "$i" |
+-            sed '
+-              $!N
+-              $s/[&\|]/\\&/g
+-              $s/\n/\\n/g
+-            ');;
++        i=$(printf '%s\n' "$i" | LC_ALL=C sed 's/[&\|]/\\&/g; $!s/$/\\/');;
+       esac
+-      sed_script="s|^|$i:|"
++
++      # $i already ends with a colon so don't add it here.
++      sed_script="s|^|$i|"
+ 
+       # Fail if grep or sed fails.
+       r=$(
+         exec 4>&1
+-        (eval "$grep" 4>&-; echo $? >&4) 3>&- | sed "$sed_script" >&3 4>&-
++        (eval "$grep" 4>&-; echo $? >&4) 3>&- |
++            LC_ALL=C sed "$sed_script" >&3 4>&-
+       ) || r=2
+       exit $r
+     fi >&3 5>&-
+-- 
+2.35.1
+
-- 
2.25.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 2/2] package/xz: backport CVE-2022-1271 security fix

[Baruch Siach via buildroot]

Hi Marcus,

On Tue, Apr 19 2022, Marcus Hoffmann wrote:
> Fixes the following security issue:
>
> CVE-2022-1271/ZDI-22-619/ZDI-CAN-16587: arbitrary-file-write vulnerability
>
> Malicious filenames can make xzgrep to write to arbitrary files
> or (with a GNU sed extension) lead to arbitrary code execution.
>
> xzgrep from XZ Utils versions up to and including 5.2.5 are
> affected. 5.3.1alpha and 5.3.2alpha are affected as well.
> This patch works for all of them.
>
> This bug was inherited from gzip's zgrep. gzip 1.12 includes
> a fix for zgrep.
>
> This vulnerability was discovered by:
> cleemy desu wayo working with Trend Micro Zero Day Initiative
>
> https://www.mail-archive.com/xz-devel@tukaani.org/msg00551.html
> https://www.zerodayinitiative.com/advisories/ZDI-22-619/
> https://www.openwall.com/lists/oss-security/2022/04/07/8
> Signed-off-by: Marcus Hoffmann <marcus.hoffmann@othermo.de>
> ---
>  package/xz/0001-xzgrep-ZDI-CAN-16587.patch | 96 ++++++++++++++++++++++
>  1 file changed, 96 insertions(+)
>  create mode 100644 package/xz/0001-xzgrep-ZDI-CAN-16587.patch

This patch should also add XZ_IGNORE_CVES in xz.mk.

baruch

>
> diff --git a/package/xz/0001-xzgrep-ZDI-CAN-16587.patch b/package/xz/0001-xzgrep-ZDI-CAN-16587.patch
> new file mode 100644
> index 0000000000..78ee9640f0
> --- /dev/null
> +++ b/package/xz/0001-xzgrep-ZDI-CAN-16587.patch
> @@ -0,0 +1,96 @@
> +From 69d1b3fc29677af8ade8dc15dba83f0589cb63d6 Mon Sep 17 00:00:00 2001
> +From: Lasse Collin <lasse.collin@tukaani.org>
> +Date: Tue, 29 Mar 2022 19:19:12 +0300
> +Subject: [PATCH] xzgrep: Fix escaping of malicious filenames (ZDI-CAN-16587).
> +
> +Malicious filenames can make xzgrep to write to arbitrary files
> +or (with a GNU sed extension) lead to arbitrary code execution.
> +
> +xzgrep from XZ Utils versions up to and including 5.2.5 are
> +affected. 5.3.1alpha and 5.3.2alpha are affected as well.
> +This patch works for all of them.
> +
> +This bug was inherited from gzip's zgrep. gzip 1.12 includes
> +a fix for zgrep.
> +
> +The issue with the old sed script is that with multiple newlines,
> +the N-command will read the second line of input, then the
> +s-commands will be skipped because it's not the end of the
> +file yet, then a new sed cycle starts and the pattern space
> +is printed and emptied. So only the last line or two get escaped.
> +
> +One way to fix this would be to read all lines into the pattern
> +space first. However, the included fix is even simpler: All lines
> +except the last line get a backslash appended at the end. To ensure
> +that shell command substitution doesn't eat a possible trailing
> +newline, a colon is appended to the filename before escaping.
> +The colon is later used to separate the filename from the grep
> +output so it is fine to add it here instead of a few lines later.
> +
> +The old code also wasn't POSIX compliant as it used \n in the
> +replacement section of the s-command. Using \<newline> is the
> +POSIX compatible method.
> +
> +LC_ALL=C was added to the two critical sed commands. POSIX sed
> +manual recommends it when using sed to manipulate pathnames
> +because in other locales invalid multibyte sequences might
> +cause issues with some sed implementations. In case of GNU sed,
> +these particular sed scripts wouldn't have such problems but some
> +other scripts could have, see:
> +
> +    info '(sed)Locale Considerations'
> +
> +This vulnerability was discovered by:
> +cleemy desu wayo working with Trend Micro Zero Day Initiative
> +
> +Thanks to Jim Meyering and Paul Eggert discussing the different
> +ways to fix this and for coordinating the patch release schedule
> +with gzip.
> +
> +Signed-off-by: Marcus Hoffmann <marcus.hoffmann@othermo.de> 
> +---
> + src/scripts/xzgrep.in | 20 ++++++++++++--------
> + 1 file changed, 12 insertions(+), 8 deletions(-)
> +
> +diff --git a/src/scripts/xzgrep.in b/src/scripts/xzgrep.in
> +index b180936..e5186ba 100644
> +--- a/src/scripts/xzgrep.in
> ++++ b/src/scripts/xzgrep.in
> +@@ -180,22 +180,26 @@ for i; do
> +          { test $# -eq 1 || test $no_filename -eq 1; }; then
> +       eval "$grep"
> +     else
> ++      # Append a colon so that the last character will never be a newline
> ++      # which would otherwise get lost in shell command substitution.
> ++      i="$i:"
> ++
> ++      # Escape & \ | and newlines only if such characters are present
> ++      # (speed optimization).
> +       case $i in
> +       (*'
> + '* | *'&'* | *'\'* | *'|'*)
> +-        i=$(printf '%s\n' "$i" |
> +-            sed '
> +-              $!N
> +-              $s/[&\|]/\\&/g
> +-              $s/\n/\\n/g
> +-            ');;
> ++        i=$(printf '%s\n' "$i" | LC_ALL=C sed 's/[&\|]/\\&/g; $!s/$/\\/');;
> +       esac
> +-      sed_script="s|^|$i:|"
> ++
> ++      # $i already ends with a colon so don't add it here.
> ++      sed_script="s|^|$i|"
> + 
> +       # Fail if grep or sed fails.
> +       r=$(
> +         exec 4>&1
> +-        (eval "$grep" 4>&-; echo $? >&4) 3>&- | sed "$sed_script" >&3 4>&-
> ++        (eval "$grep" 4>&-; echo $? >&4) 3>&- |
> ++            LC_ALL=C sed "$sed_script" >&3 4>&-
> +       ) || r=2
> +       exit $r
> +     fi >&3 5>&-
> +-- 
> +2.35.1
> +


-- 
                                                     ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 2/2] package/xz: backport CVE-2022-1271 security fix

[Marcus Hoffmann]

Hi Baruch,

On 19.04.22 18:47, Baruch Siach via buildroot wrote:
> Hi Marcus,
> 
> On Tue, Apr 19 2022, Marcus Hoffmann wrote:
>> Fixes the following security issue:
>>
>> CVE-2022-1271/ZDI-22-619/ZDI-CAN-16587: arbitrary-file-write vulnerability
>>
>> Malicious filenames can make xzgrep to write to arbitrary files
>> or (with a GNU sed extension) lead to arbitrary code execution.
>>
>> xzgrep from XZ Utils versions up to and including 5.2.5 are
>> affected. 5.3.1alpha and 5.3.2alpha are affected as well.
>> This patch works for all of them.
>>
>> This bug was inherited from gzip's zgrep. gzip 1.12 includes
>> a fix for zgrep.
>>
>> This vulnerability was discovered by:
>> cleemy desu wayo working with Trend Micro Zero Day Initiative
>>
>> https://www.mail-archive.com/xz-devel@tukaani.org/msg00551.html
>> https://www.zerodayinitiative.com/advisories/ZDI-22-619/
>> https://www.openwall.com/lists/oss-security/2022/04/07/8
>> Signed-off-by: Marcus Hoffmann <marcus.hoffmann@othermo.de>
>> ---
>>   package/xz/0001-xzgrep-ZDI-CAN-16587.patch | 96 ++++++++++++++++++++++
>>   1 file changed, 96 insertions(+)
>>   create mode 100644 package/xz/0001-xzgrep-ZDI-CAN-16587.patch
> 
> This patch should also add XZ_IGNORE_CVES in xz.mk.
> 
> baruch

Indeed! But Peter already send a better patch that does this:

https://patchwork.ozlabs.org/project/buildroot/patch/20220419113409.1008586-1-peter@korsgaard.com/

Marcus

> 
>>
>> diff --git a/package/xz/0001-xzgrep-ZDI-CAN-16587.patch b/package/xz/0001-xzgrep-ZDI-CAN-16587.patch
>> new file mode 100644
>> index 0000000000..78ee9640f0
>> --- /dev/null
>> +++ b/package/xz/0001-xzgrep-ZDI-CAN-16587.patch
>> @@ -0,0 +1,96 @@
>> +From 69d1b3fc29677af8ade8dc15dba83f0589cb63d6 Mon Sep 17 00:00:00 2001
>> +From: Lasse Collin <lasse.collin@tukaani.org>
>> +Date: Tue, 29 Mar 2022 19:19:12 +0300
>> +Subject: [PATCH] xzgrep: Fix escaping of malicious filenames (ZDI-CAN-16587).
>> +
>> +Malicious filenames can make xzgrep to write to arbitrary files
>> +or (with a GNU sed extension) lead to arbitrary code execution.
>> +
>> +xzgrep from XZ Utils versions up to and including 5.2.5 are
>> +affected. 5.3.1alpha and 5.3.2alpha are affected as well.
>> +This patch works for all of them.
>> +
>> +This bug was inherited from gzip's zgrep. gzip 1.12 includes
>> +a fix for zgrep.
>> +
>> +The issue with the old sed script is that with multiple newlines,
>> +the N-command will read the second line of input, then the
>> +s-commands will be skipped because it's not the end of the
>> +file yet, then a new sed cycle starts and the pattern space
>> +is printed and emptied. So only the last line or two get escaped.
>> +
>> +One way to fix this would be to read all lines into the pattern
>> +space first. However, the included fix is even simpler: All lines
>> +except the last line get a backslash appended at the end. To ensure
>> +that shell command substitution doesn't eat a possible trailing
>> +newline, a colon is appended to the filename before escaping.
>> +The colon is later used to separate the filename from the grep
>> +output so it is fine to add it here instead of a few lines later.
>> +
>> +The old code also wasn't POSIX compliant as it used \n in the
>> +replacement section of the s-command. Using \<newline> is the
>> +POSIX compatible method.
>> +
>> +LC_ALL=C was added to the two critical sed commands. POSIX sed
>> +manual recommends it when using sed to manipulate pathnames
>> +because in other locales invalid multibyte sequences might
>> +cause issues with some sed implementations. In case of GNU sed,
>> +these particular sed scripts wouldn't have such problems but some
>> +other scripts could have, see:
>> +
>> +    info '(sed)Locale Considerations'
>> +
>> +This vulnerability was discovered by:
>> +cleemy desu wayo working with Trend Micro Zero Day Initiative
>> +
>> +Thanks to Jim Meyering and Paul Eggert discussing the different
>> +ways to fix this and for coordinating the patch release schedule
>> +with gzip.
>> +
>> +Signed-off-by: Marcus Hoffmann <marcus.hoffmann@othermo.de>
>> +---
>> + src/scripts/xzgrep.in | 20 ++++++++++++--------
>> + 1 file changed, 12 insertions(+), 8 deletions(-)
>> +
>> +diff --git a/src/scripts/xzgrep.in b/src/scripts/xzgrep.in
>> +index b180936..e5186ba 100644
>> +--- a/src/scripts/xzgrep.in
>> ++++ b/src/scripts/xzgrep.in
>> +@@ -180,22 +180,26 @@ for i; do
>> +          { test $# -eq 1 || test $no_filename -eq 1; }; then
>> +       eval "$grep"
>> +     else
>> ++      # Append a colon so that the last character will never be a newline
>> ++      # which would otherwise get lost in shell command substitution.
>> ++      i="$i:"
>> ++
>> ++      # Escape & \ | and newlines only if such characters are present
>> ++      # (speed optimization).
>> +       case $i in
>> +       (*'
>> + '* | *'&'* | *'\'* | *'|'*)
>> +-        i=$(printf '%s\n' "$i" |
>> +-            sed '
>> +-              $!N
>> +-              $s/[&\|]/\\&/g
>> +-              $s/\n/\\n/g
>> +-            ');;
>> ++        i=$(printf '%s\n' "$i" | LC_ALL=C sed 's/[&\|]/\\&/g; $!s/$/\\/');;
>> +       esac
>> +-      sed_script="s|^|$i:|"
>> ++
>> ++      # $i already ends with a colon so don't add it here.
>> ++      sed_script="s|^|$i|"
>> +
>> +       # Fail if grep or sed fails.
>> +       r=$(
>> +         exec 4>&1
>> +-        (eval "$grep" 4>&-; echo $? >&4) 3>&- | sed "$sed_script" >&3 4>&-
>> ++        (eval "$grep" 4>&-; echo $? >&4) 3>&- |
>> ++            LC_ALL=C sed "$sed_script" >&3 4>&-
>> +       ) || r=2
>> +       exit $r
>> +     fi >&3 5>&-
>> +--
>> +2.35.1
>> +
> 
> 
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 2/2] package/xz: backport CVE-2022-1271 security fix

[Marcus Hoffmann]

Hi Baruch,

On 19.04.22 18:47, Baruch Siach via buildroot wrote:
> Hi Marcus,
> 
> On Tue, Apr 19 2022, Marcus Hoffmann wrote:
>> Fixes the following security issue:
>>
>> CVE-2022-1271/ZDI-22-619/ZDI-CAN-16587: arbitrary-file-write vulnerability
>>
>> Malicious filenames can make xzgrep to write to arbitrary files
>> or (with a GNU sed extension) lead to arbitrary code execution.
>>
>> xzgrep from XZ Utils versions up to and including 5.2.5 are
>> affected. 5.3.1alpha and 5.3.2alpha are affected as well.
>> This patch works for all of them.
>>
>> This bug was inherited from gzip's zgrep. gzip 1.12 includes
>> a fix for zgrep.
>>
>> This vulnerability was discovered by:
>> cleemy desu wayo working with Trend Micro Zero Day Initiative
>>
>> https://www.mail-archive.com/xz-devel@tukaani.org/msg00551.html
>> https://www.zerodayinitiative.com/advisories/ZDI-22-619/
>> https://www.openwall.com/lists/oss-security/2022/04/07/8
>> Signed-off-by: Marcus Hoffmann <marcus.hoffmann@othermo.de>
>> ---
>>   package/xz/0001-xzgrep-ZDI-CAN-16587.patch | 96 ++++++++++++++++++++++
>>   1 file changed, 96 insertions(+)
>>   create mode 100644 package/xz/0001-xzgrep-ZDI-CAN-16587.patch
> 
> This patch should also add XZ_IGNORE_CVES in xz.mk.
> 
> baruch


Indeed! But Peter already send a better patch that does this:

https://patchwork.ozlabs.org/project/buildroot/patch/20220419113409.1008586-1-peter@korsgaard.com/

Marcus
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/2] package/gzip: security bump to 1.12

[Arnout Vandecappelle]

On 19/04/2022 13:17, Marcus Hoffmann wrote:
> Fixes the following security issues:
> 
> CVE-2022-1271: arbitrary-file-write vulnerability
> 
> zgrep applied to a crafted file name with two or more newlines
> can no longer overwrite an arbitrary, attacker-selected file.
> [bug introduced in gzip-1.3.10]
> 
> https://www.openwall.com/lists/oss-security/2022/04/07/8
> 
> Other changes:
> 
> ** Changes in behavior
> 
>    'gzip -l' no longer misreports file lengths 4 GiB and larger.
>    Previously, 'gzip -l' output the 32-bit value stored in the gzip
>    header even though that is the uncompressed length modulo 2**32.
>    Now, 'gzip -l' calculates the uncompressed length by decompressing
>    the data and counting the resulting bytes.  Although this can take
>    much more time, nowadays the correctness pros seem to outweigh the
>    performance cons.
> 
>    'zless' is no longer installed on platforms lacking 'less'.
> 
> ** Bug fixes
> 
>    zgrep now names input file on error instead of mislabeling it as
>    "(standard input)", if grep supports the GNU -H and --label options.
> 
>    'zdiff -C 5' no longer misbehaves by treating '5' as a file name.
>    [bug present since the beginning]
> 
>    Configure-time options like --program-prefix now work.
> 
> Release Announcement:
> https://lists.gnu.org/r/bug-gzip/2022-04/msg00011.html
> 
> Signed-off-by: Marcus Hoffmann <marcus.hoffmann@othermo.de>

  Applied to master, thanks.

  Regards,
  Arnout

> ---
>   package/gzip/gzip.hash | 4 ++--
>   package/gzip/gzip.mk   | 2 +-
>   2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/package/gzip/gzip.hash b/package/gzip/gzip.hash
> index 1cf73ff912..80b86f4797 100644
> --- a/package/gzip/gzip.hash
> +++ b/package/gzip/gzip.hash
> @@ -1,6 +1,6 @@
>   # Locally calculated after checking pgp signature
> -# https://ftp.gnu.org/gnu/gzip/gzip-1.11.tar.xz.sig
> +# https://ftp.gnu.org/gnu/gzip/gzip-1.12.tar.xz.sig
>   # using key 155D3FC500C834486D1EEA677FD9FCCB000BEEEE
> -sha256  9b9a95d68fdcb936849a4d6fada8bf8686cddf58b9b26c9c4289ed0c92a77907  gzip-1.11.tar.xz
> +sha256  ce5e03e519f637e1f814011ace35c4f87b33c0bbabeec35baf5fbd3479e91956  gzip-1.12.tar.xz
>   # Locally calculated
>   sha256  8ceb4b9ee5adedde47b31e975c1d90c73ad27b6b165a1dcd80c7c545eb65b903  COPYING
> diff --git a/package/gzip/gzip.mk b/package/gzip/gzip.mk
> index 92588fcdb8..2092df363c 100644
> --- a/package/gzip/gzip.mk
> +++ b/package/gzip/gzip.mk
> @@ -4,7 +4,7 @@
>   #
>   ################################################################################
>   
> -GZIP_VERSION = 1.11
> +GZIP_VERSION = 1.12
>   GZIP_SOURCE = gzip-$(GZIP_VERSION).tar.xz
>   GZIP_SITE = $(BR2_GNU_MIRROR)/gzip
>   # Some other tools expect it to be in /bin
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/2] package/gzip: security bump to 1.12

[Peter Korsgaard]

>>>>> "Marcus" == Marcus Hoffmann <marcus.hoffmann@othermo.de> writes:

 > Fixes the following security issues:
 > CVE-2022-1271: arbitrary-file-write vulnerability

 > zgrep applied to a crafted file name with two or more newlines
 > can no longer overwrite an arbitrary, attacker-selected file.
 > [bug introduced in gzip-1.3.10]

 > https://www.openwall.com/lists/oss-security/2022/04/07/8

 > Other changes:

 > ** Changes in behavior

 >   'gzip -l' no longer misreports file lengths 4 GiB and larger.
 >   Previously, 'gzip -l' output the 32-bit value stored in the gzip
 >   header even though that is the uncompressed length modulo 2**32.
 >   Now, 'gzip -l' calculates the uncompressed length by decompressing
 >   the data and counting the resulting bytes.  Although this can take
 >   much more time, nowadays the correctness pros seem to outweigh the
 >   performance cons.

 >   'zless' is no longer installed on platforms lacking 'less'.

 > ** Bug fixes

 >   zgrep now names input file on error instead of mislabeling it as
 >   "(standard input)", if grep supports the GNU -H and --label options.

 >   'zdiff -C 5' no longer misbehaves by treating '5' as a file name.
 >   [bug present since the beginning]

 >   Configure-time options like --program-prefix now work.

 > Release Announcement:
 > https://lists.gnu.org/r/bug-gzip/2022-04/msg00011.html

 > Signed-off-by: Marcus Hoffmann <marcus.hoffmann@othermo.de>

Committed to 2022.02.x, thanks.

-- 
Bye, Peter Korsgaard
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot