locked
Quarantined Files that are not a Virus

    Question

  •  

    Hi,

     

          I ran into what appears to be two separate issues with Forefront for SharePoint SP2. When the full scan was run files were quarantined with the incident description of “Exceedingly compressed size”. One of the files that were quarantined was a zip file that was 24,757,981 bytes and the file has a total of 48 files and the uncompressed size is 29,563KB. The follow changes were made to the configuration; the max container file size setting was changed from 26214400 to 52428800, Max nested attachments changed from 30 to 50, and Max container scan time (msec) realtime changed from 120000 to 240000. Also unchecked scanning Option "Treat ZIP archives containing highly-compressed files as corrupted compressed". After all of these changes the file was still quarantine with the same incident description and the server was even rebooted to make sure is was not an issue of the changes not being active yet. We have not been able to find what setting needs to be changed to prevent this file and other like it from being quarantined by the full scan and real-time scan. The 2nd part of the problem is that we can restore a file from the quarantine by selecting Report, Quarantine and then select a file in the quarantine and click Save As. You can then select a path to save the file to but since the quarantine log did not save the original source path we did not know where the file originally was. This is a problem in all of the Forefront products. All of the other AV products that we have used before save the original source path when a file is quarantined. Does anyone have any ideas on how to resolve these issues?

    Thursday, August 07, 2008 4:26 PM

Answers

  • HI DMSchar,

     ISSUE ONE:

    The Exceedingly compressed size can be controlled by a registry key called MaxCompressedArchivedFileSize.

    If any one object within the zip file has a COMPRESSED size of over the MaxCompressedArchivedFileSize (which is a default of approx
    20MB) then Forefront will delete this file. The reason this was done was to prevent a denial of service attack where Antigen would be scanning an infinitely large file. The incident that you will see for this would be an "Exceedingly compressed size virus”.

    If this is the reason why a message is getting caught you can do the following:

    • In the registry go to HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Forefront Server Security\SharePoint or (Exchange) Server
    • Add a DWORD Key of:  MaxCompressedArchivedFileSize (equaling 40,000,000)
    • Restart FSCController service

    This is about 40 MB. This will allow the zip file itself to be about 40 MB before Forefront will take action on it.

    Please let me know if this helps.



    ISSUE TWO:

    I believe you are asking where the original file was INTENDED to go, prior to being quarantined? Is that correct?
    From the Quarantine I usually either, push it to the intended recipient and /or add additional recipients. I am not sure if you are trying to, for example, save it to the desktop and then save it somehwre else...Please clarify.

    Also, please let me know if I was able to shed any light on the first issue.

    Thanks
    Rob


    Rob M
    Wednesday, August 20, 2008 1:53 PM

All replies

  • HI DMSchar,

     ISSUE ONE:

    The Exceedingly compressed size can be controlled by a registry key called MaxCompressedArchivedFileSize.

    If any one object within the zip file has a COMPRESSED size of over the MaxCompressedArchivedFileSize (which is a default of approx
    20MB) then Forefront will delete this file. The reason this was done was to prevent a denial of service attack where Antigen would be scanning an infinitely large file. The incident that you will see for this would be an "Exceedingly compressed size virus”.

    If this is the reason why a message is getting caught you can do the following:

    • In the registry go to HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Forefront Server Security\SharePoint or (Exchange) Server
    • Add a DWORD Key of:  MaxCompressedArchivedFileSize (equaling 40,000,000)
    • Restart FSCController service

    This is about 40 MB. This will allow the zip file itself to be about 40 MB before Forefront will take action on it.

    Please let me know if this helps.



    ISSUE TWO:

    I believe you are asking where the original file was INTENDED to go, prior to being quarantined? Is that correct?
    From the Quarantine I usually either, push it to the intended recipient and /or add additional recipients. I am not sure if you are trying to, for example, save it to the desktop and then save it somehwre else...Please clarify.

    Also, please let me know if I was able to shed any light on the first issue.

    Thanks
    Rob


    Rob M
    Wednesday, August 20, 2008 1:53 PM
  •  

    Hi Rob,

     

                Thanks for the info on issue one adding the key to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Forefront Server Security\SharePoint solve the problem after increasing the value to a size required to allow the files that were being blocked. Are there other keys like this that are not documented since I searched the documents and the help files for the Forefront for SharePoint SP2 and the key you referenced was not listed. This also leads into Issue two where my problem is that the Manual scan when run quarantines files and does not list where they were so that they could be restored. I am not so much concerned about when a user uploads a file and it is blocked because they know where they intended to put the file, the problem is that the manual scan when run may quarantine files and there is no record of where it was when the manual scan quarantined the file so we do not know where to restore the file to once we have corrected the reason of why it was quarantined in the first place. Some of these may be configuration settings or registry key as in issue one or there may be some other reason like what we ran into when we installed and ran the first manual scan over 1400 files were quarantined and we did not know where to restore them to. In our case most of the quarantined files were caused by some bug where every .xml file was quarantined and after the server was rebooted the problem was resolved where .xml files were no longer quarantine but we still had the problem of not knowing where to restore all the .xml files. The incident description listed for the xml files was “EngineError”.  Like I indicated above rebooting the server corrected whatever caused the files to be quarantined but it made us aware of the risk of running a scan of all the files and not knowing where files should be restore to. Currently the only safe way Forefront (all Forefront Products) would be to identify all configuration and registry setting that might quarantine a file and make sure that setting is high enough so that existing valid files are not quarantined. We were surprised to find that Forefront did not record the original source path of a quarantined file since all other AV products we have used before recorded the full source path.

    Thursday, August 21, 2008 8:20 PM