dns_internal.cc in Squid 3.1.6, when IPv6 DNS resolution is not enabled, accesses an invalid socket during an IPv4 TCP DNS query, which allows remote attackers to cause a denial of service (assertion failure and daemon exit) via vectors that trigger an IPv4 DNS response with the TC bit set.

The remote Redhat Enterprise Linux 6 host has one or more packages installed that are affected by multiple vulnerabilities that have been acknowledged by the vendor but will not be patched.

  - squid: improper access restriction upon Digest Authentication nonce replay could lead to remote code     execution (CVE-2020-11945)

  - squid: Buffer overflow in reverse-proxy configurations (CVE-2020-8450)

  - Squid, when transparent interception mode is enabled, uses the HTTP Host header to determine the remote     endpoint, which allows remote attackers to bypass access controls for Flash, Java, Silverlight, and     probably other technologies, and possibly communicate with restricted intranet sites, via a crafted web     page that causes a client to send HTTP requests with a modified Host header. (CVE-2009-0801)

Note that Nessus has not tested for these issues but has instead relied on the package manager's report that the package is installed.

The remote host is affected by the vulnerability described in GLSA-201110-24 (Squid: Multiple vulnerabilities)

    Multiple vulnerabilities have been discovered in Squid. Please review       the CVE identifiers referenced below for details.
  Impact :

    Remote unauthenticated attackers may be able to execute arbitrary code       with the privileges of the Squid process or cause a Denial of Service.
  Workaround :

    There is no known workaround at this time.

Squid 3.1.6 is potentially affected by a denial of service vulnerability that is caused by an assertion failure when contacting IPv4-only DNS resolvers.

According to its banner, the version of the Squid proxy caching server installed on the remote host is 3.1.6. This version is affected by a denial of service vulnerability that is caused by an assertion failure when contacting IPv4-only DNS resolvers.

Note that Nessus has relied only on the version in the proxy server's banner, which is not updated by either of the patches the project has released to address this issue. If one of those has been applied properly and the service restarted, consider this to be a false positive.

ID	Name	Product	Family	Severity
198515	RHEL 6 : squid (Unpatched Vulnerability)	Nessus	Red Hat Local Security Checks	critical
56658	GLSA-201110-24 : Squid: Multiple vulnerabilities	Nessus	Gentoo Local Security Checks	medium
801040	Squid 3.1.6 DNS Replay Denial of Service	Log Correlation Engine	Web Servers	medium
5666	Squid 3.1.6 DNS Replay DoS	Nessus Network Monitor	Web Servers	medium
48433	Squid 3.1.6 DNS Reply Denial of Service	Nessus	Firewalls	medium

Detections

Analytics

CVE-2010-2951

high

Tenable Plugins

critical

medium

medium

medium

medium