ghsa-753j-68h2-88xf
Vulnerability from github
Published
2024-10-09 15:32
Modified
2024-10-23 18:33
Severity ?
8.8 (High) - CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Details

In the Linux kernel, the following vulnerability has been resolved:

smack: tcp: ipv4, fix incorrect labeling

Currently, Smack mirrors the label of incoming tcp/ipv4 connections: when a label 'foo' connects to a label 'bar' with tcp/ipv4, 'foo' always gets 'foo' in returned ipv4 packets. So, 1) returned packets are incorrectly labeled ('foo' instead of 'bar') 2) 'bar' can write to 'foo' without being authorized to write.

Here is a scenario how to see this:

  • Take two machines, let's call them C and S, with active Smack in the default state (no settings, no rules, no labeled hosts, only builtin labels)

  • At S, add Smack rule 'foo bar w' (labels 'foo' and 'bar' are instantiated at S at this moment)

  • At S, at label 'bar', launch a program that listens for incoming tcp/ipv4 connections

  • From C, at label 'foo', connect to the listener at S. (label 'foo' is instantiated at C at this moment) Connection succeedes and works.

  • Send some data in both directions.

  • Collect network traffic of this connection.

All packets in both directions are labeled with the CIPSO of the label 'foo'. Hence, label 'bar' writes to 'foo' without being authorized, and even without ever being known at C.

If anybody cares: exactly the same happens with DCCP.

This behavior 1st manifested in release 2.6.29.4 (see Fixes below) and it looks unintentional. At least, no explanation was provided.

I changed returned packes label into the 'bar', to bring it into line with the Smack documentation claims.

Show details on source website

To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-47659"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-09T14:15:07Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsmack: tcp: ipv4, fix incorrect labeling\n\nCurrently, Smack mirrors the label of incoming tcp/ipv4 connections:\nwhen a label \u0027foo\u0027 connects to a label \u0027bar\u0027 with tcp/ipv4,\n\u0027foo\u0027 always gets \u0027foo\u0027 in returned ipv4 packets. So,\n1) returned packets are incorrectly labeled (\u0027foo\u0027 instead of \u0027bar\u0027)\n2) \u0027bar\u0027 can write to \u0027foo\u0027 without being authorized to write.\n\nHere is a scenario how to see this:\n\n* Take two machines, let\u0027s call them C and S,\n   with active Smack in the default state\n   (no settings, no rules, no labeled hosts, only builtin labels)\n\n* At S, add Smack rule \u0027foo bar w\u0027\n   (labels \u0027foo\u0027 and \u0027bar\u0027 are instantiated at S at this moment)\n\n* At S, at label \u0027bar\u0027, launch a program\n   that listens for incoming tcp/ipv4 connections\n\n* From C, at label \u0027foo\u0027, connect to the listener at S.\n   (label \u0027foo\u0027 is instantiated at C at this moment)\n   Connection succeedes and works.\n\n* Send some data in both directions.\n* Collect network traffic of this connection.\n\nAll packets in both directions are labeled with the CIPSO\nof the label \u0027foo\u0027. Hence, label \u0027bar\u0027 writes to \u0027foo\u0027 without\nbeing authorized, and even without ever being known at C.\n\nIf anybody cares: exactly the same happens with DCCP.\n\nThis behavior 1st manifested in release 2.6.29.4 (see Fixes below)\nand it looks unintentional. At least, no explanation was provided.\n\nI changed returned packes label into the \u0027bar\u0027,\nto bring it into line with the Smack documentation claims.",
  "id": "GHSA-753j-68h2-88xf",
  "modified": "2024-10-23T18:33:06Z",
  "published": "2024-10-09T15:32:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47659"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0776bcf9cb6de46fdd94d10118de1cf9b05f83b9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0aea09e82eafa50a373fc8a4b84c1d4734751e2c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2fe209d0ad2e2729f7e22b9b31a86cc3ff0db550"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4be9fd15c3c88775bdf6fa37acabe6de85beebff"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5b4b304f196c070342e32a4752e1fa2e22fc0671"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a948ec993541db4ef392b555c37a1186f4d61670"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d3703fa94116fed91f64c7d1c7d284fb4369070f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d3f56c653c65f170b172d3c23120bc64ada645d8"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}


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 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.