gsd-2024-25619
Vulnerability from gsd
Modified
2024-02-09 06:02
Details
Mastodon is a free, open-source social network server based on ActivityPub. When an OAuth Application is destroyed, the streaming server wasn't being informed that the Access Tokens had also been destroyed, this could have posed security risks to users by allowing an application to continue listening to streaming after the application had been destroyed. Essentially this comes down to the fact that when Doorkeeper sets up the relationship between Applications and Access Tokens, it uses a `dependent: delete_all` configuration, which means the `after_commit` callback setup on `AccessTokenExtension` didn't actually fire, since `delete_all` doesn't trigger ActiveRecord callbacks. To mitigate, we need to add a `before_destroy` callback to `ApplicationExtension` which announces to streaming that all the Application's Access Tokens are being "killed". Impact should be negligible given the affected application had to be owned by the user. None the less this issue has been addressed in versions 4.2.6, 4.1.14, 4.0.14, and 3.5.18. Users are advised to upgrade. There are no known workaround for this vulnerability.
Aliases


To clipboard 

{
  "gsd": {
    "metadata": {
      "exploitCode": "unknown",
      "remediation": "unknown",
      "reportConfidence": "confirmed",
      "type": "vulnerability"
    },
    "osvSchema": {
      "aliases": [
        "CVE-2024-25619"
      ],
      "details": "Mastodon is a free, open-source social network server based on ActivityPub. When an OAuth Application is destroyed, the streaming server wasn\u0027t being informed that the Access Tokens had also been destroyed, this could have posed security risks to users by allowing an application to continue listening to streaming after the application had been destroyed. Essentially this comes down to the fact that when Doorkeeper sets up the relationship between Applications and Access Tokens, it uses a `dependent: delete_all` configuration, which means the `after_commit` callback setup on `AccessTokenExtension` didn\u0027t actually fire, since `delete_all` doesn\u0027t trigger ActiveRecord callbacks. To mitigate, we need to add a `before_destroy` callback to `ApplicationExtension` which announces to streaming that all the Application\u0027s Access Tokens are being \"killed\". Impact should be negligible given the affected application had to be owned by the user. None the less this issue has been addressed in versions 4.2.6, 4.1.14, 4.0.14, and 3.5.18. Users are advised to upgrade. There are no known workaround for this vulnerability.",
      "id": "GSD-2024-25619",
      "modified": "2024-02-09T06:02:34.313979Z",
      "schema_version": "1.4.0"
    }
  },
  "namespaces": {
    "cve.org": {
      "CVE_data_meta": {
        "ASSIGNER": "security-advisories@github.com",
        "ID": "CVE-2024-25619",
        "STATE": "PUBLIC"
      },
      "affects": {
        "vendor": {
          "vendor_data": [
            {
              "product": {
                "product_data": [
                  {
                    "product_name": "mastodon",
                    "version": {
                      "version_data": [
                        {
                          "version_affected": "=",
                          "version_value": "\u003e= 4.2.6, \u003c 4.2.6"
                        },
                        {
                          "version_affected": "=",
                          "version_value": "\u003e= 4.1.0, \u003c 4.1.14"
                        },
                        {
                          "version_affected": "=",
                          "version_value": "\u003e= 4.0.0, \u003c 4.0.14"
                        },
                        {
                          "version_affected": "=",
                          "version_value": "\u003c 3.5.18"
                        }
                      ]
                    }
                  }
                ]
              },
              "vendor_name": "mastodon"
            }
          ]
        }
      },
      "data_format": "MITRE",
      "data_type": "CVE",
      "data_version": "4.0",
      "description": {
        "description_data": [
          {
            "lang": "eng",
            "value": "Mastodon is a free, open-source social network server based on ActivityPub. When an OAuth Application is destroyed, the streaming server wasn\u0027t being informed that the Access Tokens had also been destroyed, this could have posed security risks to users by allowing an application to continue listening to streaming after the application had been destroyed. Essentially this comes down to the fact that when Doorkeeper sets up the relationship between Applications and Access Tokens, it uses a `dependent: delete_all` configuration, which means the `after_commit` callback setup on `AccessTokenExtension` didn\u0027t actually fire, since `delete_all` doesn\u0027t trigger ActiveRecord callbacks. To mitigate, we need to add a `before_destroy` callback to `ApplicationExtension` which announces to streaming that all the Application\u0027s Access Tokens are being \"killed\". Impact should be negligible given the affected application had to be owned by the user. None the less this issue has been addressed in versions 4.2.6, 4.1.14, 4.0.14, and 3.5.18. Users are advised to upgrade. There are no known workaround for this vulnerability."
          }
        ]
      },
      "impact": {
        "cvss": [
          {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 3.1,
            "baseSeverity": "LOW",
            "confidentialityImpact": "LOW",
            "integrityImpact": "NONE",
            "privilegesRequired": "LOW",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N",
            "version": "3.1"
          }
        ]
      },
      "problemtype": {
        "problemtype_data": [
          {
            "description": [
              {
                "cweId": "CWE-613",
                "lang": "eng",
                "value": "CWE-613: Insufficient Session Expiration"
              }
            ]
          },
          {
            "description": [
              {
                "cweId": "CWE-672",
                "lang": "eng",
                "value": "CWE-672: Operation on a Resource after Expiration or Release"
              }
            ]
          }
        ]
      },
      "references": {
        "reference_data": [
          {
            "name": "https://github.com/mastodon/mastodon/security/advisories/GHSA-7w3c-p9j8-mq3x",
            "refsource": "MISC",
            "url": "https://github.com/mastodon/mastodon/security/advisories/GHSA-7w3c-p9j8-mq3x"
          },
          {
            "name": "https://github.com/mastodon/mastodon/commit/68eaa804c9bafdc5f798e114e9ba00161425dd71",
            "refsource": "MISC",
            "url": "https://github.com/mastodon/mastodon/commit/68eaa804c9bafdc5f798e114e9ba00161425dd71"
          }
        ]
      },
      "source": {
        "advisory": "GHSA-7w3c-p9j8-mq3x",
        "discovery": "UNKNOWN"
      }
    },
    "nvd.nist.gov": {
      "cve": {
        "descriptions": [
          {
            "lang": "en",
            "value": "Mastodon is a free, open-source social network server based on ActivityPub. When an OAuth Application is destroyed, the streaming server wasn\u0027t being informed that the Access Tokens had also been destroyed, this could have posed security risks to users by allowing an application to continue listening to streaming after the application had been destroyed. Essentially this comes down to the fact that when Doorkeeper sets up the relationship between Applications and Access Tokens, it uses a `dependent: delete_all` configuration, which means the `after_commit` callback setup on `AccessTokenExtension` didn\u0027t actually fire, since `delete_all` doesn\u0027t trigger ActiveRecord callbacks. To mitigate, we need to add a `before_destroy` callback to `ApplicationExtension` which announces to streaming that all the Application\u0027s Access Tokens are being \"killed\". Impact should be negligible given the affected application had to be owned by the user. None the less this issue has been addressed in versions 4.2.6, 4.1.14, 4.0.14, and 3.5.18. Users are advised to upgrade. There are no known workaround for this vulnerability."
          },
          {
            "lang": "es",
            "value": "Mastodon es un servidor de red social gratuito y de c\u00f3digo abierto basado en ActivityPub. Cuando se destruye una aplicaci\u00f3n OAuth, no se informaba al servidor de transmisi\u00f3n que los tokens de acceso tambi\u00e9n se hab\u00edan destruido, lo que podr\u00eda haber planteado riesgos de seguridad para los usuarios al permitir que una aplicaci\u00f3n continuara escuchando la transmisi\u00f3n despu\u00e9s de que la aplicaci\u00f3n hubiera sido destruida. Esencialmente, esto se reduce al hecho de que cuando Doorkeeper configura la relaci\u00f3n entre las aplicaciones y los tokens de acceso, utiliza una configuraci\u00f3n `dependent: delete_all`, lo que significa que la configuraci\u00f3n de devoluci\u00f3n de llamada `after_commit` en `AccessTokenExtension` en realidad no se activ\u00f3, ya que ` delete_all` no activa devoluciones de llamada de ActiveRecord. Para mitigar, necesitamos agregar una devoluci\u00f3n de llamada `before_destroy` a `ApplicationExtension` que anuncia a la transmisi\u00f3n que todos los tokens de acceso de la aplicaci\u00f3n est\u00e1n siendo \"eliminados\". El impacto deber\u00eda ser insignificante dado que la aplicaci\u00f3n afectada ten\u00eda que ser propiedad del usuario. No obstante, este problema se ha solucionado en las versiones 4.2.6, 4.1.14, 4.0.14 y 3.5.18. Se recomienda a los usuarios que actualicen. No se conocen workaround para esta vulnerabilidad."
          }
        ],
        "id": "CVE-2024-25619",
        "lastModified": "2024-02-15T06:23:39.303",
        "metrics": {
          "cvssMetricV31": [
            {
              "cvssData": {
                "attackComplexity": "HIGH",
                "attackVector": "NETWORK",
                "availabilityImpact": "NONE",
                "baseScore": 3.1,
                "baseSeverity": "LOW",
                "confidentialityImpact": "LOW",
                "integrityImpact": "NONE",
                "privilegesRequired": "LOW",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N",
                "version": "3.1"
              },
              "exploitabilityScore": 1.6,
              "impactScore": 1.4,
              "source": "security-advisories@github.com",
              "type": "Secondary"
            }
          ]
        },
        "published": "2024-02-14T21:15:08.620",
        "references": [
          {
            "source": "security-advisories@github.com",
            "url": "https://github.com/mastodon/mastodon/commit/68eaa804c9bafdc5f798e114e9ba00161425dd71"
          },
          {
            "source": "security-advisories@github.com",
            "url": "https://github.com/mastodon/mastodon/security/advisories/GHSA-7w3c-p9j8-mq3x"
          }
        ],
        "sourceIdentifier": "security-advisories@github.com",
        "vulnStatus": "Awaiting Analysis",
        "weaknesses": [
          {
            "description": [
              {
                "lang": "en",
                "value": "CWE-613"
              },
              {
                "lang": "en",
                "value": "CWE-672"
              }
            ],
            "source": "security-advisories@github.com",
            "type": "Primary"
          }
        ]
      }
    }
  }
}


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.