Thanks so much for continuing this discussion.  I'm starting to exhaust
myself, so I can only imagine how I'm making you feel here.  If you don't
have the time or drive, I definitely I understand.  Or scroll to the bottom
for what I think might be a good solution here.

It's hard enough getting a 50% trust with the internal people, no chance of
100% trust with anyone outside!!  The real problem is that these outside
vendors who send the office macros are huge, won't sign, won't put us in
touch with the people who can change this, and simply don't care.  And we,
and by proxy I, have no choice but to deal with the current format of file
that comes in because our charity relies on this info.  I wish this weren't
the case, but it's what we've got....

Sticking with the MS office example, if the IT department sends out a Word
document with vba in it, and we allow the hash of that vbaproject.bin file,
there's nothing to stop someone who gets the file from sticking bad OLE in
there too right?  The only safe way would be to sign the file and allow the
hash of that signature, NOT the hash of the vba right?  I can tell you that
there's no way that these vendors (and especially the partners we have in
third world countries) are going to sign the vba.  So excepting the hash of
the vbproject.bin will let a compromised partner have an OLE stuck into one
of these files, then pow, we're dead.  At least with the old method of
userattach, we could allow >any< vba from them, but prohibit OLE.  Not
necessarily better, but different.

As an ASSP admin, I'm outright rejecting exe of all types.  The only
exception is VBA in office, and then only for specific senders.

I disagree that ASSP is all or nothing.  For example, if a DKIMWL matches,
and we have file checking enabled even for whitelisted senders, we can
still check the file, even though we found a good DKIM.  I don't think
these hash matches have to be all or nothing either.

I understand what you're staying about parts of the single PDF file, bits
of .jar files (which we'd never allow to be emailed, but that doesn't mean
other installations won't need it).  Whitelisting a hash is certainly a
good way of letting through a signature.   So, there's times when we need
to whitelist based on a match, and times that >I< at least would want to
except a vba but not whitelist.   I'd bet more than 50% of our attachments
are office files, and I would be surprised if that's not the norm for most
ASSP systems.


-- possible solution???
Couldn't you add a third option to the hash definition like:

thisisthehashbcdef123455667hash 2 ALLOWPARTONLY

where the 2 indicates how deep the hash can be found in a compressed file
and
ALLOWPARTONLY indicates that if this hash is found, we just pretend that
any other reason to block the file because of *that part* is ignored.

Mind you, I really don't know what your code does, but I imagine an
algorithm that takes the file, if it's compressed splits it up, checks
against the the different level 1/2/3 file extension/type rules, checks
against the UserAttach rules. and last checks the hashes, .

As we check the various parts of the file, we also compare each part of a
file to our hashes. If we find a hash match then:

a) If that match is NOT flagged with ALLOWPARTONLY, then we just let the
file through.  This could be used for signed files, to allow no matter what
the other content is (this is how it works now)

b) If that match IS flagged ALLOWPARTONLY, then if that part would have
ordinarily caused a file to be stripped, just pretend that nothing bad was
found and continue with the other parts, but don't explicitly allow the
rest of the file just because a hash match was found on part of it.  That
would let us allow unsigned but known vba code in an office document
without opening up the containing file (or even a nested zip) to being
allowed if it contains other disallowed content.


What do you think?





On Wed, Jan 23, 2019 at 3:36 AM Thomas Eckardt <thomas.ecka...@thockar.com>
wrote:

> >I think there's a real risk of having bad compressed file passed because
> a matching hash of a file within the compressed file.
>
> Yes - a really small one - but there is a risk! To elimnate the risk, the
> hash validity must be resticted to a single zip-level, which does not allow
> to bypass at any lower zip level..
>
> >I still want ASSP to consider the other parts of that file against the
> rules.
>
> What you want to do will only work if the hash is calculated over *all*
> forbidden parts (eg. executables).  It will not work, if the hash is
> calculated over a signature or certificate or only one executable part.
> It is the same like anywhere in assp. If a defined or agreed level of
> trust is reached by a mail (sender, recipient, SPF, DKIM, DMARC .....) ,
> the mail may be delivered regardless of its content.
>
> A good example is a PDF which includes many JavaScripts. In your scenario,
> you would have to calculate and to register the hash for each JS part - and
> the PDF will only pass, if not a single one of them is changed (has not a
> hash match).
> The goal of this feature is, that you don't need to do this, if the PDF is
> signed. If the signature hash is found,all other 'bad' parts (JS) are
> accepted.
>
> Another good reason to keep the exceptional behavior (stop at a found
> good) are for example .jar or .war files. Such file can contain hundreds or
> thousands of java classes (all are executabes). It would* take ages to
> process them all *using this feature without the exceptional behavior.
>
> This I meant, when I said "think about it".  Think about it from a general
> point of view in IT - not as an admin who battles with some office files.
>
> This feature is mainly build, to make attachment conversation easy. For
> example, any of your departments sends out sheets or PDF's, that have to be
> filled out by anyone else. The IT department (you) creates the required
> templates and signs the documents (PDF, macro, OLE, JS ...). As long as
> nobody touches or changes the signed parts, the signatures will not change
> and are keeped valid. If the documents are sent back at a agreed level of
> compression, they can be validated and delivered without any risk.
> If your company is the recipient of such documents, find and define the
> trust level together with the sending partner.
>
> Using this feature without an agreed and trusted security level of
> conversation, may lead in to a more or less higher security risk.
>
> What you want to do is to define or to find a 100% trust level without an
> agreement with any conversation partner - IMHO this is not possible,
> because the partners can change.their behavior at any time - anyway.
>
> Thomas
>
>
>
>
>
> Von:        "K Post" <nntp.p...@gmail.com>
> An:        "ASSP development mailing list" <
> assp-test@lists.sourceforge.net>
> Datum:        22.01.2019 21:44
> Betreff:        Re: [Assp-test] fixed in assp 2.6.4 *SPAM-Evaporator*
> build 19015
> ------------------------------
>
>
>
> I generally feel lost these days :)  Thanks for your continued patience!
>
> I absolutely don't want to make this more complicated than it needs to
> be.  I >think< what I'm proposing might actually be simpler, more what ASSP
> admins would expect, and much better for security.
>
> I see your point about having a match of a  hash of a digital signature be
> enough to allow a file through.  I don't know what to do about that, but
> it's not an issue for me as we'd be looking for hashes of executable
> content vs signatures.   I'm not ignoring its significance though.
>
> Let me answer your question from my perspective:
> >*Why should assp look at any "rest" if one bad content is found (Its an
> exception)? and reverse - Why should assp look at any "rest" if one known
> good content is found (Its an exception)?*
> If bad content is found, I agree, there is no need to scan more, just
> block it and be done.  *But one known good thing found shouldn't allow
> everything else in that file though.    *If you were given a cupcake made
> with delicious chocolate and poison, just because you see the known to be
> delicious chocolate doesn't mean you should blindly eat the cupcake. Check
> for poison even though there's chocolate. --if you're one of the crazy
> people out there who thinks chocolate is also bad, there is no reasoning
> with you :)
>
> I've thought long and hard, and then as you suggested, even harder about
> this.  With the current functionality, I think there's a real risk of
> having bad compressed file passed because a matching hash of a file within
> the compressed file.  A known good hash of an Excel file's vbaproject.bin
> shouldn't pass the whole MS Office compressed file.  I think the option to
> determine how many levels this file can be nested in a zip is a good
> start.  We can allow Excel files with hash matching vbaproject.bin files
> within the excel file, but not an excel file in a zip, by specifying zip
> level 1.   But to your point, what if *"**there is an object included in
> the office file (it's an OLE which can contain anything - also
> executables)"*  ?  I'd want to block OLE!!  Just because a vba project
> matches a good hash, why would we then want to allow unknown OLE in that
> same office compressed file through?  I'm just not seeing the advantage to
> letting it through, but certainly see the risk.
>
> Summary: I want to consider the hash list as a way of ignoring a file
> type/content rule that would ordinarily block the file.  If that match is
> on part of a file (either a file within a compressed file or part of a
> PDF), I still want ASSP to consider the other parts of that file against
> the rules.
>
> It's mostly compressed files that I'm worried about, because I've already
> seen multiple good quotes and a similarly named exe in a zip in the real
> world.  What if a definition like
> 08d5518ef129ba1a992f5eb5c25e497cf886556710ffebe7cfb6aedf9d5727c9 *2*  #
> VBA Macro signature of vbaProject.bin in Excel file or that .bin in an
> excel file in a zip
> would:
>
> 1) Ignore that VBA was found in a directly attached Excel file excel (not
> in a second compressed file) if vbaproject.bin matches a known hash (ignore
> the vba vs specifically allowing the whole file), but continue checking for
> other blocked content in that excel file like OLE's we don't know about.
> If something else is found in that Excel file, block it, even though we
> also found a good hash in it.
>
> 2) Do the same thing for an Excel file (say quote.xlsm), is in a zip file
> (outer.zip).  If an office macro is found in quote.xlsm with a matching
> hash, just ignore that part of the xlsm.  Check the rest of the xlsm file
> for other prohibited content.  If nothing matches, scan the other files in
> outer.zip for prohibited content, traversing into them if they're also
> compressed files.    And if for some reason there was an excepted hash 3
> levels down, ignore that it is excepted, because the hash definition above
> limits to 2 levels.
>
> This would stop:
> A) Outer.zip sent from a compromised vendor that includes Quote1.xlsm,
> Qutoe2.xlsm, and Quote3.EXE - quote1 and 2 has a good hash, quote3.exe is
> the bad file
> B) Quote1.xlsm sent from a compromised vendor that is a copy of their
> standard quote with allowed VBA but now includes malicious OLE.
>
> Before the hash allowing feature, for an office macro to be allowed
> through, we had to allow >>all<< MSOM from a given address, which was far
> from optimal.  But at least with that, OLE would sill be blocked.  Now, we
> can only allow known MSOM (vba), but in doing so OLE will get though in
> that same file which scares me.
>
>
>
>
>
>
>
> On Tue, Jan 22, 2019 at 2:08 AM Thomas Eckardt <
> *thomas.ecka...@thockar.com* <thomas.ecka...@thockar.com>> wrote:
> I'm lost. (:
>
> using the following rule
>
> zip:*@domain => block => exe-bin|xml
>
> having an exception SHA-hash for the included vba file
>
> what would happen - think about ....
>
> even harder - in addition there is an object included in the office file
> (it's an OLE which can contain anything - also executables)
>
> what would happen - think about ....
>
> >If you looked at the rest of the content
>
> Why should assp look at any "rest" if one bad content is found (Its an
> exception)? and reverse - Why should assp look at any "rest" if one known
> good content is found (Its an exception)?
>
> What should be done, if a signature or certificate is hashed , but not the
> executable itself? What is the relation beween the cert and the executable
> or bad file or good files or not bad files?
>
> It makes no sense to further scan an attachment, if a known good file is
> found - because there is no rule for "what to do" , if "what" is found.
>
> Your suggestion will lead in to a very very complex attachment definition.
> You would have to specify (exactly) for each SHA-hash, which other content
> is allowed or forbidden at which zip-level (possibly at which folder level)
>
> Thomas
>
>
>
>
> Von:        "K Post" <*nntp.p...@gmail.com* <nntp.p...@gmail.com>>
> An:        "ASSP development mailing list" <
> *assp-test@lists.sourceforge.net* <assp-test@lists.sourceforge.net>>
> Datum:        21.01.2019 19:07
> Betreff:        Re: [Assp-test] fixed in assp 2.6.4 *SPAM-Evaporator*
> build 19015
> ------------------------------
>
>
>
> We can tell vendors not to send zip files, but we don't have a choice for
> some of the bigger ones that our charity works with.  They won't change,
> not ever.
>
> I understand about AFC just treating office files as zip files (and that's
> fine).  For those vendors who insist on sending zip files with office macro
> enabled files, if we enable the hash of good vbaproject.bin files at level
> 2, then that zip will be set as good regardless of the rest of the
> content.  What I'm asking is why you wouldn't want to mark that file in the
> zip as good, but still check the other files in the zip?  If you looked at
> the rest of the content, that would cause the zip to get rejected if an exe
> is slipped in or non-approved vba is in another file.  Wouldn't this be
> preferable functionality for all?
>
>
>
>
>
>
> On Mon, Jan 21, 2019 at 4:26 AM Thomas Eckardt <
> *thomas.ecka...@thockar.com* <thomas.ecka...@thockar.com>> wrote:
> >Would you consider changing this functionality to consider the other
> files in a compressed file, or at least giving us the option between:
>
>
> This is not possible, because ASSP_AFC does not know anything about office
> files. Office files are ZIP files and processed like them.
> So a part of an Office file will match at zip-level 1. If the Office file
> is in a ZIP the match will be at zip-level 2.
>
> >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).
>
> All other files in an Office file (ZIP) are remaining fles. If you use the
> hash of a signature file to detect the 'good' exception, the (or any)
> project file would be a remaining file (and possibly blocked).
>
>
> ASSP_AFC handles both cases - "found a bad file" and "found a well known
> good file" - as an exception. In the first case it stops processing the
> attachment and blocks, in the second case it stops processing and delivers.
> Both without analysing any other (still not processed) part of this
> attachment
> The check for "a well known good file" is done first for all files in a
> complete uncompressed tree, before (for example) the executable detection
> is done for any part of the ZIP.
>
> There is only one way to be sure a "a well known good file" definition
> can't be (easy) frauded. Restrict the zip-level for parts of office files
> to 1 and for PDF to 0 - and tell the vendors to not zip attachments.
>
> If you fear, a verdors PC can possibly be hijacked and abused to infect
> attachments without lossing an agreed signature - don't use this feature.
>
> 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* <Assp-test@lists.sourceforge.net>
> *https://lists.sourceforge.net/lists/listinfo/assp-test*
> <https://lists.sourceforge.net/lists/listinfo/assp-test>
> _______________________________________________
> Assp-test mailing list
> *Assp-test@lists.sourceforge.net* <Assp-test@lists.sourceforge.net>
> *https://lists.sourceforge.net/lists/listinfo/assp-test*
> <https://lists.sourceforge.net/lists/listinfo/assp-test>
>
>
>
>
> 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* <Assp-test@lists.sourceforge.net>
> *https://lists.sourceforge.net/lists/listinfo/assp-test*
> <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
>
>
>
>
> 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