* Bug: global remote.origin.url silently overrides git clone <URL>
@ 2023-05-26 8:28 Jan Krag
0 siblings, 0 replies; only message in thread
From: Jan Krag @ 2023-05-26 8:28 UTC (permalink / raw)
To: git
I have stumbled across some very unexpected behaviour in git related
to remote.origin.url. I initially reported it to the security mailing
list because of concern of possible exploits, but Glenn Choo and
Taylor Blau deemed that the issue was outside Git's security boundary,
and thus safe to discuss on the public list.
In short, I found out that if a user for some reason, either
intentionally/maliciously or unintentionally sets `remote.origin.url`
to a repo URL in their *global* config, then a subsequent `git
clone`operation will *silently* use this URL instead of the one
provided as the command line argument to `git clone`.
I believe this is unintentional behaviour, and not just a corner case
I haven’t thought of, because of the following observations:
* The folder name to clone to is still taken from the command-line specified URL
* Git still prints “cloning into…” and the folder name that the user specified
* Git sets sets the *local* `remote.origin.url` to the value provided
* However, Git fetches the actual repo content, and subsequent
workspace checkout, from the URL in the global config, without any
notification to the user.
Security implications: I believe that this behaviour could
theoretically be mis-used for supply-chain attacks, especially on a
build server, but Glenn and Taylor pointed out that if an attacker has
access to modify a global git config, then there are much worse things
they could do. Also, I realise that most build servers these days
don’t actually use `git clone` under normal operations (rather they
use git init, git remote add, git fetch) so the problem isn't that
severe.
If a team disables the regular build server fake cloning behaviour and
does actual cloning in e.g. a shell step for more control, an attacker
with access to pipelines running on the same build node, could
potentially set the global url to a malicious fork of a repo used in
other pipelines, and silently make the other pipelines clone this
forked and patched repo, and potentially execute code within.
What did you do before the bug happened? (Steps to reproduce your issue)
What happened instead? (Actual behaviour)
------------------------------------------------------------------
I discovered the problem in the wild, reproduced it on my Mac (see
later) and then went through the following controlled reproduction in
a Docker environment.
`docker run -it --entrypoint /bin/bash bitnami/git:2.19.2`
```
$ git config --global remote.origin.url https://github.com/JKrag/sc_demo.git
$ git clone https://github.com/eficode-academy/git-katas.git
Cloning into 'git-katas'...
$ cd git-katas
$ ls
README.md (i.e. content from sc_demo, not git-katas)
$ git remote show origin
* remote origin
Fetch URL: https://github.com/JKrag/sc_demo.git
Push URL: https://github.com/JKrag/sc_demo.git
Push URL: https://github.com/eficode-academy/git-katas.git
$ cat .git/config
...
[remote "origin"]
url = https://github.com/eficode-academy/git-katas.git
...
$ git config --list --show-origin |grep "remote\.origin"
file:/root/.gitconfig remote.origin.url=https://github.com/JKrag/sc_demo.git
file:.git/config
remote.origin.url=https://github.com/eficode-academy/git-katas.git
file:.git/config remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
$ git fetch
$ git status
On branch master
Your branch is up to date with 'origin/master'.
nothing to commit, working tree clean
$ git config --global --unset remote.origin.url
$ git status
On branch master
Your branch is up to date with 'origin/master'.
nothing to commit, working tree clean
$ git fetch
remote: Enumerating objects: 2443, done.
remote: Counting objects: 100% (1109/1109), done.
remote: Compressing objects: 100% (465/465), done.
remote: Total 2443 (delta 699), reused 674 (delta 642), pack-reused 1334
Receiving objects: 100% (2443/2443), 2.46 MiB | 6.29 MiB/s, done.
Resolving deltas: 100% (1052/1052), done.
From https://github.com/eficode-academy/git-katas
+ 398b171...8bc6cc8 master -> origin/master (forced update)
* [new branch] brent-clark-SED-Sw-Mgr/improve-overview ->
origin/brent-clark-SED-Sw-Mgr/improve-overview
* [new branch] improve-rebase-powershell -> origin/improve-rebase-powershell
* [new branch] pr-verify -> origin/pr-verify
* [new branch] reorder-instructions-unclear ->
origin/reorder-instructions-unclear
* [new branch] sofusalbertsen-patch-1 -> origin/sofusalbertsen-patch-1
* [new branch] sofusalbertsen-patch-2 -> origin/sofusalbertsen-patch-2
* [new branch] test-script -> origin/test-script
* [new branch] tree-vis -> origin/tree-vis
* [new branch] uppercase -> origin/uppercase
* [new tag] 0.1.1 -> 0.1.1
* [new tag] 0.2.0 -> 0.2.0
* [new tag] 0.3.0 -> 0.3.0
$ git rev-list --max-parents=0 --all
398b17173d150371977cc12d4406f927a4be32ea # Initial commit from sc-demo repo
ad31d12363a181b998317d5f075d89b3fb990122 # Initial commit from git-katas repo
```
What did you expect to happen? (Expected behaviour)
First off, I would expect that Git used the url specified on the
command line, as it is normal that command-line arguments override
both local and global configs.
Alternatively, if there really is a good reason to use the global
configured one, git should at least take the folder name from there
and print out “Cloning into [global configured repo name]”
In reality, I can’t see any reason why there would ever be a need to
configure global remote.origin.url, and ideally doing so could lead to
an error/warning message, but I also know that the philosophy behind
Git config is to basically allow any settings, and there is no natural
place to “stop” such entries, although I guess it might be reasonable
to expect a warning at least when cloning a new repo.
Anything else you want to add:
--------------------------------------------
Yes, I am aware that this is a very obscure scenario, and as an
experienced Git user, it had never crossed my mind that this could
happen, but I saw it “in the wild” a few weeks ago, when delivering a
2-day Git training. I asked the participants to clone our “git-katas”
repo (as in the reproduced scenario above), and then one participant
was VERY confused because the folder then had “her own code”, and she
couldn’t understand why. After going through her bash history and
verifying that there was no other good explanation, I finally found
the explanation by looking in the global config where I found the
unexpected setting. The user had no real idea how it had gotten there,
except some vague idea of having tried “some stuff” to fix “some
issue” a long time ago. Since she only used a single repo on her
computer, she would never really have noticed under normal conditions.
Platform:
----------------
Problem originally seen “in the wild” on an Ubuntu laptop running Git
2.17 as I recall.
Issue reproduced on OSX Git 2.39.2, and in docker containers running
2.19.2 and 2.40.
[ Local Mac ]
[System Info]
git version:
git version 2.39.2
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Darwin 22.4.0 Darwin Kernel Version 22.4.0: Mon Mar 6 21:00:17
PST 2023; root:xnu-8796.101.5~3/RELEASE_X86_64 x86_64
compiler info: clang: 14.0.0 (clang-1400.0.29.202)
libc info: no libc information available
$SHELL (typically, interactive shell): /bin/zsh
[ Bitnami/git:2:40 ]
$ docker run -it --entrypoint /bin/bash bitnami/git:2.40.0
root@89543b59ce2c:/# git version --build-options
git version 2.40.0
cpu: x86_64
$SHELL = /bin/bash
[ Bitnami/git:2.19.2 ]
$ docker run -it --entrypoint /bin/bash bitnami/git:2.19.2
root@6a86a5c92e58:/# git version --build-options
git version 2.19.2
cpu: x86_64
$SHELL = /bin/bash
$ uname -a
Linux 6a86a5c92e58 5.15.49-linuxkit #1 SMP Tue Sep 13 07:51:46 UTC
2022 x86_64 GNU/Linux
Regards Jan
-----------------------
Jan Krag
Git Trainer & DevOps Consultant
jan.krag@eficode.com
www.eficode.com
Copenhagen, Denmark
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2023-05-26 8:28 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-05-26 8:28 Bug: global remote.origin.url silently overrides git clone <URL> Jan Krag
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).