A high-impact vulnerability was discovered in March 2022 in zgrep, a script that ships with GNU gzip — software found on nearly every major UNIX and Linux distribution. Registered as CVE-2022-1271, this bug enables an attacker to quietly overwrite arbitrary files on your system by tricking you (or an automated process) into running zgrep with a specially-named file. Below, I’ll explain the vulnerability in plain English, show example exploits, and link key references. This post is original and tailored for security beginners and seasoned sysadmins alike.
What is zgrep?
zgrep is a shell script provided by GNU gzip. It lets you search inside compressed files with familiar grep-like options. For example:
zgrep 'error' log.gz
Unlike most command-line utilities, zgrep (prior to gzip 1.12) took some shortcuts when handling filenames — and that’s where things went wrong.
Let’s break it down step by step
- zgrep takes the filename you provide (say, archive.gz) and indirectly wraps it in a shell command using eval — a risky move if the filename itself has weird or malicious characters.
- A crafty attacker can instead provide a filename that includes newlines (\n), so when zgrep builds its shell command, it splits into multiple lines.
- Now, the attacker controls not just the source file but also parameters to underlying tools — sometimes even injecting their own shell redirection (>filename) to make gzip or grep write output wherever the attacker wants!
The root cause? No validation or escaping of unsafe characters in filenames, especially those with newlines.
Let’s look at a basic proof-of-concept attack.
Suppose an attacker has the power to create files on your system (maybe via an automated upload or a vulnerable part of your pipeline). They create a file with a multi-line name, such as:
test
victimfile
Hello, you have been hacked!
There are actually two newline (\n) characters in this filename!
Once created, if zgrep is run on this file, the shell script’s internal logic will treat the embedded lines after the first newline as new commands or arguments, including output redirections such as >victimfile. Now any output from the search will be written to a file called victimfile — even though you never asked for it.
Dangerous filename creation (bash)
ATTACKER_FILENAME="attackerfile
victim.txt
Hacked!"
touch "$ATTACKER_FILENAME"
Now, whoever runs
zgrep 'pattern' attackerfile*
…will likely have a new file called victim.txt created (or an existing one overwritten), with contents controlled by the attacker.
Attackers could
- Plant malicious cron jobs by overwriting /etc/crontab
- Alter configs (like ~/.ssh/authorized_keys)
Here’s an expanded Bash snippet that demonstrates the basics
# Simulate a malicious multi-line filename
MALICIOUS="$(printf 'exploit.gz\n/etc/passwd\nnewcontents\n')"
touch "$MALICIOUS"
# Run zgrep on the file (change pattern to whatever)
zgrep "root" ./*gz*
# Check /etc/passwd (or substitute with a test file) — it could be clobbered!
Important: Never test this on any real system unless you overwrite only safe, disposable files!
How to Defend Your System
1. Upgrade gzip: This bug is fixed in gzip version 1.12 (GNU announcement). All major Linux vendors issued timely security updates (Debian Security Bulletin).
2. Do not process untrusted files with zgrep: At least until all your systems are patched, be absolutely certain only trusted files are passed to scripts calling zgrep.
3. Sanitize filenames in scripts: Defensively, never allow weird characters (especially newlines) in filenames used in shell pipelines.
Official References
- CVE-2022-1271 (NVD)
- GNU gzip zgrep Arbitrary File Write (Vendor advisory)
- Debian Security Advisory DSA-5112
- Red Hat Security Advisory
Final Thoughts
This vulnerability is a textbook example of what can go wrong when shell scripts don’t sanitize input — especially in common utilities. If left unpatched, CVE-2022-1271 gives attackers a reliable pathway to escalate from simple file uploads to remote code execution by overwriting critical files. Upgrade, audit, and stay safe!
Timeline
Published on: 08/31/2022 16:15:00 UTC
Last modified on: 10/07/2022 14:14:00 UTC