> This at least prevents this from being a "silent" attack in all but the > most targeted scenarios---and in those cases, the attacker probably > already has another way in.
I disagree that users are only at risk in the "most targeted scenarios." I do agree that these error messages, in most cases, prevent a total brute force. However, I believe that an attacker may reasonably guess that a user will extract either one or two directories deep into their home directory (e.g. `~/extract` or `~/Downloads/extract`) and be correct a decent amount of the time. I do not believe the overwrite `Y/n` prompts can entirely mitigate this either. I looked at three Linux distros (Ubuntu Desktop, Debian, and Rocky Linux), and found at least one potential target file for each of these distros under the user's home directory that both leads directly to RCE and does not exist by default. > If the link cannot be overwritten (another entry in the fake archive > with the same name?), then there are immediate indications pointing to > everything the attacker planted. Adding another entry with the same name could be used to overwrite the link, but 7-Zip will display the overwrite `Y/n` prompt. On Sun, Aug 10, 2025 at 6:16 PM Jacob Bachmeyer <jcb62...@gmail.com> wrote: > On 8/10/25 19:04, lunbun wrote: > > > 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. > > This at least prevents this from being a "silent" attack in all but the > most targeted scenarios---and in those cases, the attacker probably > already has another way in. > > > [...] > > > > > 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. > > If the link cannot be overwritten (another entry in the fake archive > with the same name?), then there are immediate indications pointing to > everything the attacker planted. > > Thank you for answering all of my questions. > > > 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. > > At the original announcement, you had basically released a PoC, there > would be only a matter of programming to generate malicious fake archives. > > > -- Jacob > >
