A security vulnerability report arrived that claimed that it could obtain unauthorized access to a password-protected ZIP file by the following means:
- Start with a password-protected ZIP file, call it “secret.zip”.
- Create a dummy ZIP file and give it the same password. Call this file “attack”.
- Open attack.zip in Explorer.
- Enter the password when prompted.
- Close attack.zip.
- Copy the secret.zip file on top of the dummy attack.zip file.
- Open “attack.zip” (which is now a copy of secret.zip).
- Observe that Explorer opens the impostor ZIP file without asking for a password. You have obtained unauthorized access to the secret.zip password-protected ZIP file.
As usual, we have to look at who the attacker is, who the victim is, and what the attacker has gained.
The attacker is, I guess, the user who is creating the attack.zip ZIP file and doing the fancy swap-in.
The victim is, I think, the person who created the original password-protected ZIP file “secret.zip”.
And what the attacker gained is access to a password-protected ZIP.
Wait a second, but in order for this trick to work, the attacker must already know the password to the secret.zip ZIP file, because they need to use that same password for the attack.zip ZIP file.
So what the attacker gained is “access to a password-protected ZIP file that they know the password to”, which is not really much of a gain at all. They could have done this in a much simpler way:
- Open secret.zip.
- Enter the password when prompted.
Explorer caches passwords for ZIP files to avoid having to bug the user for the password each time it goes back to the ZIP file.¹ For example, if the ZIP file is open in an Explorer window, and then you extract a file from the ZIP, then the ZIP file needs to be reopened to find that file and extract it. Before asking you for the password, it uses the password you used to open the ZIP file originally, and if that works, then the operation continues without needing to prompt again. It would be super-annoying if you had to re-enter the password for each file you extracted from a ZIP file.
“Bu why does it try the password even when it’s a different ZIP file?”
Well, what exactly is “a different ZIP file”?
If you define it as “A file with the same name but a different last-modified timestamp or with different contents is a different ZIP file”, then it means that any time you modify a password-protected ZIP file (say, to delete a file from it), you will have to re-enter the password. That seems wrong.
The finder here seems to mean that there is some metaphysical concept of “identity” that is broader than “files are byte-for-byte identical” (because they presumably want the password to be remembered even if, say, a single file is removed from the ZIP file), yet more strict than “a file is created” (because they want “overwriting the bytes of one file with the bytes of another file” to change the identity).
Now you’re dealing with some sort of Ship of Theseus thought experiment: Suppose the original file is modified one byte at a time until it matches the replacement file. At what point does it stop being the original file and start being the replacement?
Windows isn’t going to try to solve a philosophical conundrum from ancient Greece.
Windows uses the simple rule that if it has the same path, then it’s worth trying the same password.
But it’s just trying the password you already gave it. It did not magically determine the password for the file. If the password you gave it is incorrect, then Windows will prompt for the password. The only way you can gain access to the ZIP file is if you provide the password.
¹ The cache has session lifetime, so all of these cached ZIP passwords are forgotten when you sign out.
Not “don’t ask again”, but rather “save password”
“Windows isn’t going to try to solve a philosophical conundrum from ancient Greece.”
Windows doesn’t, but some applications make the user ponder Zeno’s paradox while watching the progress bar move slower and slower 🙂
Just add a checkbox. It can be opt out, but it will serve two purposes: letting the user know the password will be saved, and providing an option to opt out. If, for example, it’s a shared computer, I’d rather not have it shared. And yes, the shared computer can already have a keylogger etc., but it’s about reducing the risk.
A checkbox doesn't solve the issue here at all and would just add an option that effectively does nothing. Firstly, if you provide the user an option to "don't ask again" then most likely they'll check that box and therefore expose themselves to more of a security vulnerability. Furthermore it is per file and most likely, if it is password protected, the user isn't going to be opening it that often anyway. And perhaps more likely it is a once and done file yet you'd be caching off the password to a file that may no longer even exist.
Secondly, the...
For one thing, I did not expect File Explorer to remember my ZIP file password at all. My mental model for the default design:
- If I enter password while browsing, then the window remembers the password in-memory for any subsequent operations. When I navigate out or when the window is closed, it forgets the password.
- If I copy files into/out of the ZIP file, then the file operation remembers the password in-memory for the duration of that operation, either from prompting or from the explorer window. When the operation completes, it forgets the password.
- For a COM perspective,...
I agree, this is the real issue.
It comes down to expectations tho. Am I trying to hide files from prying eyes on my computer (presumably(!) not me)? Then this is not what I want.
Otherwise, caching the password sounds useful.
Given the choice of making life easier, or supporting potentially questionable use cases, I lean toward “easier”. But there’ s no right answer here.
“The cache has session lifetime, so all of these cached ZIP passwords are forgotten when you sign out.”
The reporter missing that fact explains the whole thing.
On a related note; since Windows Explorer only supports the legacy zip file password scheme, it’s almost certainly faster to crack the password than to prompt the user for it. (And if Windows Explorer gained new zip encryption types support, do so only for the legacy one.)