RUSTSEC-2020-0006 (CVE-2020-35861)

Vulnerability from osv_rustsec – Published: 2020-03-24 12:00 – Updated: 2023-06-13 13:10 – Source website
VLAI
Summary
Flaw in `realloc` allows reading unknown memory
Details

When reallocing, if we allocate new space, we need to copy the old allocation's bytes into the new space. There are old_size number of bytes in the old allocation, but we were accidentally copying new_size number of bytes, which could lead to copying bytes into the realloc'd space from past the chunk that we're bump allocating out of, from unknown memory.

If an attacker can cause reallocs, and can read the realoced data back, this could allow them to read things from other regions of memory that they shouldn't be able to. For example, if some crypto keys happened to live in memory right after a chunk we were bump allocating out of, this could allow the attacker to read the crypto keys.

Beyond just fixing the bug and adding a regression test, I've also taken two additional steps:

  1. While we were already running the testsuite under valgrind in CI, because valgrind exits with the same code that the program did, if there are invalid reads/writes that happen not to trigger a segfault, the program can still exit OK and we will be none the wiser. I've enabled the --error-exitcode=1 flag for valgrind in CI so that tests eagerly fail in these scenarios.

  2. I've written a quickcheck test to exercise realloc. Without the bug fix in this patch, this quickcheck immediately triggers invalid reads when run under valgrind. We didn't previously have quickchecks that exercised realloc because realloc isn't publicly exposed directly, and instead can only be indirectly called. This new quickcheck test exercises realloc via bumpalo::collections::Vec::resize and bumpalo::collections::Vec::shrink_to_fit calls.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
References
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "categories": [
          "memory-exposure"
        ],
        "cvss": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
        "informational": null
      },
      "ecosystem_specific": {
        "affected_functions": null,
        "affects": {
          "arch": [],
          "functions": [],
          "os": []
        }
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "bumpalo",
        "purl": "pkg:cargo/bumpalo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.2.1"
            }
          ],
          "type": "SEMVER"
        }
      ],
      "versions": []
    }
  ],
  "aliases": [
    "CVE-2020-35861",
    "GHSA-vqx7-pw4r-29rr"
  ],
  "database_specific": {
    "license": "CC0-1.0"
  },
  "details": "When `realloc`ing, if we allocate new space, we need to copy the old\nallocation\u0027s bytes into the new space. There are `old_size` number of bytes in\nthe old allocation, but we were accidentally copying `new_size` number of bytes,\nwhich could lead to copying bytes into the realloc\u0027d space from past the chunk\nthat we\u0027re bump allocating out of, from unknown memory.\n\nIf an attacker can cause `realloc`s, and can read the `realoc`ed data back,\nthis could allow them to read things from other regions of memory that they\nshouldn\u0027t be able to. For example, if some crypto keys happened to live in\nmemory right after a chunk we were bump allocating out of, this could allow\nthe attacker to read the crypto keys.\n\nBeyond just fixing the bug and adding a regression test, I\u0027ve also taken two\nadditional steps:\n\n1. While we were already running the testsuite under `valgrind` in CI, because\n   `valgrind` exits with the same code that the program did, if there are\n   invalid reads/writes that happen not to trigger a segfault, the program can\n   still exit OK and we will be none the wiser. I\u0027ve enabled the\n   `--error-exitcode=1` flag for `valgrind` in CI so that tests eagerly fail\n   in these scenarios.\n\n2. I\u0027ve written a quickcheck test to exercise `realloc`. Without the bug fix\n   in this patch, this quickcheck immediately triggers invalid reads when run\n   under `valgrind`. We didn\u0027t previously have quickchecks that exercised\n   `realloc` because `realloc` isn\u0027t publicly exposed directly, and instead\n   can only be indirectly called. This new quickcheck test exercises `realloc`\n   via `bumpalo::collections::Vec::resize` and\n   `bumpalo::collections::Vec::shrink_to_fit` calls.",
  "id": "RUSTSEC-2020-0006",
  "modified": "2023-06-13T13:10:24Z",
  "published": "2020-03-24T12:00:00Z",
  "references": [
    {
      "type": "PACKAGE",
      "url": "https://crates.io/crates/bumpalo"
    },
    {
      "type": "ADVISORY",
      "url": "https://rustsec.org/advisories/RUSTSEC-2020-0006.html"
    },
    {
      "type": "REPORT",
      "url": "https://github.com/fitzgen/bumpalo/issues/69"
    }
  ],
  "related": [],
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Flaw in `realloc` allows reading unknown memory"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

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

Sightings and recorded dates, grouped by day · UTC

JSON
How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.