Bug#1009167: xz-utils: diff for NMU version 5.2.5-2.1

2022-04-13 Thread Salvatore Bonaccorso
Hi Jonathan,

On Tue, Apr 12, 2022 at 10:37:32PM -0700, Jonathan Nieder wrote:
> Hi Salvatore,
> 
> Salvatore Bonaccorso wrote:
> > On Sun, Apr 10, 2022 at 03:08:12PM +0200, Salvatore Bonaccorso wrote:
> 
> >> I've prepared an NMU for xz-utils (versioned as 5.2.5-2.1) and
> >> uploaded it to DELAYED/2. Please feel free to tell me if I
> >> should delay it longer.
> >
> > I noted that the last uploads done by Sebastian were NMUs, so hope it
> > is uncontroversial that I rescheduled the fix to delayed/0 and direct
> > upload tonight. There is not particular reason for the urgency, it's
> > more that I would like to base the bullseye-security just on top of
> > the 5.2.5-2.1 versioned 5.2.5-2.1~deb11u1 and have additionally the
> > fix first exposed in unstable enough as well for regression testing.
> 
> No problem at all.  Thanks for your work!  (And I'd be happy to have
> a new maintainer or co-maintainer if you're interested. :))

Thank you Jonathan! For co-maintenace: I think I have to happily
decline because I think I have already enough on my plate.

FWIW, status update: have preapred as well corresponding security
updates and we have scheduled for safety some regression testing as
well. We plan to release the DSA in the next few days (similarly for
gzip).

Regards,
Salvatore



Bug#1009167: xz-utils: diff for NMU version 5.2.5-2.1

2022-04-12 Thread Jonathan Nieder
Hi Salvatore,

Salvatore Bonaccorso wrote:
> On Sun, Apr 10, 2022 at 03:08:12PM +0200, Salvatore Bonaccorso wrote:

>> I've prepared an NMU for xz-utils (versioned as 5.2.5-2.1) and
>> uploaded it to DELAYED/2. Please feel free to tell me if I
>> should delay it longer.
>
> I noted that the last uploads done by Sebastian were NMUs, so hope it
> is uncontroversial that I rescheduled the fix to delayed/0 and direct
> upload tonight. There is not particular reason for the urgency, it's
> more that I would like to base the bullseye-security just on top of
> the 5.2.5-2.1 versioned 5.2.5-2.1~deb11u1 and have additionally the
> fix first exposed in unstable enough as well for regression testing.

No problem at all.  Thanks for your work!  (And I'd be happy to have
a new maintainer or co-maintainer if you're interested. :))

Thanks,
Jonathan



Bug#1009167: xz-utils: diff for NMU version 5.2.5-2.1

2022-04-10 Thread Salvatore Bonaccorso
Hi Jonathan,

On Sun, Apr 10, 2022 at 03:08:12PM +0200, Salvatore Bonaccorso wrote:
> Control: tags 1009167 + patch
> Control: tags 1009167 + pending
> 
> 
> Dear maintainer,
> 
> I've prepared an NMU for xz-utils (versioned as 5.2.5-2.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.

I noted that the last uploads done by Sebastian were NMUs, so hope it
is uncontroversial that I rescheduled the fix to delayed/0 and direct
upload tonight. There is not particular reason for the urgency, it's
more that I would like to base the bullseye-security just on top of
the 5.2.5-2.1 versioned 5.2.5-2.1~deb11u1 and have additionally the
fix first exposed in unstable enough as well for regression testing.

If that was a not welcome move and not having it only on delayed/2
then please let me know.

Regards,
Salvatore



Bug#1009167: xz-utils: diff for NMU version 5.2.5-2.1

2022-04-10 Thread Salvatore Bonaccorso
Control: tags 1009167 + patch
Control: tags 1009167 + pending


Dear maintainer,

I've prepared an NMU for xz-utils (versioned as 5.2.5-2.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards,
Salvatore
diff -Nru xz-utils-5.2.5/debian/changelog xz-utils-5.2.5/debian/changelog
--- xz-utils-5.2.5/debian/changelog	2021-03-08 23:01:54.0 +0100
+++ xz-utils-5.2.5/debian/changelog	2022-04-10 13:31:29.0 +0200
@@ -1,3 +1,11 @@
+xz-utils (5.2.5-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * xzgrep: Fix escaping of malicious filenames (ZDI-CAN-16587)
+(CVE-2022-1271) (Closes: #1009167)
+
+ -- Salvatore Bonaccorso   Sun, 10 Apr 2022 13:31:29 +0200
+
 xz-utils (5.2.5-2) unstable; urgency=medium
 
   * Non-maintainer upload (Closes: #983067).
diff -Nru xz-utils-5.2.5/debian/patches/0010-xzgrep-Fix-escaping-of-malicious-filenames-ZDI-CAN-1.patch xz-utils-5.2.5/debian/patches/0010-xzgrep-Fix-escaping-of-malicious-filenames-ZDI-CAN-1.patch
--- xz-utils-5.2.5/debian/patches/0010-xzgrep-Fix-escaping-of-malicious-filenames-ZDI-CAN-1.patch	1970-01-01 01:00:00.0 +0100
+++ xz-utils-5.2.5/debian/patches/0010-xzgrep-Fix-escaping-of-malicious-filenames-ZDI-CAN-1.patch	2022-04-10 13:30:30.0 +0200
@@ -0,0 +1,96 @@
+From: Lasse Collin 
+Date: Tue, 29 Mar 2022 19:19:12 +0300
+Subject: xzgrep: Fix escaping of malicious filenames (ZDI-CAN-16587).
+Origin: https://git.tukaani.org/?p=xz.git;a=commit;h=69d1b3fc29677af8ade8dc15dba83f0589cb63d6
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2022-1271
+Bug-Debian: https://bugs.debian.org/1009167
+
+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 \ 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.
+---
+ 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 b180936c808c..e5186baf84e9 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>&-
+--