19019 has much improved GUI explanation, thank you. And it's neat that you can specify how deep to go into compressed files, giving us more granular control especially for allowing office macros, but not in a ZIP which could then contain an EXE which would be allowed. That helps ease my concern. Thank you. thank you.
BUT if we were to regularly get ZIP files containing multiple XLS files with macros in them, there's still a potential problem. I think that's what you acknowledged above, and if so, excuse my overly detailed explanation please. Take this scenario- Vendor sends a couple large excel files in a single zip file, not unusual, a lot of the old school vendors do it this way. As always, they have their silly VBA code in them that the vendor uses internally to query their internal database to get data into the excel files. With the 19019 changes, we could now do 08d5518ef129ba1a992f5eb5c25e497cf886556710ffebe7cfb6aedf9d5727c9 2 # VBA Macro signature of vbaProjectSignature.bin in Excel file that's then in a zip 2 problems here though: 1) If just ONE of the excel files in the zip matches the hash, the whole zip will be allowed through (right?), which means that potential other VBA in separate Excel files that haven't been specifically allowed using the hash will also go through. 2) More worrisome,if a malicious person sends a zip containing Quote1.xls, Quote2,xls, Quote3*.exe (to fool the user)*, and Quote4.xls, if quote 1, 2, or 4 match the hash, they'll all get through in the ZIP as will Quote3.exe, which is a renamed remote tool that antivirus won't catch because it's not a known virus, just a commercially available remote access tool. On our internal network or computers that we control, IPS will stop the tool from running, so that's good. But if click crazy, untrainable, front office person clicks what he think is the third quote while on a home computer where we don't have control, that exe will run.. You wrote, "This is a matter of trust. Do not open this door for haphazardly clicking front office persons." But we can't apply hash exceptions per user, if we want files from this vendor to get through, it'll be enabled for everyone, including the person who will click clcik. Would you consider changing this functionality to consider the other files in a compressed file, or at least giving us the option between: 1. Default functionality / *Loose mode*:: Any matching hash in a compressed file or portion of a PDF will allow the entire file, regardless of what else in that same would ordinarily separately cause a rejection based on extension or file type detection. 2. *Strict Mode*: If a hash is matched for a file in a compressed file (or a portion of a PDF), that match will except that file in the compressed file (or that portion of the PDF) from causing a rejection, but the remaining files in the compressed file (or the other parts of the PDF) will be analyzed and can separately trigger stripping of the containing zip (or the PDF). maybe: 08d5518ef129ba1a992f5eb5c25e497cf886556710ffebe7cfb6aedf9d5727c9 2 STRICT # VBA Macro signature of vbaProjectSignature.bin in Excel file that's then in a zip to enable "strict mode" for that hash, but others will use default functionality? Or give us a GUI option in a select box that affects all hashes: Loose mode (default) / Strict Mode Your current way is still MUCH better than the previous only other option of allowing all VBA from an email address. I just don't understand why you'd prefer the current functionality of this new hash matching vs my "strict mode" suggestion for it. I'm guessing I'm missing a scenario where the current way would be better. Maybe you can explain why your current way is more beneficial? On Sat, Jan 19, 2019 at 12:38 AM Thomas Eckardt <thomas.ecka...@thockar.com> wrote: > > See what I mean? > > Yes - this problem is well known. > > If the unexpected executable contains a virus, the attachment will be > blocked/removed. > > The meaning of this feature is a "super-super-super whitelist" for > attachments. And YES - use it with care OR don't use it in doubt! > > >But what if that vendor is compromised internally or otherwise? > > This is a matter of trust. Do not open this door for "haphazardly > clicking front office persons" ! > > - the signature is removed, if the Macro content is touched anyway > > - it is not possible to modify a PDF without loosing the > signature/certificate > > - jar files loosing there signature if modified > > - the case where an executable is stored in the same compressed file > along with a well known good file - hopefully any virus scanner willl catch > it - otherwise the recipient should KNOW what do, because the attachment > looks different to any ever received from this vendor > > > I'll make some tests for such a scenario. > > Thomas > > > > > > > DISCLAIMER: > ******************************************************* > This email and any files transmitted with it may be confidential, legally > privileged and protected in law and are intended solely for the use of the > individual to whom it is addressed. > This email was multiple times scanned for viruses. There should be no > known virus in this email! > ******************************************************* > > _______________________________________________ > Assp-test mailing list > Assp-test@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/assp-test >
_______________________________________________ Assp-test mailing list Assp-test@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/assp-test