Описание
In Go before 1.10.6 and 1.11.x before 1.11.3, the "go get" command is vulnerable to remote code execution when executed with the -u flag and the import path of a malicious Go package, or a package that imports it directly or indirectly. Specifically, it is only vulnerable in GOPATH mode, but not in module mode (the distinction is documented at https://golang.org/cmd/go/#hdr-Module_aware_go_get). Using custom domains, it's possible to arrange things so that a Git repository is cloned to a folder named ".git" by using a vanity import path that ends with "/.git". If the Git repository root contains a "HEAD" file, a "config" file, an "objects" directory, a "refs" directory, with some work to ensure the proper ordering of operations, "go get -u" can be tricked into considering the parent directory as a repository root, and running Git commands on it. That will use the "config" file in the original Git repository root for its configuration, and if that config file contains malicious commands, they will execute on the system running "go get -u".
Отчет
This issue affects the version of golang package in Red Hat Enterprise Linux 7. The golang package, previously available in the Optional channel, will no longer receive updates in Red Hat Enterprise Linux 7. Developers are encouraged to use the Go Toolset instead, which is available through the Red Hat Developer program. https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/7.6_release_notes/chap-red_hat_enterprise_linux-7.6_release_notes-deprecated_functionality_in_rhel7#idm139716309923696
Затронутые пакеты
| Платформа | Пакет | Состояние | Рекомендация | Релиз |
|---|---|---|---|---|
| Red Hat Ceph Storage 2 | golang | Will not fix | ||
| Red Hat Ceph Storage 3 | golang | Will not fix | ||
| Red Hat Enterprise Linux 7 | golang | Will not fix | ||
| Red Hat Enterprise Linux 8 | go-toolset:rhel8/golang | Not affected | ||
| Red Hat OpenShift Container Platform 3.10 | atomic-openshift | Fix deferred | ||
| Red Hat OpenShift Container Platform 3.11 | atomic-openshift | Not affected | ||
| Red Hat OpenShift Container Platform 3.7 | atomic-openshift | Out of support scope | ||
| Red Hat OpenShift Container Platform 3.9 | atomic-openshift | Fix deferred | ||
| Red Hat OpenShift Container Platform 4 | openshift | Not affected | ||
| Red Hat OpenStack Platform 8 (Liberty) Operational Tools | golang | Will not fix |
Показывать по
Дополнительная информация
Статус:
EPSS
7.5 High
CVSS3
Связанные уязвимости
In Go before 1.10.6 and 1.11.x before 1.11.3, the "go get" command is vulnerable to remote code execution when executed with the -u flag and the import path of a malicious Go package, or a package that imports it directly or indirectly. Specifically, it is only vulnerable in GOPATH mode, but not in module mode (the distinction is documented at https://golang.org/cmd/go/#hdr-Module_aware_go_get). Using custom domains, it's possible to arrange things so that a Git repository is cloned to a folder named ".git" by using a vanity import path that ends with "/.git". If the Git repository root contains a "HEAD" file, a "config" file, an "objects" directory, a "refs" directory, with some work to ensure the proper ordering of operations, "go get -u" can be tricked into considering the parent directory as a repository root, and running Git commands on it. That will use the "config" file in the original Git repository root for its configuration, and if that config file contains malicious comma...
In Go before 1.10.6 and 1.11.x before 1.11.3, the "go get" command is vulnerable to remote code execution when executed with the -u flag and the import path of a malicious Go package, or a package that imports it directly or indirectly. Specifically, it is only vulnerable in GOPATH mode, but not in module mode (the distinction is documented at https://golang.org/cmd/go/#hdr-Module_aware_go_get). Using custom domains, it's possible to arrange things so that a Git repository is cloned to a folder named ".git" by using a vanity import path that ends with "/.git". If the Git repository root contains a "HEAD" file, a "config" file, an "objects" directory, a "refs" directory, with some work to ensure the proper ordering of operations, "go get -u" can be tricked into considering the parent directory as a repository root, and running Git commands on it. That will use the "config" file in the original Git repository root for its configuration, and if that config file contains malicious commands
In Go before 1.10.6 and 1.11.x before 1.11.3, the "go get" command is ...
In Go before 1.10.6 and 1.11.x before 1.11.3, the "go get" command is vulnerable to remote code execution when executed with the -u flag and the import path of a malicious Go package, or a package that imports it directly or indirectly. Specifically, it is only vulnerable in GOPATH mode, but not in module mode (the distinction is documented at https://golang.org/cmd/go/#hdr-Module_aware_go_get). Using custom domains, it's possible to arrange things so that a Git repository is cloned to a folder named ".git" by using a vanity import path that ends with "/.git". If the Git repository root contains a "HEAD" file, a "config" file, an "objects" directory, a "refs" directory, with some work to ensure the proper ordering of operations, "go get -u" can be tricked into considering the parent directory as a repository root, and running Git commands on it. That will use the "config" file in the original Git repository root for its configuration, and if that config file contains malicious comma...
Уязвимость реализации команды «go get» языка программирования Go, позволяющая нарушителю выполнить произвольный код
EPSS
7.5 High
CVSS3