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

Reply via email to