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: 
The quarantine AV features mentioned in the reply before make sure that the file cannot be executed or accessed while under quarantine. So no, as long as the antivirus is working, there is no danger for the virus to escape quarantine. Practically, some store the file in a different non-runnable format and some just rename the file and deny read/write.execution access to them.

A simple example: you get a standard file with ASCII .exe content, convert that content to binary and re-write it as zeros and 1s into a text file. Nothing can go wrong from there. There's nothing to escape since the file is now binary content saved as text.

-Edit-

So the elements you asked about are Deny R/W/X access and encode the file into anything else but the original format.
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.