Message ID | 20220505005009.27789-1-carenas@gmail.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [v2] setup: tighten ownership checks post CVE-2022-24765 | expand |
Hi Carlo On 05/05/2022 01:50, Carlo Marcelo Arenas Belón wrote: > 8959555cee7 (setup_git_directory(): add an owner check for the top-level > directory, 2022-03-02), adds a function to check for ownership of > repositories using a directory that is representative of it (its workdir) > and ways to add it to an exception list if needed, but that check breaks > when the ownership of the workdir is not the same than the ownership of > directory where the configuration and other relevant files reside. > > An attacker could create a git repository in a directory that he has write > access to but is owned by the victim, and therefore workaround the fix that > was introduced with CVE-2022-24765 to attack them, like in the following > scenario which could result in privilege escalation if root then runs a git > command in that directory or any of its sub directories: > > $ git -C /tmp init > > To avoid that, extend the ensure_valid_ownership function to be able to > check for ownership of both the worktree and the gitdir, and use that for > non bare repositories. Looking at the code below it now only ever checks the ownership of the gitdir, it no longer checks the ownership of the worktree. I haven't really thought through what happens if I cd into a worktree added by an attacker to a repository that I own which has extentions.worktreeConfig set. My initial thought is that if they can add a worktree then they can probably edit the repository config anyway but I wonder if an attacker can set GIT_COMMON_DIR to a directory where they have write permission to add a worktree to a repository where they don't have write permission. > [...] > diff --git a/setup.c b/setup.c > index aad9ace0af9..0fae2d71a3c 100644 > --- a/setup.c > +++ b/setup.c > @@ -1054,14 +1054,21 @@ static int safe_directory_cb(const char *key, const char *value, void *d) > return 0; > } > > -static int ensure_valid_ownership(const char *path) > +static int ensure_valid_ownership(const char *worktree, const char *gitdir) > { > - struct safe_directory_data data = { .path = path }; > + struct safe_directory_data data = { .path = worktree }; We keep checking the worktree path against safe.directory - good. > + const char *check_path; > + > + if (gitdir) > + check_path = gitdir; > + else > + check_path = worktree; We check either the gitdir or worktree but always call this function with a non-NULL gitdir so in fact always check that. This code could be removed. > if (!git_env_bool("GIT_TEST_ASSUME_DIFFERENT_OWNER", 0) && > - is_path_owned_by_current_user(path)) > + is_path_owned_by_current_user(check_path)) Previously we checked the ownership of the worktree but now we check the ownership of the gitdir instead to handle the "git -C /tmp init" case. > return 1; > > + data.is_safe = 0; /* ensure we are initialized and secure by default */ > read_very_early_config(safe_directory_cb, &data); > > return data.is_safe; > @@ -1166,14 +1173,25 @@ static enum discovery_result setup_git_directory_gently_1(struct strbuf *dir, > } > strbuf_setlen(dir, offset); > if (gitdirenv) { > - if (!ensure_valid_ownership(dir->buf)) > + const char *gitdir_to_check = gitdirenv; > + struct strbuf gdbuf = STRBUF_INIT; > + int ret; > + > + if (!is_absolute_path(gitdirenv)) { > + strbuf_addf(&gdbuf, "%s/%s", dir->buf, > + gitdirenv); > + gitdir_to_check = gdbuf.buf; > + } > + ret = ensure_valid_ownership(dir->buf, gitdir_to_check); > + strbuf_release(&gdbuf); > + if (!ret) > return GIT_DIR_INVALID_OWNERSHIP; > strbuf_addstr(gitdir, gitdirenv); > return GIT_DIR_DISCOVERED; > } > > if (is_git_directory(dir->buf)) { > - if (!ensure_valid_ownership(dir->buf)) > + if (!ensure_valid_ownership(NULL, dir->buf)) Previously we checked bare repositories against safe.directory now we no longer do that as worktree is NULL. If this is intentional it should be flagged up in the commit message. Best Wishes Phillip > return GIT_DIR_INVALID_OWNERSHIP; > strbuf_addstr(gitdir, "."); > return GIT_DIR_BARE; > diff --git a/t/t0034-root-safe-directory.sh b/t/t0034-root-safe-directory.sh > index a68e1d7602b..a3ddebb009a 100755 > --- a/t/t0034-root-safe-directory.sh > +++ b/t/t0034-root-safe-directory.sh > @@ -47,6 +47,35 @@ test_expect_success SUDO 'sudo git status as original owner' ' > ) > ' > > +test_expect_success SUDO 'unsecure worktree with non bare repository' ' > + sudo rm -rf root && > + sudo mkdir -p root/t && > + sudo chmod 1777 root/t && > + ( > + cd root/t && > + git init && > + git status && > + sudo git status && > + run_with_sudo <<-END > + unset SUDO_UID && > + ! git status > + END > + ) > +' > + > +test_expect_success SUDO 'non bare repository using a gitfile' ' > + sudo rm -rf root && > + mkdir -p root/w && > + mkdir -p root/e && > + ( > + cd root/w && > + git init --separate-git-dir ../e && > + git status && > + sudo chown -R root ../e && > + test_must_fail git status > + ) > +' > + > # this destroys the test environment used above > test_expect_success SUDO 'cleanup regression' ' > sudo rm -rf root
On 05/05/2022 10:40, Phillip Wood wrote: > [...] >> To avoid that, extend the ensure_valid_ownership function to be able to >> check for ownership of both the worktree and the gitdir, and use that for >> non bare repositories. > > Looking at the code below it now only ever checks the ownership of the > gitdir, it no longer checks the ownership of the worktree. I haven't > really thought through what happens if I cd into a worktree added by an > attacker to a repository that I own which has extentions.worktreeConfig > set. My initial thought is that if they can add a worktree then they can > probably edit the repository config anyway but I wonder if an attacker > can set GIT_COMMON_DIR to a directory where they have write permission > to add a worktree to a repository where they don't have write permission. Thinking about this some more, I don't think setting GIT_COMMON_DIR while running "git worktree add" will help an attacker as the worktree's gitdir is created under the main gitdir. I've had a bit of a think and I've not been able to come up with a senario where GIT_DIR and GIT_COMMON_DIR have different owners that is exploitable but it might be worth someone else checking I've not missed something. Best Wishes Phillip
On 5/4/2022 8:50 PM, Carlo Marcelo Arenas Belón wrote: > 8959555cee7 (setup_git_directory(): add an owner check for the top-level > directory, 2022-03-02), adds a function to check for ownership of > repositories using a directory that is representative of it (its workdir) > and ways to add it to an exception list if needed, but that check breaks > when the ownership of the workdir is not the same than the ownership of > directory where the configuration and other relevant files reside. > > An attacker could create a git repository in a directory that he has write > access to but is owned by the victim, and therefore workaround the fix that > was introduced with CVE-2022-24765 to attack them, It's worth noting that this requires having the current user owning a directory, but allowing other users to write into it. > [...] like in the following > scenario which could result in privilege escalation if root then runs a git > command in that directory or any of its sub directories: > > $ git -C /tmp init This /tmp example is an example of why that is actually common, and not just a "user misconfigured their machine" issue. > To avoid that, extend the ensure_valid_ownership function to be able to > check for ownership of both the worktree and the gitdir, and use that for > non bare repositories. You mention extending the check here, but... > -static int ensure_valid_ownership(const char *path) > +static int ensure_valid_ownership(const char *worktree, const char *gitdir) > { > - struct safe_directory_data data = { .path = path }; > + struct safe_directory_data data = { .path = worktree }; > + const char *check_path; > + > + if (gitdir) > + check_path = gitdir; > + else > + check_path = worktree; ...this makes it appear like you are choosing to check only _one_ of the directories, not _both_, which is what I would expect for a strengthening of our security checks. > if (!git_env_bool("GIT_TEST_ASSUME_DIFFERENT_OWNER", 0) && > - is_path_owned_by_current_user(path)) > + is_path_owned_by_current_user(check_path)) > return 1; Indeed, we are checking only one of these directories for ownership. I think you should remove check_path and instead do the following: if (!git_env_bool("GIT_TEST_ASSUME_DIFFERENT_OWNER", 0) && is_path_owned_by_current_user(worktree) && (!gitdir || is_path_owned_by_current_user(gitdir))) return 1; Thanks, -Stolee
On 5/5/2022 9:14 AM, Derrick Stolee wrote: > On 5/4/2022 8:50 PM, Carlo Marcelo Arenas Belón wrote: >> -static int ensure_valid_ownership(const char *path) >> +static int ensure_valid_ownership(const char *worktree, const char *gitdir) >> { >> - struct safe_directory_data data = { .path = path }; >> + struct safe_directory_data data = { .path = worktree }; This also seems a bit backwards to me. I think bare repos will have a NULL worktree, but all repos will have a gitdir. I think what we really want is this: .path = worktree ? worktree : gitdir And that might affect the callers of this method allowing the worktree to be NULL. > I think you should remove check_path and instead do the following: > > if (!git_env_bool("GIT_TEST_ASSUME_DIFFERENT_OWNER", 0) && > is_path_owned_by_current_user(worktree) && > (!gitdir || is_path_owned_by_current_user(gitdir))) > return 1; But that changes my logic here to instead be if (!git_env_bool("GIT_TEST_ASSUME_DIFFERENT_OWNER", 0) && is_path_owned_by_current_user(gitdir) && (!worktree|| is_path_owned_by_current_user(worktree))) return 1; Thanks, -Stolee
diff --git a/setup.c b/setup.c index aad9ace0af9..0fae2d71a3c 100644 --- a/setup.c +++ b/setup.c @@ -1054,14 +1054,21 @@ static int safe_directory_cb(const char *key, const char *value, void *d) return 0; } -static int ensure_valid_ownership(const char *path) +static int ensure_valid_ownership(const char *worktree, const char *gitdir) { - struct safe_directory_data data = { .path = path }; + struct safe_directory_data data = { .path = worktree }; + const char *check_path; + + if (gitdir) + check_path = gitdir; + else + check_path = worktree; if (!git_env_bool("GIT_TEST_ASSUME_DIFFERENT_OWNER", 0) && - is_path_owned_by_current_user(path)) + is_path_owned_by_current_user(check_path)) return 1; + data.is_safe = 0; /* ensure we are initialized and secure by default */ read_very_early_config(safe_directory_cb, &data); return data.is_safe; @@ -1166,14 +1173,25 @@ static enum discovery_result setup_git_directory_gently_1(struct strbuf *dir, } strbuf_setlen(dir, offset); if (gitdirenv) { - if (!ensure_valid_ownership(dir->buf)) + const char *gitdir_to_check = gitdirenv; + struct strbuf gdbuf = STRBUF_INIT; + int ret; + + if (!is_absolute_path(gitdirenv)) { + strbuf_addf(&gdbuf, "%s/%s", dir->buf, + gitdirenv); + gitdir_to_check = gdbuf.buf; + } + ret = ensure_valid_ownership(dir->buf, gitdir_to_check); + strbuf_release(&gdbuf); + if (!ret) return GIT_DIR_INVALID_OWNERSHIP; strbuf_addstr(gitdir, gitdirenv); return GIT_DIR_DISCOVERED; } if (is_git_directory(dir->buf)) { - if (!ensure_valid_ownership(dir->buf)) + if (!ensure_valid_ownership(NULL, dir->buf)) return GIT_DIR_INVALID_OWNERSHIP; strbuf_addstr(gitdir, "."); return GIT_DIR_BARE; diff --git a/t/t0034-root-safe-directory.sh b/t/t0034-root-safe-directory.sh index a68e1d7602b..a3ddebb009a 100755 --- a/t/t0034-root-safe-directory.sh +++ b/t/t0034-root-safe-directory.sh @@ -47,6 +47,35 @@ test_expect_success SUDO 'sudo git status as original owner' ' ) ' +test_expect_success SUDO 'unsecure worktree with non bare repository' ' + sudo rm -rf root && + sudo mkdir -p root/t && + sudo chmod 1777 root/t && + ( + cd root/t && + git init && + git status && + sudo git status && + run_with_sudo <<-END + unset SUDO_UID && + ! git status + END + ) +' + +test_expect_success SUDO 'non bare repository using a gitfile' ' + sudo rm -rf root && + mkdir -p root/w && + mkdir -p root/e && + ( + cd root/w && + git init --separate-git-dir ../e && + git status && + sudo chown -R root ../e && + test_must_fail git status + ) +' + # this destroys the test environment used above test_expect_success SUDO 'cleanup regression' ' sudo rm -rf root
8959555cee7 (setup_git_directory(): add an owner check for the top-level directory, 2022-03-02), adds a function to check for ownership of repositories using a directory that is representative of it (its workdir) and ways to add it to an exception list if needed, but that check breaks when the ownership of the workdir is not the same than the ownership of directory where the configuration and other relevant files reside. An attacker could create a git repository in a directory that he has write access to but is owned by the victim, and therefore workaround the fix that was introduced with CVE-2022-24765 to attack them, like in the following scenario which could result in privilege escalation if root then runs a git command in that directory or any of its sub directories: $ git -C /tmp init To avoid that, extend the ensure_valid_ownership function to be able to check for ownership of both the worktree and the gitdir, and use that for non bare repositories. Reported-by: Hanno Böck <hanno@hboeck.de> Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> --- Changes since RFC * remove debug code from ensure_valid_ownership since is no longer needed * replace convoluted logic in setup_git_directory_gently_1 with Junio's * improve tests (AGAIN, not considered production and only for convenience) * hopefully improved commit message and spelling. The changes in setup.c should be sufficient to cover for all known issues, but has been only lightly tested and mostly in *NIX, so more changes might be needed to cover Windows. Specially the use of "/" to reconstruct the gitdir based on the previously cut workdir might be problematic if not covered by its compat code. The code for setup_git_directory_gently_1 is inefficient (as pointed by dscho) and could be improved by instead reusing the buffer before it is cut by the setlen, but if doing so, then a copy of the full gitdir will be needed, so a solution for that is not provided. In the same line, we already know before getting into the condition, if we are coming from a gitfile or not, so the is_absolute_path(gitdirenv) could be optimized away, like it was done in the RFC with an incorrectly named is_bare boolean, but that change hasn't been implemented as the cost of the current implementation is unknown and feels like premature optimization. Slightly off-topic and maybe more of an ADMINISTRATIVE, but had added the Reported-by for the guy that came with the last report, not sure what the right procedure is, and might be better if kept as a note, but be careful of git send-email to avoid leaks, at least until we have a final version. setup.c | 28 +++++++++++++++++++++++----- t/t0034-root-safe-directory.sh | 29 +++++++++++++++++++++++++++++ 2 files changed, 52 insertions(+), 5 deletions(-)