[<prev] [<thread-prev] [day] [month] [year] [list]
Message-ID: <5d16e4d9-a25d-4b5e-946b-4c5243a54bcb@gmail.com>
Date: Sun, 10 Aug 2025 18:13:37 -0500
From: Jacob Bachmeyer <jcb62281@...il.com>
To: lunbun <lunbun021@...il.com>
Cc: oss-security@...ts.openwall.com
Subject: Re: CVE-2025-55188: 7-Zip: Arbitrary file write on
extraction, may lead to code execution
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
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
