17

This Super User question 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?"

Anders
  • 64,406
  • 24
  • 178
  • 215
Zaibis
  • 701
  • 1
  • 4
  • 16
  • 2
    Most just encrypt the file and move on – Daniel M. Jul 04 '16 at 20:44
  • It isn't Im aware of this beeing possible despite most say it isnt. Im asking here how they are trying to prevent this. – Zaibis Jul 07 '16 at 20:58
  • I'm just making again the point of my last comment and also the Note is saying.... This is not asking IF quarantined files are a danger(as the marked duplicate asks, and gets answered in consent, that they aren't). I'm providing even examples about HOW they could get dangerous and asked *WHAT* AV' do, to protect against the risk I pointed (which risk is by the pretended duplicate simply denied to even exist...) – Zaibis Jun 16 '17 at 13:11

4 Answers4

17

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 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. 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 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, since no files can be read without invoking that. Alternatively, to watch for the marking of pages as executable, it could hook NtProtectVirtualMemory. 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.

Ben N
  • 2,491
  • 1
  • 12
  • 22
  • +1 because this is the first answer at least addressing my concerns! – Zaibis Jul 04 '16 at 17:03
  • My main concerns are about bufferoverflows and an attack on 2 sides. If there is an exploit that lets you get a running process to jump somewhere else. it is enough to know how your code is/isn't decoded and where to find it. None fo these 3 points would protect against it. Could you add some informations about that? So I could accpet your answer :) – Zaibis Jul 08 '16 at 05:42
  • @Zaibis I've added to it, I hope that addresses your concerns. – Ben N Jul 08 '16 at 18:11
6

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.

Overmind
  • 8,779
  • 3
  • 19
  • 28
  • Both cases aren't something I'd consider safe for aspect of OP – Zaibis Jul 04 '16 at 12:16
  • I have added an an example after your RE to the initial answer. – Overmind Jul 04 '16 at 12:18
  • regarding the edit: One simply had to get the pattern read the file and decode this. And there we go. And that is actually the thing I'm worried about. – Zaibis Jul 04 '16 at 12:18
  • 2
    And what if the malware had a separated part which wasn't detected, and was able to convert that text-file back in a binary? Like the AV can do as well. Or does the AV also encrypt that file? – O'Niel Jul 04 '16 at 12:19
  • Counter-Anti-viruses work on disabling the antivirus, not rebuilding a blocked file. There is no reason to rebuild it from the quarantine since the AV is active and will re-block the newly respawned file. – Overmind Jul 04 '16 at 12:21
  • The point is, it doesn't need to be rebuild just to be executed. it is enough that one malware knows where to find it and in what way it was changed. And as long something is insecure so it can make by some vulnearbillity make me execute code, it could if smart enough access the same resources as AV could. Therefor decode it as the AV could. Or what are the ways AV prevents it? – Zaibis Jul 04 '16 at 12:25
  • 1
    Your example situation cannot practically occur. If the antivirus detected a virus, it knows how to remove it completely. And, if there is another hidden process, it would know to respwan an .exe file without needing access to what it originally spawned. Also, the files is in read-deny state, as I mentioned (this prevents further 3rd party access) --> this prevents such a slight possibility. – Overmind Jul 04 '16 at 12:29
  • 2
    @Overmind I don't consider denying R/W/X to be safe, because that implies it could be overpowered by a root or admin command. Even if we ignore remote access or trojan, there's still the risk that Dummy McDumbDumb might still try to execute, sorry I mean, view... 'cute baby photos.jpeg'... with privileged access rights whilst in the quarantine folder. Never underestimate the capacity for human stupidity to wreck a computer! – c1646091 Jul 04 '16 at 20:25
  • And if you think that can't happen, you might want to try working in IT support. – c1646091 Jul 04 '16 at 20:26
  • @c1646091 at least for windows the system group has higher privileges than admin users. So the AV-software can even deny admins access to the files (beside other tricks like hooks on certain system functions). If implemented correctly, the only way to access the file would be via the AV-GUI to un-quarantine it. But of course it doesn't prevent the user to shoot himself into the foot because he "might still try to execute, sorry I mean, view... 'cute baby photos.jpeg'... with privileged access rights". I still hope most adults still have brains because in that case they are themself responsible – H. Idden Jul 04 '16 at 21:24
2

Suppose you have an important file(say, some presentation) that is flagged by your antivirus as "malicious". You do not wish to delete it(it's important after all, even if it is malicious!), but you don't want your machine to get infected as well.

So, what option do you have? Your antivirus product can quarantine it. It keeps the files in an isolated environment on your disk, so that malicious files do not pose a threat to your machine.

There are different approaches as to how these files can be handled: 1) moving the file to a different location 2) renaming the file, changing the format of the file 3) changing the permissions of the file, marking it as hidden 4) encrypting or encoding the file, so that even accessing the file would render the malicious code useless

Now what if you want the file back, even after you understand that it might wreak havoc, or might be just a false-positive? Antivirus products give you the option to move the quarantined file from quarantine to the original location, in the original format, so it is usable again for you(at your own risk, of course!).

If you strongly suspect that your file is harmless, you can try scanning it with other antivirus(say, on Virustotal). You can also ask your antivirus product vendor to recheck the file for any malicious behavior. Once you're satisfied that it is harmless, you can safely go ahead and restore the file from quarantine.

And yes, you can rely on quarantine features of any reputed antivirus product.

pri
  • 4,438
  • 24
  • 31
  • 1
    You explained the practical use of quarantine, but not how it works technically. "by storing the files in different formats" could you explain that please? How does that prevent from malware escaping the quarantine? And how can you be so sure quarantines are secure? We also thought sandbox and VMs were secure, now malware can escape them. Does quarantine also work like a kind of sandbox? Or do they do it by setting permissions, so it can't get executed in any way? Or ain't it a sandbox but does the AV just remove it to another path? – O'Niel Jul 04 '16 at 12:13
  • I've included some of the ways which I know antivirus products use to quarantine. Please take a look at them. I think that even in sandboxes and VMs, the files are not changed, they remain executables, hence they're dangerous. Whereas in Quarantine, the files are rendered non-executable, so that even having the code on your hard disk is like a dead code present, which won't get executed, hence harmless. – pri Jul 04 '16 at 12:23
0

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.

Cees Timmerman
  • 113
  • 6