Sebastian Krahmer discovered an off-by-one error, leading to a heap-based buffer overflow flaw, in the way Squid handled UDP SNMP requests. An unauthenticated, remote attacker could possibly use this flaw to crash Squid or, potentially, execute arbitrary code. As noted in Sebastian's original report, an SNMP port must be configured. The default configuration of Squid for Red Hat Enterprise Linux 6 and 7 does not include an snmp_port declaration (http://wiki.squid-cache.org/Features/Snmp). Patch: http://bugzillafiles.novell.org/attachment.cgi?id=605545 References: https://bugzilla.novell.com/show_bug.cgi?id=895773 http://seclists.org/oss-sec/2014/q3/542
Created squid tracking bugs for this issue: Affects: fedora-all [bug 1139968]
This actually is a BSS based overflow, not heap based as mentioned in the original report. The actual impact of such overflow is build specific, the issue is unlikely to produce reliable crash of the program. This flaw exists in the code that handles SNMP packets. As noted in comment 0, Squid's SNMP agent is not enabled by default. Hence squid packages in Red Hat Enterprise Linux and Fedora are not affected in their default configuration. SNMP agent is can be enabled by specifying non-zero value for the snmp_port configuration directive. There are multiple options to mitigate this issue: - Do not enable SNMP support if it's not needed. Ensure squid configuration either does not include snmp_port directive, or sets its value to 0. - Restrict access to SNMP port only to trusted networks or hosts. The snmp_incoming_address configuration directive can be used to bind SNMP agent to a specific IP / network interface (e.g. when using multi-homed server with a connection to trusted management network), or firewall configuration can be used to block access from untrusted sources. Note that as UDP is used, firewall restrictions may be bypassed using packets with spoofed source address sent from at least the local network. - Filter packets that are large enough to trigger the overflow - i.e. packets that have at least 4096 bytes. Iptables rule similar to the below one can be used to reject IPv4 packets of the given size (value used in the rule takes IP and UDP header size into account). # iptables -A INPUT -p udp --dport 3401 -m length --length 4124: -j REJECT
Lowering impact rating as this is functionality disabled by default, not needed for normal proxy operation, not needed to be exposed to untrusted users, overflow is too limited and difficult to exploit, and mitigation is available.
Statement: This issue affects the versions of squid as shipped with Red Hat Enterprise Linux 5, 6, and 7. Red Hat Product Security has rated this issue as having Moderate security impact. A future update may address this issue. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.
Created attachment 936923 [details] Local copy of the proposed patch Source: https://bugzilla.novell.com/show_bug.cgi?id=895773#c1
Upstream commits: http://bazaar.launchpad.net/~squid/squid/trunk/revision/13574 http://bazaar.launchpad.net/~squid/squid/trunk/revision/13582
External References: http://www.squid-cache.org/Advisories/SQUID-2014_3.txt
squid-3.4.7-2.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
squid-3.3.13-2.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
squid-3.3.13-2.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
Are there any plans to fix this bug in RHEL 6?
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2014-6270