FKIE_CVE-2023-41041

Vulnerability from fkie_nvd - Published: 2023-08-30 22:15 - Updated: 2024-11-21 08:20
Summary
Graylog is a free and open log management platform. In a multi-node Graylog cluster, after a user has explicitly logged out, a user session may still be used for API requests until it has reached its original expiry time. Each node maintains an in-memory cache of user sessions. Upon a cache-miss, the session is loaded from the database. After that, the node operates solely on the cached session. Modifications to sessions will update the cached version as well as the session persisted in the database. However, each node maintains their isolated version of the session. When the user logs out, the session is removed from the node-local cache and deleted from the database. The other nodes will however still use the cached session. These nodes will only fail to accept the session id if they intent to update the session in the database. They will then notice that the session is gone. This is true for most API requests originating from user interaction with the Graylog UI because these will lead to an update of the session's "last access" timestamp. If the session update is however prevented by setting the `X-Graylog-No-Session-Extension:true` header in the request, the node will consider the (cached) session valid until the session is expired according to its timeout setting. No session identifiers are leaked. After a user has logged out, the UI shows the login screen again, which gives the user the impression that their session is not valid anymore. However, if the session becomes compromised later, it can still be used to perform API requests against the Graylog cluster. The time frame for this is limited to the configured session lifetime, starting from the time when the user logged out. This issue has been addressed in versions 5.0.9 and 5.1.3. Users are advised to upgrade.
Impacted products
Vendor Product Version
graylog graylog *
graylog graylog *

{
  "configurations": [
    {
      "nodes": [
        {
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:a:graylog:graylog:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "5F18A9D7-F631-4E37-BCE2-876D1E0DA431",
              "versionEndExcluding": "5.0.9",
              "versionStartIncluding": "1.0.0",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:a:graylog:graylog:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "E213B603-847C-439D-86AA-D77E59653492",
              "versionEndExcluding": "5.1.3",
              "versionStartIncluding": "5.1.0",
              "vulnerable": true
            }
          ],
          "negate": false,
          "operator": "OR"
        }
      ]
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "Graylog is a free and open log management platform. In a multi-node Graylog cluster, after a user has explicitly logged out, a user session may still be used for API requests until it has reached its original expiry time. Each node maintains an in-memory cache of user sessions. Upon a cache-miss, the session is loaded from the database. After that, the node operates solely on the cached session. Modifications to sessions will update the cached version as well as the session persisted in the database. However, each node maintains their isolated version of the session. When the user logs out, the session is removed from the node-local cache and deleted from the database. The other nodes will however still use the cached session. These nodes will only fail to accept the session id if they intent to update the session in the database. They will then notice that the session is gone. This is true for most API requests originating from user interaction with the Graylog UI because these will lead to an update of the session\u0027s \"last access\" timestamp. If the session update is however prevented by setting the `X-Graylog-No-Session-Extension:true` header in the request, the node will consider the (cached) session valid until the session is expired according to its timeout setting. No session identifiers are leaked. After a user has logged out, the UI shows the login screen again, which gives the user the impression that their session is not valid anymore. However, if the session becomes compromised later, it can still be used to perform API requests against the Graylog cluster. The time frame for this is limited to the configured session lifetime, starting from the time when the user logged out. This issue has been addressed in versions 5.0.9 and 5.1.3. Users are advised to upgrade.\n\n\n"
    },
    {
      "lang": "es",
      "value": "Graylog es una plataforma de gesti\u00f3n de logs gratuita y de c\u00f3digo abierto. En un cl\u00faster Graylog de m\u00faltiples nodos, despu\u00e9s de que un usuario ha cerrado sesi\u00f3n expl\u00edcitamente, una sesi\u00f3n de usuario a\u00fan puede ser utilizada para solicitudes de API hasta que haya alcanzado su tiempo de caducidad original. Cada nodo mantiene una cach\u00e9 en memoria de sesiones de usuario. Ante un fallo de cach\u00e9, la sesi\u00f3n se carga desde la base de datos. Despu\u00e9s de eso, el nodo opera \u00fanicamente con la sesi\u00f3n en cach\u00e9. Las modificaciones a las sesiones actualizar\u00e1n la versi\u00f3n en cach\u00e9, as\u00ed como la sesi\u00f3n persistida en la base de datos. Sin embargo, cada nodo mantiene su versi\u00f3n aislada de la sesi\u00f3n. Cuando el usuario cierra sesi\u00f3n, la sesi\u00f3n se elimina de la cach\u00e9 local del nodo y se borra de la base de datos. Los otros nodos, sin embargo, seguir\u00e1n utilizando la sesi\u00f3n en cach\u00e9. Estos nodos solo fallar\u00e1n en aceptar el ID de la sesi\u00f3n si intentan actualizar la sesi\u00f3n en la base de datos. Entonces notar\u00e1n que la sesi\u00f3n ha desaparecido. Esto es cierto para la mayor\u00eda de las solicitudes de API que se originan de la interacci\u00f3n del usuario con la interfaz de usuario de Graylog porque estas conducir\u00e1n a una actualizaci\u00f3n de la marca de tiempo de \u0027\u00faltimo acceso\u0027 de la sesi\u00f3n. Si la actualizaci\u00f3n de la sesi\u00f3n se evita, sin embargo, configurando el encabezado X-Graylog-No-Session-Extension:true en la solicitud, el nodo considerar\u00e1 la sesi\u00f3n (en cach\u00e9) v\u00e1lida hasta que la sesi\u00f3n expire seg\u00fan su configuraci\u00f3n de tiempo de espera. No se filtran identificadores de sesi\u00f3n. Despu\u00e9s de que un usuario ha cerrado sesi\u00f3n, la interfaz de usuario muestra la pantalla de inicio de sesi\u00f3n nuevamente, lo que da al usuario la impresi\u00f3n de que su sesi\u00f3n ya no es v\u00e1lida. Sin embargo, si la sesi\u00f3n se ve comprometida m\u00e1s tarde, a\u00fan puede ser utilizada para realizar solicitudes de API contra el cl\u00faster Graylog. El plazo para esto est\u00e1 limitado a la vida \u00fatil de la sesi\u00f3n configurada, a partir del momento en que el usuario cerr\u00f3 sesi\u00f3n. Este problema ha sido abordado en las versiones 5.0.9 y 5.1.3. Se aconseja a los usuarios que actualicen."
    }
  ],
  "id": "CVE-2023-41041",
  "lastModified": "2024-11-21T08:20:26.350",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "HIGH",
          "attackVector": "NETWORK",
          "availabilityImpact": "NONE",
          "baseScore": 2.6,
          "baseSeverity": "LOW",
          "confidentialityImpact": "LOW",
          "integrityImpact": "NONE",
          "privilegesRequired": "LOW",
          "scope": "UNCHANGED",
          "userInteraction": "REQUIRED",
          "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:L/I:N/A:N",
          "version": "3.1"
        },
        "exploitabilityScore": 1.2,
        "impactScore": 1.4,
        "source": "security-advisories@github.com",
        "type": "Secondary"
      },
      {
        "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": "nvd@nist.gov",
        "type": "Primary"
      }
    ]
  },
  "published": "2023-08-30T22:15:10.043",
  "references": [
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Patch"
      ],
      "url": "https://github.com/Graylog2/graylog2-server/commit/bb88f3d0b2b0351669ab32c60b595ab7242a3fe3"
    },
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Exploit",
        "Vendor Advisory"
      ],
      "url": "https://github.com/Graylog2/graylog2-server/security/advisories/GHSA-3fqm-frhg-7c85"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Patch"
      ],
      "url": "https://github.com/Graylog2/graylog2-server/commit/bb88f3d0b2b0351669ab32c60b595ab7242a3fe3"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Exploit",
        "Vendor Advisory"
      ],
      "url": "https://github.com/Graylog2/graylog2-server/security/advisories/GHSA-3fqm-frhg-7c85"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Modified",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-613"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Secondary"
    }
  ]
}


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


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…