[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
ts-2024-007
Vulnerability from tailscale

Description: Incorrect DNS resolution with split DNS on macOS and iOS

What happened?

On Tailscale macOS and iOS clients with split DNS configurations (like App Connectors or Restricted Nameservers), lookups of bare tailnet node names could in rare cases return incorrect answers. For example, if a node mynode and an App Connector for *.example.com exist on a tailnet, DNS lookups for mynode could return the answer for mynode.example.com instead of the local tailnet IP. This mis-configuration is intermittent, and most often triggers for a few seconds when switching device networks (for example from Wi-Fi to a phone hotspot).

We fixed this bug in client version 1.68.0, and notified the security contacts of potentially affected tailnets over email.

Who was affected?

All tailnets that use App Connectors or Restricted Domains, and have macOS or iOS nodes could have been affected.

This bug is usually intermittently-triggered when switching networks in our experience. Only lookups of bare domains, like mynode but not mynode.mytailnet.ts.net, are at risk.

Note that not all split DNS domains are dangerous. Only domains where an attacker can choose their FQDN to match a node name, and controls the destination to receive non-TLS traffic could be abused.

We are not aware of any active exploitation of this vulnerability.

What was the impact?

For a split DNS domain example.com, an attacker with control over mynode.example.com can impersonate a non-TLS server running on node mynode on the tailnet. This attack is opportunistic and passive - it relies on the user connecting to mynode using its bare domain and cannot be forced remotely.

What do I need to do?

Upgrade your macOS and iOS clients to 1.68.0 or later.

Show details on source website


{
  "guidislink": false,
  "id": "https://tailscale.com/security-bulletins/#ts-2024-007",
  "link": "https://tailscale.com/security-bulletins/#ts-2024-007",
  "links": [
    {
      "href": "https://tailscale.com/security-bulletins/#ts-2024-007",
      "rel": "alternate",
      "type": "text/html"
    }
  ],
  "published": "Wed, 12 Jun 2024 00:00:00 GMT",
  "summary": "\u003cp\u003e\u003cstrong\u003e\u003cem\u003eDescription\u003c/em\u003e\u003c/strong\u003e: Incorrect DNS resolution with split DNS on macOS and iOS\u003c/p\u003e\n\u003ch5\u003eWhat happened?\u003c/h5\u003e\n\u003cp\u003eOn Tailscale macOS and iOS clients with split DNS configurations (like \u003ca href=\"https://tailscale.com/kb/1281/app-connectors\"\u003eApp\nConnectors\u003c/a\u003e or \u003ca href=\"https://tailscale.com/kb/1054/dns#nameservers\"\u003eRestricted\nNameservers\u003c/a\u003e), lookups of bare tailnet node names\ncould in rare cases return incorrect answers. For example, if a node \u003ccode\u003emynode\u003c/code\u003e\nand an App Connector for \u003ccode\u003e*.example.com\u003c/code\u003e exist on a tailnet, DNS lookups for\n\u003ccode\u003emynode\u003c/code\u003e could return the answer for \u003ccode\u003emynode.example.com\u003c/code\u003e instead of the local\ntailnet IP. This mis-configuration is intermittent, and most often triggers for\na few seconds when switching device networks (for example from Wi-Fi to a phone\nhotspot).\u003c/p\u003e\n\u003cp\u003eWe fixed this bug in client version 1.68.0, and notified the security contacts\nof potentially affected tailnets over email.\u003c/p\u003e\n\u003ch5\u003eWho was affected?\u003c/h5\u003e\n\u003cp\u003eAll tailnets that use App Connectors or Restricted Domains, and have macOS or\niOS nodes could have been affected.\u003c/p\u003e\n\u003cp\u003eThis bug is usually intermittently-triggered when switching networks in our\nexperience. Only lookups of bare domains, like \u003ccode\u003emynode\u003c/code\u003e but not\n\u003ccode\u003emynode.mytailnet.ts.net\u003c/code\u003e, are at risk.\u003c/p\u003e\n\u003cp\u003eNote that not all split DNS domains are dangerous. Only domains where an\nattacker can choose their FQDN to match a node name, and controls the\ndestination to receive non-TLS traffic could be abused.\u003c/p\u003e\n\u003cp\u003eWe are not aware of any active exploitation of this vulnerability.\u003c/p\u003e\n\u003ch5\u003eWhat was the impact?\u003c/h5\u003e\n\u003cp\u003eFor a split DNS domain \u003ccode\u003eexample.com\u003c/code\u003e, an attacker with control over\n\u003ccode\u003emynode.example.com\u003c/code\u003e can impersonate a non-TLS server running on node \u003ccode\u003emynode\u003c/code\u003e\non the tailnet. This attack is opportunistic and passive - it relies on the\nuser connecting to \u003ccode\u003emynode\u003c/code\u003e using its bare domain and cannot be forced\nremotely.\u003c/p\u003e\n\u003ch5\u003eWhat do I need to do?\u003c/h5\u003e\n\u003cp\u003eUpgrade your macOS and iOS clients to 1.68.0 or later.\u003c/p\u003e",
  "summary_detail": {
    "base": "https://tailscale.com/security-bulletins/index.xml",
    "language": null,
    "type": "text/html",
    "value": "\u003cp\u003e\u003cstrong\u003e\u003cem\u003eDescription\u003c/em\u003e\u003c/strong\u003e: Incorrect DNS resolution with split DNS on macOS and iOS\u003c/p\u003e\n\u003ch5\u003eWhat happened?\u003c/h5\u003e\n\u003cp\u003eOn Tailscale macOS and iOS clients with split DNS configurations (like \u003ca href=\"https://tailscale.com/kb/1281/app-connectors\"\u003eApp\nConnectors\u003c/a\u003e or \u003ca href=\"https://tailscale.com/kb/1054/dns#nameservers\"\u003eRestricted\nNameservers\u003c/a\u003e), lookups of bare tailnet node names\ncould in rare cases return incorrect answers. For example, if a node \u003ccode\u003emynode\u003c/code\u003e\nand an App Connector for \u003ccode\u003e*.example.com\u003c/code\u003e exist on a tailnet, DNS lookups for\n\u003ccode\u003emynode\u003c/code\u003e could return the answer for \u003ccode\u003emynode.example.com\u003c/code\u003e instead of the local\ntailnet IP. This mis-configuration is intermittent, and most often triggers for\na few seconds when switching device networks (for example from Wi-Fi to a phone\nhotspot).\u003c/p\u003e\n\u003cp\u003eWe fixed this bug in client version 1.68.0, and notified the security contacts\nof potentially affected tailnets over email.\u003c/p\u003e\n\u003ch5\u003eWho was affected?\u003c/h5\u003e\n\u003cp\u003eAll tailnets that use App Connectors or Restricted Domains, and have macOS or\niOS nodes could have been affected.\u003c/p\u003e\n\u003cp\u003eThis bug is usually intermittently-triggered when switching networks in our\nexperience. Only lookups of bare domains, like \u003ccode\u003emynode\u003c/code\u003e but not\n\u003ccode\u003emynode.mytailnet.ts.net\u003c/code\u003e, are at risk.\u003c/p\u003e\n\u003cp\u003eNote that not all split DNS domains are dangerous. Only domains where an\nattacker can choose their FQDN to match a node name, and controls the\ndestination to receive non-TLS traffic could be abused.\u003c/p\u003e\n\u003cp\u003eWe are not aware of any active exploitation of this vulnerability.\u003c/p\u003e\n\u003ch5\u003eWhat was the impact?\u003c/h5\u003e\n\u003cp\u003eFor a split DNS domain \u003ccode\u003eexample.com\u003c/code\u003e, an attacker with control over\n\u003ccode\u003emynode.example.com\u003c/code\u003e can impersonate a non-TLS server running on node \u003ccode\u003emynode\u003c/code\u003e\non the tailnet. This attack is opportunistic and passive - it relies on the\nuser connecting to \u003ccode\u003emynode\u003c/code\u003e using its bare domain and cannot be forced\nremotely.\u003c/p\u003e\n\u003ch5\u003eWhat do I need to do?\u003c/h5\u003e\n\u003cp\u003eUpgrade your macOS and iOS clients to 1.68.0 or later.\u003c/p\u003e"
  },
  "title": "TS-2024-007",
  "title_detail": {
    "base": "https://tailscale.com/security-bulletins/index.xml",
    "language": null,
    "type": "text/plain",
    "value": "TS-2024-007"
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.