Question: [This Super User question](https://superuser.com/q/1096317/479461) made me ask, is it really a good idea to keep files in quarantine, when you don't know what they are yet? For what I know there are more or less 2 steps that need to be performed for "losing control" of your system. First there has to be some malicious code to be injected to the system and then there needs to be a way to execute it. So what measures does AV software take for "in quarantine"-files to avoid this? I'm assuming, the case where the user is just executing the file isn't the problem. I.e. how to make sure that not a bug is causing some overflow resulting in execution of the code?

In other words: What does AV software do to prevent execution of quarantined files, and can I rely on them not being able to get executed anyway?

**NOTE:** I'm not asking about the ways AV's are performing the quarantine feature. The core of the post is: "What are the ways quarantine features are protecting themselves/quarantined files from beeing tricked/decoded/whatever and getting executed anyways and how likely is it this could happen?"

Answer: 
There are a couple ways an antivirus program might go about preventing the execution of a quarantined file:

* Hold it open for exclusive access. It can simply use the normal [`CreateFile`](https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858) API and pass zero for `dwShareMode`, preventing all other kinds of access to the file. If an executable can't be read, it can't be executed. Since antivirus programs are usually one of the first things to start, they can reopen all such files when the system reboots.
* Use [Software Restriction Policies](https://technet.microsoft.com/en-us/magazine/2008.06.srp.aspx). When the antivirus program is installed, it could create an SRP that blocks the execution of programs in the quarantine directory.
* Hook a function that's critical for the creation of a process. Process starting always involves `NtCreateSection`, so the antivirus program's kernel-mode driver could [hook that](http://www.codeproject.com/Articles/11985/Hooking-the-native-API-and-controlling-process-cre) and determine whether the file in question is an executable and check whether `PAGE_EXECUTE` is requested.

Of these, only the first is useful for non-programs (e.g. documents that may contain exploits). To keep an eye on all file loads, the antivirus program could hook [`NtCreateFile`](https://msdn.microsoft.com/en-us/library/bb432380), since no files can be read without invoking that. Alternatively, to watch for the marking of pages as executable, it could hook [`NtProtectVirtualMemory`](http://undocumented.ntinternals.net/index.html?page=UserMode%2FUndocumented%20Functions%2FMemory%20Management%2FVirtual%20Memory%2FNtProtectVirtualMemory.html). Either way, the kernel-mode driver could look around a bit at what's going on in userspace before allowing the operation to proceed.

The easiest solution, however, would be to encrypt the quarantined files with a key that's not stored on disk. With such a system, the user would have to type a password to decrypt and un-quarantine the files. This could be accomplished fairly easily with some asymmetric-key cryptography.
It's unlikely that any file would execute without a user having granted that permission. That user could have been someone who prepared the factory image, or you when you ran another program.

To prevent (malicious) content from being accessed, a sure way is to use a completely separate machine to encrypt it using a One Time Pad of the same length as the content, and then keeping the encrypted content and the pad separate until it's time to access the content. Stray execution pointers are rare in stable code, and as such should not execute the malicious content even when it's been decoded. Unless, of course, the decoder was written in an unsafe language and contains a bug that the content knows to exploit. (See JPG exploits.)

If you don't wish to salvage the content, then shredding it from orbit (boot from a secure read-only media) should ensure it never returns... if you use an HDD. SSDs are known to manage their own storage cells in a way that offers no guarantee that the data those cells contain is gone. Even HDDs need multiple overwrites according to army specs, and many companies physically shred the drives to ensure no economical data recovery.