Whitelisting based on attachment checksum rather e-mail address

[robert-scheck]

Given especially current spam waves are partially using real-world e-mail addresses as sender address, it would be a nice enhancement to additionally allow whitelisting based on attachment checksums (SHA512) rather on sender e-mail address (to better cover false positive scenarios).

[sbidy]

I plan to change the white listing to a hash value of the e-mail address.
To use the hash of a document for the exclusion would be also not possible because the documents hash is changing relay fast. If you only open an close a document the modification is big enough to change the hash value.

[robert-scheck]

How does the hash value of a sending e-mail address improve things? The e-mail address can still be faked easily -> IMHO no benefit over whitelisting per sender e-mail address.

Is it possible to extract only the macro part and use a hash value of that? Is this also bound to these unintended changes you mentioned before? Aside of that, you are anyway using caching based on a hash value, so why is it not good enough to use the same checksum for specific whitelisting?

[sbidy]

It improves a security bug - I tried to fuzz mail addresses and detect a vulnerability at the whitelisting. To prevent this and other "unexpected" and "non-RFC" formatted mail address I would like to hash the mail address string to a "normalized" value. It is more a workaround.

To bring a macro whitelisting in place is a good idea 😉 - but I'll plan this for a future release because in my opinion it can be really complex and how should a "normal" user generate the hash for the whitelist?
On the other hand, we can maybe deprecate the feature. An encrypted zip can also a useful method to send a blocked macro document and already used for passing unwanted attachment types through the amavis.

[robert-scheck]

Personally, I treat any whitelisting based on e-mail sender address anyway as manipulatable ;-)

Generating the hash of the macro itself is something that I would leave to MacroMilter (it could just print it in the reject message or simply log the hash when rejecting). Once a whitelisting is required, this anyway requires an administrator handling the hash from somewhere. Given the whitelisting, something like SHA512 would be suitable otherwise it's maybe possible to cause a collision to bypass malicious macros.

[sbidy]

Yub, that's correct. I'm working on it.
I want to implement a hashing over the analyzed macro code. I think this will be the best meta data for a "stable" and secure WS. To avoid a collision I'll use a SHA512.

[sbidy]

implemented and released with 3.6