Re: CVE-2025-55188: 7-Zip: Arbitrary file write on extraction, may lead to code execution

[Jacob Bachmeyer <jcb62281 () gmail com>]

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