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

[lunbun <lunbun021 () gmail com>]

> 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 a symlink targets a nonexistent directory, the write will fail. 7-Zip by
default will print an error message, like:
```
ERROR: Cannot open output file : errno=2 : No such file or directory :
./malicious_link/file.txt
```

This applies similarly to other filesystem errors, like insufficient
permissions or unwritable directory.

However, 7-Zip by default continues with extraction regardless of the
error, which is why an attacker can use this "shotgun" strategy. These
errors, though, would hopefully help notify the user that something
suspicious is happening.

> 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?

Yes, the malicious link must point to the directory that contains the
attacker's file/directory.

> 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.)

I could be wrong, but I don't think there is any way for an attacker to
silently remove or replace a malicious link.

I don't know what the general policy is for releasing exploit PoCs after a
patch is released. If it is okay, I can post one on this thread (publicly)
so you can play around with it.

On Sun, Aug 10, 2025 at 4:13 PM Jacob Bachmeyer <jcb62281 () gmail com> wrote:

> 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