#1448 Temporary files can be left in place permenantly

[fresheneesz]

I have encrypted files that I'm seeing UNENCRYPTED in the temporary directories. These files have been exposed plain-text for over a year. This is a MASSIVE security risk and is completely unacceptable for software that handles encryption. I understand if I open a file, accidentally close 7zip, and then save it (it being the temporary file), that 7zip will have deleted the tmp file, but I then recreate it.

However, 7zip NEEDS to delete these created files on its next opening. Or better yet, don't create obscure hidden plain-text temporary files of encrypted information. I'm VERY PISSED OFF that this happened.

Get rid of the temporary file and create a temporary file in the same directory as the archive. That way at least a user who's paying attention will see that "hey, there's this artifact left over in the directory i was just using". Instead of finding out YEARS later that they have been exposing their passwords in plain text on their hard drive.

I can't express to you how messed up it is that 7zip does this. I'm going to be looking for a better way to encrypt my files. One that doesn't mess it up.

[Igor Pavlov]

Lets suppose you have flash drive that contains encrypted archive.
Do you want 7-zip to create temp file on that flash drive?

[fresheneesz]

Why not? As long as there is a need to create a temporary file (already a security problem), then it better be as ephemeral as possible - which means either making 100% sure the file is gone and never comes back, or if that's not possible, making it very easy for the user to see if their encrypted information is left in plain text.

[fresheneesz]

Igor, care to comment? I just looked in my temp directory and I had SEVEN temporary files with exposed encryped content. I use this for my passwords dude. You do understand that encrypting a file is worthless if your encryption tools store a plain-text version of it somewhere else on your system right?

As far as I'm concerned, 7zip is not an acceptable encryption tool. I won't continue to use it. I'm really disappointed in this project.

[Gary W.]

I've been looking into this problem, and it appears that WinZip v14 solves this problem by wiping the temp files before deletion. I think this could be easily done (dare I say it) by launching the file from 7z, leaving 7zip up while the file is being edited (in the temp folder). Save the file, then close the editing program. 7zip should recognize that you're done and offer to store the updated file back to the archive and wipe the temp file. I think this is basically what WinZip is doing.

I don't see storing in the current dir as a good solution overall, although it would work in this case of a ram drive, mentioned above. At least it would be an easier option.

[GeorgeGW]

Gary. Your suggestion is excellent. Any update on the status of fixing this bug?

[fresheneesz]

Maybe the program should warn you before closing if there are encrypted files left in a temporary folder. It could ask "7zip couldn't delete temporary decrypted files because at least one is open in another program. If you close, those temporary files will not be deleted by 7zip <options:> [wait] [close anyway]"</options:>

[Igor Karushev]

Уважемый Игорь Павлов. Только что установил последнюю версию 7-zip, но проблема так и осталась на месте. Временные файлы из зашифрованных архивов так и остаются в открытом виде во временной папке профиля пользователя и не удаляются при закрытии зашифрованного архива.
Вопрос: будет ли проведена работа в этом направлении?

[doomer]

I was shocked too after discovering this.
Windows allows creating temporary files (FILE_FLAG_DELETE_ON_CLOSE flag to CreateFile WinAPI). So even if owner process crashes temporary files will be deleted.

[M S]

I had exactly the same experience with Viivo which leaves an unencrypted version of an opened file in a folder called C:\Users\<user>\AppData\Local\Viivo\Data\File-Edit even after the file and application is closed. This was a massive shock as I had been using Viivo on a shared PC for many months! </user>

I was hoping 7-zip would have a better solution but apparently not. At the very least I would expect users to be made aware of the existence of these rogue files.

[GeorgeGW]

Gary W's suggestion makes a lot of sense. I appreciate the 7zip author's effort of building a technically excellent software.

It is like a great jet engine installed on a great 747 with a few key bolts not tightened right. And the plane takes its passengers to 30,000 ft and cruising along beautifully. BUT, those few bolts got loosen and the engine is about to fall off the plane...

Is this bug being worked on?

I would highly recommend fixing this bug ASAP considering the recent event at Equifax.

[GeorgeGW]

Hi Ipavlov,

I trust there are plenty of issues to keep you busy. I hope you are reading this issue page.

But this particular security issue of potenial HIGH severity, may I suggest a quick and dirty fix to plug the security hole first? Don't worry about complicated in-place updating the changes of decrypted file back into the 7zip encrypted file. Just focusing plugging the security hole: deleting those temp decrypted files.

My first thought is:
del /s /q C:\Users\<user>\AppData\Local\Temp\<all_just_decryupted_files>.
when closing of 7zip file manager is a giant step in the right direction. </all_just_decryupted_files></user>

However, if you can implement (secure delete) will be superb.
sdelete /s /q C:\Users\<user>\AppData\Local\Temp\<all_just_decryupted_files>.</all_just_decryupted_files></user>

(https://docs.microsoft.com/en-us/sysinternals/downloads/sdelete )

Of course, you may come up with much better solution than this. I hope my clumsy quick and dirty fix trigger the forthcoming of better solution ideas easy for you to implement.

[Ethan Leduc]

+1 on this, I was really surprised and disappointed to learn it was happening.

[Geograph]

Need option like in WinRar. And may be wipe temp directories every 7z manager start

[greatwolf]

What's the status of fixing this bug atm? This issue has been ongoing for 4 years now since it was first posted.

[Johan Larsson]

This is serious stuff! There's no other option for me now than to stop using 7-zip. WinRAR for some reason doesn't enable automatic secure deletion/shredding for temp files of encrypted archives by default, but can be configured to do so.

[greatwolf]

Still nothing after 2 years later?

[trutter]

Overwriting of the temporary files after use has a number of flaws.

1. It isn't guaranteed to wipe all trace of the file, due to remapping in the drive such as wear-leveling.
2. The plaintext file existing for any (short) length of time still gives an opportunity for other software to read it during that time. Backup or archiving software could grab it in that time.
3. Unexpected termination of the program will lead to the plaintext files not being deleted at all and remaining on disk.

In its current form it's best to think of the encryption feature of 7z as protecting the archive while in transit - that is, if written to a thumb drive, sent as an email attachment, sent in instant messaging etc nobody can read the contents should they happen to intercept it and they aren't the authorized recipient (ie, don't have the passphrase). But, the authorized user who decrypts it on their computer cannot expect the files he or she decrypts to be secure against anyone who may have access to that computer during that time or afterwards - unless they have done additional work themselves to ensure that.

Hypothetically, a program like 7zip which can act as a virtual disk driver and provide transparent access to files that way could do away with the need for temporarily storing decrypted files anyway. By that stage, however, you are treading on what Veracrypt does already and maybe Veracrypt is a better solution.

A compromise might be if 7zip were to detect if it is being opened from an encrypted virtual drive, and if so ensure all temporary files it creates are within that encrypted virtual drive - so for instance someone wanting to be extra careful who opens an encrypted 7-zip from within a veracrypt container can be confident any temporary files also stay within that veracrypt container. But, you wouldn't want to do this for external drives which are not encrypted such as thumb drives, because that would then destroy the assumption that encrypted 7-zip containers in transit on physical media are secure against anyone who should come across that thumb drive.

[Gary W.]

Trutter, you bring up some good points. Wiping the temp files wouldn't be a completely secure solution, but it would be better than not. The problem is you don't know in any specific case whether or not it was sufficient. In many cases it could offer protection that it wouldn't otherwise. In other cases, parts of your data would be left. You wouldn't know for sure how much or which.

I think a good workaround might be to use a RAM disk, if you could have 7zip put its temp files there. However, is there still a danger of data getting to the disk, as part of the swap file? I also like your idea of 7zip acting like a virtual drive, but anything in RAM could get swapped-out.

Perhaps this is a good argument for encrypting your hard drive, if concerned about someone else obtaining your computer. I agree, putting encrypted data on thumb drives is more important.

I looked at the source code, but not being familiar with the project, I didn't get anywhere with it.

[Gary W.]

I looked at this further to determine a work-around. As long as the temp files are unpacked in a RAM drive, as well as the final, unencrypted files, this probably does most of what I need. I think using a newer computer and an OS that encrypts your whole hard drive is a more secure solution than anything 7-zip can do, but you need to figure out the right balance of security for you. (As a disclaimer, I'm not a security expert.)

7-zip has an option in the UI to change the temporary work folder, however, it ignored this setting for me, continuing to put unencrypted files in the system temp folder under my user folder. However, when I used 7z.exe from the command-line, the -w option worked. So, I created batch files to extract/update to/from a RAM drive. I'm not saying that this is completely "secure", but for me, I think it's a lot better.

I think fixing the UI settings to allow changing the destination of the temp files seems worthwhile and could mitigate the issue somewhat, although as Trutter pointed out, you can't depend on having a completely secure solution when extracting, regardless of the software.

[jim northrup]

tmpfs or cramfs mounted on /tmp is a huge step in the right direction

working as guest on macosx or similar temporary userdir for your most expensive assets seems like a good idea as well.

hardware drive encryption incurs the debt of redundancy or any combination of cosmic rays, power surges, and MTBF ending your access through sector or cmos corruption.

building from source and submitting a patch for DELETE_ON_CLOSE to the authors of important crypt providers is probably a very strong benefit to yourself and community and puts you in touch with enough system level features to understand what an attacker sees as well.

cheers

[ebloch]

I run a batch every night so I made a 7ziip working folder in a known location and added a CMD to the batch to always delete everything in that folder

[gabry11]

is the bug fixed? are temporary files deleted correctly?

[Jasper Thorne]

Utterly insane that this has been an issue for upwards of ten years. It would literally be as simple as implementing a rule that clears the temp directory of any files containing the prefix 7z when an archive is closed.

Inb4 custom .bat files for cleaning, I'm well aware. This exact reason in 2015 is why I stopped using 7-zip. I figured enough time had passed that this would easily have been fixed, guess not.

Igor why do you not see this as a MASSIVE security flaw? The purpose of an encrypted archive is to protect sensitive information from unauthorized access. You are completely undermining this fundamental purpose by leaving this data lingering in the temp directory. Anyone with access to the user's machine even after the archive is closed could potentially stumble upon this data.

The fact that this has persisted for so long is frankly baffling and demonstrates a severe lack of attention to a critical security aspect. Implementing a simple cleanup rule upon closing an archive is not a complex undertaking. Why has this not been addressed Igor? Users expect and deserve better security from a tool designed for encryption. This negligence puts EVERY user at risk, and it's time this serious flaw was rectified immediately.

Ten years. Ridiculous.

[dartraiden]

If you don't use full disk encryption, there are many other ways to steal this data.

For example, an attacker can boot another operating system from their removable media, and then replace your copy of 7-zip with their own, which will not clear temporary files or will even send them over the network to the attacker.

In addition, it is impossible to reliably delete data from an SSD. As you know, data on an SSD is not erased immediately. The drive controller only marks the memory cells as free and then decides when to write other data there (it tries to wear out all the memory cells evenly to extend the life of the drive). Moreover, even if you overwrite a specific file with random bytes, the SSD controller will write them to a completely different place (cells). SSD is not HDD, here writing works differently. There is no way to specify which specific cells the data should be written to. Unlike HDD, where you can write data to specific sectors.

The only reliable option with protection of temporary files is to encrypt the system partition and be the only user on this PC.

Even if a specific program deletes its files, there is a risk that the attacker will be able to restore something.