rustsec-2023-0041
Vulnerability from osv_rustsec
Published
2023-06-01 12:00
Modified
2023-06-13 13:10
Summary
Remote Attackers can cause Denial-of-Service (packet loops) with crafted DNS packets
Details

trust-dns and trust-dns-server are vulnerable to remotely triggered denial-of-service attacks, consuming both network and CPU resources. DNS messages with the QR=1 bit set are responded to with a FormErr response. This allows creating a traffic loop, in which these FormErr responses are sent nonstop between vulnerable servers.

There are two scenarios how this can be exploited: 1) Create a loop between two instances of trust-dns, consuming network resources, or 2) consuming the CPU of a single instance.

With two instances A and B an attacker sends a DNS query with a spoofed source IP address to A. A replies with a FormErr to B. Now both servers with ping-pong the message back and forth until by chance the packet is dropped in the network. Multiple spoofed packets can be sent by the attacker, increasing resource consumption.

A single server can get locked up replying to itself. Same setup as above, but now A sends the reply to itself. The packet is sent out as fast as the CPU and network stack manage. This locks up a CPU core. Multiple packets from the attacker consume multiple CPU cores.

To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "categories": [
          "denial-of-service"
        ],
        "cvss": null,
        "informational": null
      },
      "ecosystem_specific": {
        "affected_functions": null,
        "affects": {
          "arch": [],
          "functions": [],
          "os": []
        }
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "trust-dns-server",
        "purl": "pkg:cargo/trust-dns-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.0.0-0"
            },
            {
              "fixed": "0.22.1"
            },
            {
              "introduced": "0.23.0-0"
            },
            {
              "fixed": "0.23.0-alpha.3"
            }
          ],
          "type": "SEMVER"
        }
      ],
      "versions": []
    }
  ],
  "aliases": [
    "GHSA-5fm9-h728-fwpj"
  ],
  "database_specific": {
    "license": "CC0-1.0"
  },
  "details": "trust-dns and trust-dns-server are vulnerable to remotely triggered denial-of-service attacks, consuming both network and CPU resources.\nDNS messages with the QR=1 bit set are responded to with a `FormErr` response.\nThis allows creating a traffic loop, in which these `FormErr` responses are sent nonstop between vulnerable servers.\n\nThere are two scenarios how this can be exploited: 1) Create a loop between two instances of trust-dns, consuming network resources, or 2) consuming the CPU of a single instance.\n\nWith two instances *A* and *B* an attacker sends a DNS query with a spoofed source IP address to *A*.\n*A* replies with a `FormErr` to *B*.\nNow both servers with ping-pong the message back and forth until by chance the packet is dropped in the network.\nMultiple spoofed packets can be sent by the attacker, increasing resource consumption.\n\nA single server can get locked up replying to itself.\nSame setup as above, but now *A* sends the reply to itself.\nThe packet is sent out as fast as the CPU and network stack manage.\nThis locks up a CPU core.\nMultiple packets from the attacker consume multiple CPU cores.",
  "id": "RUSTSEC-2023-0041",
  "modified": "2023-06-13T13:10:24Z",
  "published": "2023-06-01T12:00:00Z",
  "references": [
    {
      "type": "PACKAGE",
      "url": "https://crates.io/crates/trust-dns-server"
    },
    {
      "type": "ADVISORY",
      "url": "https://rustsec.org/advisories/RUSTSEC-2023-0041.html"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bluejekyll/trust-dns/pull/1952"
    }
  ],
  "related": [],
  "severity": [],
  "summary": "Remote Attackers can cause Denial-of-Service (packet loops) with crafted DNS packets"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Detection rules are retrieved from Rulezet.