On 8/10/25 00:55, lunbun wrote:
Hi Jacob,
Thanks for asking.
For all of the following results, I have tested on 7-Zip 25.00 on Debian.
[...]
Symlink targets are relative to the extraction directory, so if the
user extracts to somewhere in their home directory, an attacker could
use the .., ../.., ../../.., etc... strategy to reliably point to
`~/.bashrc` or `~/.ssh/authorized_keys`.
What does 7-Zip do if the symlink implies a nonexistent directory?
(Example: attack targeting ~/.ssh/authorized_keys is unpacked in
~/Downloads/foo/bar and unpacks a symlink to /proc/self/cwd/../../.ssh
which maps to ~/Downloads/.ssh which probably does not exist.)
If, say, the archive is extracted to `/tmp` and the CWD is `/tmp`,
then yes, the best an attacker can do is guess the user's login name.
That would at least limit this to targeted attacks. Suppose the
attacker guesses wrong or tries a "shotgun" approach. What does 7-Zip
do if the symlink points to a nonexistent directory that cannot be
created? (Example: /home/alice on Bob's computer or /home/bob on
Alice's computer.)
What does 7-Zip do if the symlink points to an unwritable directory?
(Example: one "../" too many while aiming for ~/.bashrc and the symlink
resolves to /home.)
However, only specifying the extraction directory with `-o` cannot be
used to mitigate this as a malicious actor could use `/proc/self/cwd`.
The CWD also needs to be set to a safe directory.
Say that a malicious actor is able to point to `~/.bashrc`. By
default, `7z x` will present the user with a `Y/n` prompt asking if
they want to overwrite `.bashrc`. However, 7-Zip displays the path of
`.bashrc` before symlink resolution, so an attacker can hide every
part of the path except for the file basename. Here is a sample message:
```
Would you like to replace the existing file:
Path: ./malicious_link/.bashrc
Size: 3526 bytes (4 KiB)
Modified: 2025-04-18 22:47:34
with the file from archive:
Path: malicious_link/.bashrc
Size: 5 bytes (1 KiB)
Modified: 1970-01-01 00:00:00
? (Y)es / (N)o / (A)lways / (S)kip all / A(u)to rename all / (Q)uit?
```
Of course, this prompt is not displayed if the targeted file does not
already exist.
Fortunately, ".bashrc" and "authorized_keys" are (or should be) highly
suspicious basenames, but an inattentive user could miss that detail.
However, ~/.ssh/authorized_keys is not likely to exist on a system not
normally accessed using SSH, such as a user's desktop, so the attacker
gets to drop it "free" in that typical situation. Add that
distributions often run sshd by default and... well... is there a
firewall blocking inbound port 22?
Do I gather correctly that the malicious link must point to the
directory (e.g. ~ or ~/.ssh) that is to contain the attacker's file
rather than the file itself?
Can the malicious link be silently replaced or does extracting a
malicious archive leave links to every directory that the attack hit?
(That could at least make cleaning out the attack relatively
straightforward.)
Similarly, for `7z l`, symlinks targets are not listed, so an attacker
can hide every part of the path except for the file basename.
This should probably be considered a bug in 7-Zip, although it is
excusable due to 7-Zip's origin on Windows, which did not have symlinks
when 7-Zip was invented.
-- Jacob
