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> An: "ASSP development mailing list" <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 > 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 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
