Snort++

Multiple Cisco products are affected by a vulnerability in the rate filtering feature of the Snort detection engine that could allow an unauthenticated, remote attacker to bypass a configured rate limiting filter.  This vulnerability is due to an incorrect connection count comparison. An attacker could exploit this vulnerability by sending traffic through an affected device at a rate that exceeds a configured rate filter. A successful exploit could allow the attacker to successfully bypass the rate filter. This could allow unintended traffic to enter the network protected by the affected device.Show less

Multiple Cisco products are affected by a vulnerability in the Snort Intrusion Prevention System (IPS) rule engine that could allow an unauthenticated, remote attacker to bypass the configured rules on an affected system. This vulnerability is due to incorrect HTTP packet handling. An attacker could exploit this vulnerability by sending crafted HTTP packets through an affected device. A successful exploit could allow the attacker to bypass configured IPS rules and allow uninspected traffic onto the network.Show less

Multiple Cisco products are affected by a vulnerability in Snort rules that could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device.The vulnerability is due to improper handling of the Block with Reset or Interactive Block with Reset actions if a rule is configured without proper constraints. An attacker could exploit this vulnerability by sending a crafted IP packet to the affected device. A successful exploit could allow the attacker to cause through traffic to be dropped. Note: Only products with Snort3 configured and either a rule with Block with Reset or Interactive Block with Reset actions configured are vulnerable. Products configured with Snort2 are not vulnerable.Show less

Cisco Sourcefire Snort 3.0 before build 233 mishandles Ether Type Validation. Since valid ether type and IP protocol numbers do not overlap, Snort++ stores all protocol decoders in a single array. That makes it possible to craft packets that have IP protocol numbers in the ether type field which will confuse the Snort++ decoder. For example, an eth:llc:snap:icmp6 packet will cause a crash because there is no ip6 header with which to calculate the icmp6 checksum. Affected decoders include gre, llc, trans_bridge, ciscometadata, linux_sll, and token_ring. The fix adds a check in the packet manager to validate the ether type before indexing the decoder array. An out of range ether type will raise 116:473.Show less