Cisco Bug: CSCvt36709 - [ENH] Being able to authenticate headers as originating from the ESA itself
Mar 14, 2020
- Cisco Email Security Appliance
Known Affected Releases
Symptom: Not being able to authenticate headers as originating from the ESA itself (and not added to the incoming message by a bad actor) creates a security hole when using custom headers to bypass additional filters or otherwise. Given limitations to ESA message and content filters, it is necessary to implement custom headers in some instances to achieve desired results. Security holes create an opportunity for bad actors to bypass security mechanisms and act maliciously. Conditions: If the ESAs had a way to differentiate headers that were included in the message when it originally arrived versus headers added by the ESA itself, then the authenticity of headers could be trusted. Without such trust, a bad actor can take advantage of processing logic by inserting headers that are used to check for whitelisting or other security-related statuses. One proposed method is to sign headers, however any method that the ESA can use to differentiate untrusted versus locally-created headers would achieve the desired result, provided that logic in filter processing was available such that ?trusted? state of headers could be checked. In content filter header checking logic there could be a checkbox for ?require trusted header? or a drop down available to select whether condition required a header state of ?trusted?, ?untrusted?, or ?either? to apply. An adaptation of this for CLI processing of message filters would be desirable as well.
Bug details contain sensitive information and therefore require a Cisco.com account to be viewed.
Bug Details Include
- Full Description (including symptoms, conditions and workarounds)
- Known Fixed Releases
- Related Community Discussions
- Number of Related Support Cases