CVE-2023-45814: Bunkum Bunkum Tokens Cached Vulnerability

MODERATE
Advisory Identifier: GHSA-jrf2-h5j6-3rrq
Share
CVSS 5.3
CWE-772
Published
Advisory Summary

CVE-2023-45814 is a MODERATE (CVSS 5.3) bunkum tokens cached vulnerability (CWE-772: Missing Release of Resource after Effective Lifetime) affecting Bunkum libraries in the NuGet ecosystem. The issue involves bunkum tokens cached in the authenticationservice are susceptible to a use-after-free. Remediation is available by upgrading affected packages to version 4.2.1.

CVE-2023-45814 at a Glance

CVE Identifier CVE-2023-45814
GHSA Identifier GHSA-jrf2-h5j6-3rrq
Severity MODERATE
CVSS v3.1 Base Score 5.3
CWE Classification CWE-772: Missing Release of Resource after Effective Lifetime
Affected Product Bunkum
Package Ecosystem NuGet
Published Date
Last Updated

Security Impact

CVSS: 5.3

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required None (PR:N)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality Low (C:L)
Integrity None (I:N)
Availability None (A:N)

How to Fix CVE-2023-45814

To remediate this vulnerability, upgrade all affected Bunkum dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

Bunkum fixed: 4.2.1 
Upgrade Bunkum to 4.2.1
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release: 

inspect dependencies for Bunkum

How to Check if You Are Affected

To determine whether your application is affected by CVE-2023-45814, inspect your project dependencies for Bunkum:

inspect dependencies for Bunkum

Analyze the terminal output to locate any version of Bunkum in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 4.2.1), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-772: Missing Release of Resource after Effective Lifetime, where the product does not release a resource after its effective lifetime has ended, i.e., after the resource is no longer needed. In Bunkum, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### Impact First, a little bit of background. So, in the beginning, Bunkum's `AuthenticationService` only supported injecting `IUser`s. However, as Refresh and SoundShapesServer implemented permissions systems support for injecting `IToken`s into endpoints was added. All was well until 4.0. Bunkum 4.0 then changed to enforce relations between `IToken`s and `IUser`s. This wasn't implemented in a very good way in the `AuthenticationService`, and ended up breaking caching in such a way that cached tokens would persist after the lifetime of the request - since we tried to cache both tokens and users. From that point until now, from what I understand, Bunkum was attempting to use that cached token at the start of the next request once cached. Naturally, when that token expired, downstream projects like Refresh would remove the object from Realm - and cause the object in the cache to be in a detached state, causing an exception from invalid use of `IToken.User`. So in other words, a use-after-free since Realm can't manage the lifetime of the cached token. Security-wise, the scope is fairly limited, can only be pulled off on a couple endpoints given a few conditions, and you can't guarantee which token you're going to get. Also, the token *would* get invalidated properly if the endpoint had either a `IToken` usage or a `IUser` usage. User interaction is required as authenticated requests must be performed. ### Patches The fix is to just wipe the token cache after the request was handled, which is now in `4.2.1`. I'd recommend that you update. Unfortunately, there are no real workarounds for other versions in the 4.X.X range.

CVE-2023-45814 Affected Bunkum Versions

1 component(s)
Fixed Versions:
4.2.1
Product / Package Ecosystem Affected Versions Fixed Version
Bunkum
nuget/Bunkum
NuGet
≥ 4.0.0
< 4.2.1
4.2.1

References

GitHub Advisory / Wiki ADVISORY
https://github.com/LittleBigRefresh/Bunkum/security/advisories/GHSA-jrf2-h5j6-3rrq
NVD — CVE-2023-45814 NVD
https://nvd.nist.gov/vuln/detail/CVE-2023-45814
Security Fix Commit FIX COMMIT
https://github.com/LittleBigRefresh/Bunkum/commit/6e109464ed9255f558182f001f475a378405ff76
Bunkum Source Repository REPOSITORY
https://github.com/LittleBigRefresh/Bunkum

Frequently Asked Questions

What is CVE-2023-45814?
CVE-2023-45814 is a security vulnerability in Bunkum involving Bunkum tokens cached in the AuthenticationService are susceptible to a use-after-free under CWE-772: Missing Release of Resource after Effective Lifetime.
Which Bunkum versions are affected?
Affected versions include releases prior to 4.2.1 across affected packages: Bunkum.
What version fixes CVE-2023-45814?
Upgrading to 4.2.1 (or the latest patched release for your respective branch) resolves the vulnerability.
Is Bunkum affected?
Yes, Bunkum is affected in releases prior to 4.2.1. Upgrade your dependency to 4.2.1 or later.
What is the CVSS score of CVE-2023-45814?
CVE-2023-45814 has a CVSS v3.1 base score of 5.3 (MODERATE) with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N.
What CWE is associated with CVE-2023-45814?
CVE-2023-45814 is classified under CWE-772: Missing Release of Resource after Effective Lifetime (The product does not release a resource after its effective lifetime has ended, i.e., after the resource is no longer needed.).
How can I check NuGet dependencies for CVE-2023-45814?
Run the dependency tree command: 'inspect dependencies for Bunkum'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
View Raw JSON 
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-jrf2-h5j6-3rrq",
  "modified" : "2023-10-19T16:11:59Z",
  "published" : "2023-10-19T16:11:59Z",
  "aliases" : [ "CVE-2023-45814" ],
  "summary" : "Bunkum tokens cached in the AuthenticationService are susceptible to a use-after-free",
  "details" : "### Impact\nFirst, a little bit of background. So, in the beginning, Bunkum's `AuthenticationService` only supported injecting `IUser`s. However, as Refresh and SoundShapesServer implemented permissions systems support for injecting `IToken`s into endpoints was added. All was well until 4.0.\n\nBunkum 4.0 then changed to enforce relations between `IToken`s and `IUser`s. This wasn't implemented in a very good way in the `AuthenticationService`, and ended up breaking caching in such a way that cached tokens would persist after the lifetime of the request - since we tried to cache both tokens and users. From that point until now, from what I understand, Bunkum was attempting to use that cached token at the start of the next request once cached.\n\nNaturally, when that token expired, downstream projects like Refresh would remove the object from Realm - and cause the object in the cache to be in a detached state, causing an exception from invalid use of `IToken.User`. So in other words, a use-after-free since Realm can't manage the lifetime of the cached token.\n\nSecurity-wise, the scope is fairly limited, can only be pulled off on a couple endpoints given a few conditions, and you can't guarantee which token you're going to get. Also, the token *would* get invalidated properly if the endpoint had either a `IToken` usage or a `IUser` usage. User interaction is required as authenticated requests must be performed.\n\n### Patches\nThe fix is to just wipe the token cache after the request was handled, which is now in `4.2.1`. I'd recommend that you update. Unfortunately, there are no real workarounds for other versions in the 4.X.X range.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "NuGet",
      "name" : "Bunkum"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "4.0.0"
      }, {
        "fixed" : "4.2.1"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/LittleBigRefresh/Bunkum/security/advisories/GHSA-jrf2-h5j6-3rrq"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2023-45814"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/LittleBigRefresh/Bunkum/commit/6e109464ed9255f558182f001f475a378405ff76"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/LittleBigRefresh/Bunkum"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-772" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2023-10-19T16:11:59Z",
    "nvd_published_at" : "2023-10-18T22:15:09Z"
  }
}