cve-2022-24826
Vulnerability from cvelistv5
Published
2022-04-19 23:35
Modified
2024-08-03 04:20
Severity ?
9.8 (Critical) - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Summary
On Windows, if Git LFS operates on a malicious repository with a `..exe` file as well as a file named `git.exe`, and `git.exe` is not found in `PATH`, the `..exe` program will be executed, permitting the attacker to execute arbitrary code. This does not affect Unix systems. Similarly, if the malicious repository contains files named `..exe` and `cygpath.exe`, and `cygpath.exe` is not found in `PATH`, the `..exe` program will be executed when certain Git LFS commands are run. More generally, if the current working directory contains any file with a base name of `.` and a file extension from `PATHEXT` (except `.bat` and `.cmd`), and also contains another file with the same base name as a program Git LFS intends to execute (such as `git`, `cygpath`, or `uname`) and any file extension from `PATHEXT` (including `.bat` and `.cmd`), then, on Windows, when Git LFS attempts to execute the intended program the `..exe`, `..com`, etc., file will be executed instead, but only if the intended program is not found in any directory listed in `PATH`. The vulnerability occurs because when Git LFS detects that the program it intends to run does not exist in any directory listed in `PATH` then Git LFS passes an empty string as the executable file path to the Go `os/exec` package, which contains a bug such that, on Windows, it prepends the name of the current working directory (i.e., `.`) to the empty string without adding a path separator, and as a result searches in that directory for a file with the base name `.` combined with any file extension from `PATHEXT`, executing the first one it finds. (The reason `..bat` and `..cmd` files are not executed in the same manner is that, although the Go `os/exec` package tries to execute them just as it does a `..exe` file, the Microsoft Win32 API `CreateProcess()` family of functions have an undocumented feature in that they apparently recognize when a caller is attempting to execute a batch script file and instead run the `cmd.exe` command interpreter, passing the full set of command line arguments as parameters. These are unchanged from the command line arguments set by Git LFS, and as such, the intended program's name is the first, resulting in a command line like `cmd.exe /c git`, which then fails.) Git LFS has resolved this vulnerability by always reporting an error when a program is not found in any directory listed in `PATH` rather than passing an empty string to the Go `os/exec` package in this case. The bug in the Go `os/exec` package has been reported to the Go project and is expected to be patched after this security advisory is published. The problem was introduced in version 2.12.1 and is patched in version 3.1.3. Users of affected versions should upgrade to version 3.1.3. There are currently no known workarounds at this time.
References
security-advisories@github.comhttps://github.com/git-lfs/git-lfs/releasesThird Party Advisory
security-advisories@github.comhttps://github.com/git-lfs/git-lfs/security/advisories/GHSA-6rw3-3whw-jvjjThird Party Advisory
af854a3a-2127-422b-91ae-364da2661108https://github.com/git-lfs/git-lfs/releasesThird Party Advisory
af854a3a-2127-422b-91ae-364da2661108https://github.com/git-lfs/git-lfs/security/advisories/GHSA-6rw3-3whw-jvjjThird Party Advisory
Impacted products
Vendor Product Version
git-lfs git-lfs Version: 3.1.3
 Create a notification for this product.
Show details on NVD website

To clipboard 

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-03T04:20:50.511Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "tags": [
              "x_refsource_MISC",
              "x_transferred"
            ],
            "url": "https://github.com/git-lfs/git-lfs/releases"
          },
          {
            "tags": [
              "x_refsource_CONFIRM",
              "x_transferred"
            ],
            "url": "https://github.com/git-lfs/git-lfs/security/advisories/GHSA-6rw3-3whw-jvjj"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "git-lfs",
          "vendor": "git-lfs",
          "versions": [
            {
              "status": "affected",
              "version": "3.1.3"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "On Windows, if Git LFS operates on a malicious repository with a `..exe` file as well as a file named `git.exe`, and `git.exe` is not found in `PATH`, the `..exe` program will be executed, permitting the attacker to execute arbitrary code. This does not affect Unix systems. Similarly, if the malicious repository contains files named `..exe` and `cygpath.exe`, and `cygpath.exe` is not found in `PATH`, the `..exe` program will be executed when certain Git LFS commands are run. More generally, if the current working directory contains any file with a base name of `.` and a file extension from `PATHEXT` (except `.bat` and `.cmd`), and also contains another file with the same base name as a program Git LFS intends to execute (such as `git`, `cygpath`, or `uname`) and any file extension from `PATHEXT` (including `.bat` and `.cmd`), then, on Windows, when Git LFS attempts to execute the intended program the `..exe`, `..com`, etc., file will be executed instead, but only if the intended program is not found in any directory listed in `PATH`. The vulnerability occurs because when Git LFS detects that the program it intends to run does not exist in any directory listed in `PATH` then Git LFS passes an empty string as the executable file path to the Go `os/exec` package, which contains a bug such that, on Windows, it prepends the name of the current working directory (i.e., `.`) to the empty string without adding a path separator, and as a result searches in that directory for a file with the base name `.` combined with any file extension from `PATHEXT`, executing the first one it finds. (The reason `..bat` and `..cmd` files are not executed in the same manner is that, although the Go `os/exec` package tries to execute them just as it does a `..exe` file, the Microsoft Win32 API `CreateProcess()` family of functions have an undocumented feature in that they apparently recognize when a caller is attempting to execute a batch script file and instead run the `cmd.exe` command interpreter, passing the full set of command line arguments as parameters. These are unchanged from the command line arguments set by Git LFS, and as such, the intended program\u0027s name is the first, resulting in a command line like `cmd.exe /c git`, which then fails.) Git LFS has resolved this vulnerability by always reporting an error when a program is not found in any directory listed in `PATH` rather than passing an empty string to the Go `os/exec` package in this case. The bug in the Go `os/exec` package has been reported to the Go project and is expected to be patched after this security advisory is published. The problem was introduced in version 2.12.1 and is patched in version 3.1.3. Users of affected versions should upgrade to version 3.1.3. There are currently no known workarounds at this time."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 9.8,
            "baseSeverity": "CRITICAL",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-426",
              "description": "CWE-426: Untrusted Search Path",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2022-04-19T23:35:10",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/git-lfs/git-lfs/releases"
        },
        {
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/git-lfs/git-lfs/security/advisories/GHSA-6rw3-3whw-jvjj"
        }
      ],
      "source": {
        "advisory": "GHSA-6rw3-3whw-jvjj",
        "discovery": "UNKNOWN"
      },
      "title": "Git LFS can execute a binary from the current directory on Windows",
      "x_legacyV4Record": {
        "CVE_data_meta": {
          "ASSIGNER": "security-advisories@github.com",
          "ID": "CVE-2022-24826",
          "STATE": "PUBLIC",
          "TITLE": "Git LFS can execute a binary from the current directory on Windows"
        },
        "affects": {
          "vendor": {
            "vendor_data": [
              {
                "product": {
                  "product_data": [
                    {
                      "product_name": "git-lfs",
                      "version": {
                        "version_data": [
                          {
                            "version_value": "3.1.3"
                          }
                        ]
                      }
                    }
                  ]
                },
                "vendor_name": "git-lfs"
              }
            ]
          }
        },
        "data_format": "MITRE",
        "data_type": "CVE",
        "data_version": "4.0",
        "description": {
          "description_data": [
            {
              "lang": "eng",
              "value": "On Windows, if Git LFS operates on a malicious repository with a `..exe` file as well as a file named `git.exe`, and `git.exe` is not found in `PATH`, the `..exe` program will be executed, permitting the attacker to execute arbitrary code. This does not affect Unix systems. Similarly, if the malicious repository contains files named `..exe` and `cygpath.exe`, and `cygpath.exe` is not found in `PATH`, the `..exe` program will be executed when certain Git LFS commands are run. More generally, if the current working directory contains any file with a base name of `.` and a file extension from `PATHEXT` (except `.bat` and `.cmd`), and also contains another file with the same base name as a program Git LFS intends to execute (such as `git`, `cygpath`, or `uname`) and any file extension from `PATHEXT` (including `.bat` and `.cmd`), then, on Windows, when Git LFS attempts to execute the intended program the `..exe`, `..com`, etc., file will be executed instead, but only if the intended program is not found in any directory listed in `PATH`. The vulnerability occurs because when Git LFS detects that the program it intends to run does not exist in any directory listed in `PATH` then Git LFS passes an empty string as the executable file path to the Go `os/exec` package, which contains a bug such that, on Windows, it prepends the name of the current working directory (i.e., `.`) to the empty string without adding a path separator, and as a result searches in that directory for a file with the base name `.` combined with any file extension from `PATHEXT`, executing the first one it finds. (The reason `..bat` and `..cmd` files are not executed in the same manner is that, although the Go `os/exec` package tries to execute them just as it does a `..exe` file, the Microsoft Win32 API `CreateProcess()` family of functions have an undocumented feature in that they apparently recognize when a caller is attempting to execute a batch script file and instead run the `cmd.exe` command interpreter, passing the full set of command line arguments as parameters. These are unchanged from the command line arguments set by Git LFS, and as such, the intended program\u0027s name is the first, resulting in a command line like `cmd.exe /c git`, which then fails.) Git LFS has resolved this vulnerability by always reporting an error when a program is not found in any directory listed in `PATH` rather than passing an empty string to the Go `os/exec` package in this case. The bug in the Go `os/exec` package has been reported to the Go project and is expected to be patched after this security advisory is published. The problem was introduced in version 2.12.1 and is patched in version 3.1.3. Users of affected versions should upgrade to version 3.1.3. There are currently no known workarounds at this time."
            }
          ]
        },
        "impact": {
          "cvss": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 9.8,
            "baseSeverity": "CRITICAL",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          }
        },
        "problemtype": {
          "problemtype_data": [
            {
              "description": [
                {
                  "lang": "eng",
                  "value": "CWE-426: Untrusted Search Path"
                }
              ]
            }
          ]
        },
        "references": {
          "reference_data": [
            {
              "name": "https://github.com/git-lfs/git-lfs/releases",
              "refsource": "MISC",
              "url": "https://github.com/git-lfs/git-lfs/releases"
            },
            {
              "name": "https://github.com/git-lfs/git-lfs/security/advisories/GHSA-6rw3-3whw-jvjj",
              "refsource": "CONFIRM",
              "url": "https://github.com/git-lfs/git-lfs/security/advisories/GHSA-6rw3-3whw-jvjj"
            }
          ]
        },
        "source": {
          "advisory": "GHSA-6rw3-3whw-jvjj",
          "discovery": "UNKNOWN"
        }
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2022-24826",
    "datePublished": "2022-04-19T23:35:11",
    "dateReserved": "2022-02-10T00:00:00",
    "dateUpdated": "2024-08-03T04:20:50.511Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2022-24826\",\"sourceIdentifier\":\"security-advisories@github.com\",\"published\":\"2022-04-20T00:16:50.903\",\"lastModified\":\"2024-11-21T06:51:11.050\",\"vulnStatus\":\"Modified\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"On Windows, if Git LFS operates on a malicious repository with a `..exe` file as well as a file named `git.exe`, and `git.exe` is not found in `PATH`, the `..exe` program will be executed, permitting the attacker to execute arbitrary code. This does not affect Unix systems. Similarly, if the malicious repository contains files named `..exe` and `cygpath.exe`, and `cygpath.exe` is not found in `PATH`, the `..exe` program will be executed when certain Git LFS commands are run. More generally, if the current working directory contains any file with a base name of `.` and a file extension from `PATHEXT` (except `.bat` and `.cmd`), and also contains another file with the same base name as a program Git LFS intends to execute (such as `git`, `cygpath`, or `uname`) and any file extension from `PATHEXT` (including `.bat` and `.cmd`), then, on Windows, when Git LFS attempts to execute the intended program the `..exe`, `..com`, etc., file will be executed instead, but only if the intended program is not found in any directory listed in `PATH`. The vulnerability occurs because when Git LFS detects that the program it intends to run does not exist in any directory listed in `PATH` then Git LFS passes an empty string as the executable file path to the Go `os/exec` package, which contains a bug such that, on Windows, it prepends the name of the current working directory (i.e., `.`) to the empty string without adding a path separator, and as a result searches in that directory for a file with the base name `.` combined with any file extension from `PATHEXT`, executing the first one it finds. (The reason `..bat` and `..cmd` files are not executed in the same manner is that, although the Go `os/exec` package tries to execute them just as it does a `..exe` file, the Microsoft Win32 API `CreateProcess()` family of functions have an undocumented feature in that they apparently recognize when a caller is attempting to execute a batch script file and instead run the `cmd.exe` command interpreter, passing the full set of command line arguments as parameters. These are unchanged from the command line arguments set by Git LFS, and as such, the intended program\u0027s name is the first, resulting in a command line like `cmd.exe /c git`, which then fails.) Git LFS has resolved this vulnerability by always reporting an error when a program is not found in any directory listed in `PATH` rather than passing an empty string to the Go `os/exec` package in this case. The bug in the Go `os/exec` package has been reported to the Go project and is expected to be patched after this security advisory is published. The problem was introduced in version 2.12.1 and is patched in version 3.1.3. Users of affected versions should upgrade to version 3.1.3. There are currently no known workarounds at this time.\"},{\"lang\":\"es\",\"value\":\"En Windows, si Git LFS opera en un repositorio malicioso con un archivo \\\"..exe\\\" as\u00ed como un archivo llamado \\\"git.exe\\\", y \\\"git.exe\\\" no se encuentra en \\\"PATH\\\", el programa \\\"..exe\\\" se ejecutar\u00e1, permitiendo al atacante ejecutar c\u00f3digo arbitrario. Esto no afecta a los sistemas Unix. Del mismo modo, si el repositorio malicioso contiene archivos llamados \\\"..exe\\\" y \\\"cygpath.exe\\\", y \\\"cygpath.exe\\\" no es encontrado en el \\\"PATH\\\", el programa \\\"..exe\\\" ser\u00e1 ejecutado cuando sean ejecutados determinados comandos Git LFS. M\u00e1s generalmente, si el directorio de trabajo actual contiene cualquier archivo con un nombre base de \\\".\\\" y una extensi\u00f3n de archivo de \\\"PATHEXT\\\" (excepto \\\".bat\\\" y \\\". cmd\\\"), y tambi\u00e9n contiene otro archivo con el mismo nombre base que un programa que Git LFS pretende ejecutar (como \\\"git\\\", \\\"cygpath\\\", o \\\"uname\\\") y cualquier extensi\u00f3n de archivo de \\\"PATHEXT\\\" (incluyendo \\\".bat\\\" y \\\".cmd\\\"), entonces, en Windows, cuando Git LFS intente ejecutar el programa previsto el archivo \\\"..exe\\\", \\\"..com\\\", etc., ser\u00e1 ejecutado en su lugar, pero s\u00f3lo si el programa deseado no es encontrado en ning\u00fan directorio de la lista \\\"PATH\\\". La vulnerabilidad ocurre porque cuando Git LFS detecta que el programa que pretende ejecutar no se presenta en ning\u00fan directorio listado en \\\"PATH\\\" entonces Git LFS pasa una cadena vac\u00eda como la ruta del archivo ejecutable al paquete Go \\\"os/exec\\\", que contiene un error tal que, en Windows, antepone el nombre del directorio de trabajo actual (es decir, \\\".\\\") a la cadena vac\u00eda sin a\u00f1adir un separador de ruta, y como resultado busca en ese directorio un archivo con el nombre base \\\".\\\" combinado con cualquier extensi\u00f3n de archivo de \\\"PATHEXT\\\", ejecutando el primero que encuentre. (La raz\u00f3n por la que los archivos \\\"..bat\\\" y \\\"..cmd\\\" no son ejecutados de la misma manera es que, aunque el paquete Go \\\"os/exec\\\" intenta ejecutarlos igual que un archivo \\\"..exe\\\", la familia de funciones \\\"CreateProcess()\\\" de la API de Microsoft Win32 presenta una caracter\u00edstica no documentada en la que aparentemente reconocen cuando quien llama est\u00e1 intentando ejecutar un archivo de script por lotes y en su lugar ejecutan el int\u00e9rprete de comandos \\\"cmd.exe\\\", pasando el conjunto completo de argumentos de la l\u00ednea de comandos como par\u00e1metros. Estos no son modificados con respecto a los argumentos de l\u00ednea de comandos establecidos por Git LFS, y como tal, el nombre del programa previsto es el primero, resultando en una l\u00ednea de comandos como \\\"cmd.exe /c git\\\", que entonces falla). Git LFS ha resuelto esta vulnerabilidad informando siempre de un error cuando un programa no es encontrado en ning\u00fan directorio listado en \\\"PATH\\\" en lugar de pasar una cadena vac\u00eda al paquete Go \\\"os/exec\\\" en este caso. El bug en el paquete Go \\\"os/exec\\\" ha sido reportado al proyecto Go y es esperado que sea parcheado despu\u00e9s de la publicaci\u00f3n de este aviso de seguridad. El problema fue introducido en versi\u00f3n 2.12.1 y est\u00e1 parcheado en la versi\u00f3n 3.1.3. Los usuarios de las versiones afectadas deben actualizar a la versi\u00f3n 3.1.3. Actualmente no se presentan medidas de mitigaci\u00f3n a este problema\"}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H\",\"baseScore\":9.8,\"baseSeverity\":\"CRITICAL\",\"attackVector\":\"NETWORK\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"NONE\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"HIGH\",\"integrityImpact\":\"HIGH\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":3.9,\"impactScore\":5.9},{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H\",\"baseScore\":7.8,\"baseSeverity\":\"HIGH\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"NONE\",\"userInteraction\":\"REQUIRED\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"HIGH\",\"integrityImpact\":\"HIGH\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":5.9}],\"cvssMetricV2\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"2.0\",\"vectorString\":\"AV:L/AC:M/Au:N/C:P/I:P/A:P\",\"baseScore\":4.4,\"accessVector\":\"LOCAL\",\"accessComplexity\":\"MEDIUM\",\"authentication\":\"NONE\",\"confidentialityImpact\":\"PARTIAL\",\"integrityImpact\":\"PARTIAL\",\"availabilityImpact\":\"PARTIAL\"},\"baseSeverity\":\"MEDIUM\",\"exploitabilityScore\":3.4,\"impactScore\":6.4,\"acInsufInfo\":false,\"obtainAllPrivilege\":false,\"obtainUserPrivilege\":false,\"obtainOtherPrivilege\":false,\"userInteractionRequired\":true}]},\"weaknesses\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Secondary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-426\"}]},{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-426\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:a:git_large_file_storage_project:git_large_file_storage:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"2.12.1\",\"versionEndExcluding\":\"3.1.3\",\"matchCriteriaId\":\"F8AB6200-A60A-4B2B-A090-0B9DEAA1407B\"}]}]}],\"references\":[{\"url\":\"https://github.com/git-lfs/git-lfs/releases\",\"source\":\"security-advisories@github.com\",\"tags\":[\"Third Party Advisory\"]},{\"url\":\"https://github.com/git-lfs/git-lfs/security/advisories/GHSA-6rw3-3whw-jvjj\",\"source\":\"security-advisories@github.com\",\"tags\":[\"Third Party Advisory\"]},{\"url\":\"https://github.com/git-lfs/git-lfs/releases\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Third Party Advisory\"]},{\"url\":\"https://github.com/git-lfs/git-lfs/security/advisories/GHSA-6rw3-3whw-jvjj\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Third Party Advisory\"]}]}}"
  }
}


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.