[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMqWyhhFgATrYJtxFP-hGLR3FN2XhnvZLHVyNtxpWdAp6fFJNQ@mail.gmail.com>
Date: Sat, 9 Aug 2025 22:55:14 -0700
From: lunbun <lunbun021@...il.com>
To: jcb62281@...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
Hi Jacob,
Thanks for asking.
For all of the following results, I have tested on 7-Zip 25.00 on Debian.
Yes, 7-Zip does not resolve `~` in file names/symlink targets.
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`.
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.
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.
Similarly, for `7z l`, symlinks targets are not listed, so an attacker can
hide every part of the path except for the file basename.
On Sat, Aug 9, 2025 at 8:10 PM Jacob Bachmeyer <jcb62281@...il.com> wrote:
> On 8/9/25 15:46, lunbun wrote:
> > [...]
> >
> > ## Details
> >
> > 7-Zip before 25.01 does not always properly handle symbolic links during
> > extraction. Prior to 25.01, it was possible for a maliciously-crafted
> > archive
> > to create an unsafe symbolic link. 7-Zip follows symbolic links when
> > extracting, so this leads to arbitrary file write.
> >
> > An attacker may leverage this arbitrary file write to achieve
> unauthorized
> > access/code execution, such as by overwriting a user's SSH keys or
> > .bashrc file
> > [1]. In one extraction, an attacker may attempt several times to
> > leverage this
> > vulnerability to write to sensitive files.
>
> How much does the attacker have to guess here? Somehow I doubt that
> 7-Zip resolves "~" in file names or symlink targets. (I understand that
> the attacker can simply pack multiple symlinks into the archive.)
>
> To target .bashrc or replace the SSH authorized_keys file, does the
> attacker need to know the user's login name, or is it possible to simply
> list relative symlink targets using .., ../.., ../../.., etc. and hope
> that the archive is being extracted somewhere below the user's home
> directory, as opposed to somewhere under /tmp?
>
> Does a malicious archive produce suspicious output when listed with `7z
> l`? Is this more of a concern for systems that automatically extract
> archives and incautious users or is this actually a general problem?
>
>
> -- Jacob
>
>
>
Content of type "text/html" skipped
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.
