Re: Git remote origin leaks user access token

Re: Git remote origin leaks user access token

[Jonathan Nieder]

(+cc: git@vger.kernel.org, git-security -> bcc)
Hi!

limin wrote:

> Hi, I found a potential security issue when running a tool in my private
> project. I think this exposes my personal access token to danger when using
> "git remote get-url origin".

I'm moving this conversation to the public Git mailing list, as this
behavior is well known.

I look forward to working together on ways to reduce the impact (for
example, ways to encourage people to use their system's password
keychain instead of including credentials in URLs).

Report left unsnipped below, for reference.

Thanks,
Jonathan

> Version
>
> 2.45.2
>
> Description
>
> Lots of people are using personal access token to clone their private
> repository. To use a access token, you can include your username and token
> in https url to clone projects on github, gitlab or any other DevOps
> Platform:
>
> git clone https://<username>:<token>@github.com/username/repository.git
>
> However, we can get the token back easily by just using git remote get-url
> origin.
>
> cd privateProject
> git remote get-url origin
> > https://username:ghp_xxxxx@github.com/username/repository.git
>
> This can be dangerous, because we often run third party tools in our
> private repository. If a malicious tool runs git remote get-url origin, it
> can steal our personal access token of github/gitlab. In this case, our
> github/gitlab will be controlled by attackers which can have severe
> consequences.
>
> I found this issue during code auditing via safety tool
> <https://github.com/pyupio/safety>. After scanning a project using safety
> check -r requirements.txt --save-json test.json, safety saved results into
> test.json file. However, when I looked into test.json, I found my personal
> access token in this file.
>
> "report_meta": {
>     "scan_target": "files",
>     "scanned": [
>         "/home/kali/huntr/azure-sdk-for-python/tools/azure-sdk-tools/ci_tools/versioning/requirements.txt"
>     ],
>     "target_languages": [
>         "python"
>     ],
>     "git": {
>         "branch": "main",
>         "tag": "",
>         "commit": "b182b0c4f9d07d18f118130bc941c3b7a75667b1",
>         "dirty": false,
>         "origin": "https://outh2:ghp_xxxx@github.com/sunriseXu/xxxx.git"
>     },
> }
>
> So, I looked into the source code of safety. The class GIT
> <https://github.com/pyupio/safety/blob/f15d7908d27fd887dcc6b31237b8e3df79a9359b/safety/scan/util.py#L49>
> is
> responsible for collecting repository information in current repo where
> safety runs.
>
> class GIT:
>     ORIGIN_CMD: Tuple[str, ...] = ("remote", "get-url", "origin")
>     def __run__(self, cmd: Tuple[str, ...], env_var: Optional[str] =
> None) -> Optional[str]:
>         if env_var and os.environ.get(env_var):
>             return os.environ.get(env_var)
>
>         try:
>             return subprocess.run(self.git + cmd, stdout=subprocess.PIPE,
>
> stderr=subprocess.DEVNULL).stdout.decode('utf-8').strip()
>         except Exception as e:
>             LOG.exception(e)
>
>         return None
>     def origin(self) -> Optional[str]:
>         # get the origin of repository
>         return self.__run__(self.ORIGIN_CMD, env_var="SAFETY_GIT_ORIGIN")
>
> Impact
>
> This can have severe consequences. *Any* tools running in private
> repositories have ability to steal personal access token if the token is
> written in git remote url explicitly. Git should mask user’s access token
> when using cli command git remote get-url origin.

Re: Git remote origin leaks user access token

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 2759 bytes --]

On 2024-07-01 at 11:46:03, Jonathan Nieder wrote:
> (+cc: git@vger.kernel.org, git-security -> bcc)
> Hi!
> 
> limin wrote:
> 
> > Hi, I found a potential security issue when running a tool in my private
> > project. I think this exposes my personal access token to danger when using
> > "git remote get-url origin".
> 
> I'm moving this conversation to the public Git mailing list, as this
> behavior is well known.
> 
> I look forward to working together on ways to reduce the impact (for
> example, ways to encourage people to use their system's password
> keychain instead of including credentials in URLs).

I'll point out that we already document this in the Git FAQ (git help
gitfaq):

----
How do I specify my credentials when pushing over HTTP?

The easiest way to do this is to use a credential helper via the
`credential.helper` configuration.  Most systems provide a standard
choice to integrate with the system credential manager.  For example,
Git for Windows provides the `wincred` credential manager, macOS has the
`osxkeychain` credential manager, and Unix systems with a standard
desktop environment can use the `libsecret` credential manager.  All of
these store credentials in an encrypted store to keep your passwords or
tokens secure.

In addition, you can use the `store` credential manager which stores in a file
in your home directory, or the `cache` credential manager, which does not
permanently store your credentials, but does prevent you from being prompted for
them for a certain period of time.

You can also just enter your password when prompted.  While it is possible to
place the password (which must be percent-encoded) in the URL, this is not
particularly secure and can lead to accidental exposure of credentials, so it is
not recommended.
----

We also have a FAQ entry about how to read credentials from the
environment as well, since that's a common thing people want to do.

I also recently added support for putting credentials that are not
username and password (e.g., Bearer tokens) in credential helpers
specifically for this purpose, since people were using
`http.extraHeader` for this, which is equally insecure.

I do want to point out that several people, not just me, have worked
together to make using a credential helper as easy and robust as
possible.  I mention this not to contradict Jonathan, who I think is
also trying to help in this regard, but mostly to mention that as a
project we've been trying to gently nudge people into doing the more
secure thing.  If people have further suggestions on how to make this
easier for users in the future, I'm very eager to hear them.
-- 
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: Git remote origin leaks user access token

[Jeff King]

On Mon, Jul 01, 2024 at 04:27:43PM +0000, brian m. carlson wrote:

> I do want to point out that several people, not just me, have worked
> together to make using a credential helper as easy and robust as
> possible.  I mention this not to contradict Jonathan, who I think is
> also trying to help in this regard, but mostly to mention that as a
> project we've been trying to gently nudge people into doing the more
> secure thing.  If people have further suggestions on how to make this
> easier for users in the future, I'm very eager to hear them.

One thing we could do is refuse to store credentials in plaintext
config. That helps people who aren't aware of the recommendations you
mentioned end up more secure (though at the expense of convenience, as
subsequent fetches won't work if you don't have a credential helper set
up).

Some old discussion and possible patches here if anybody wants to pick
up the topic:

  https://lore.kernel.org/git/nycvar.QRO.7.76.6.1905172121130.46@tvgsbejvaqbjf.bet/

-Peff

Re: Git remote origin leaks user access token

[Junio C Hamano]

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> I'll point out that we already document this in the Git FAQ (git help
> gitfaq):
>
> ----
> How do I specify my credentials when pushing over HTTP?
> ...
>
> We also have a FAQ entry about how to read credentials from the
> environment as well, since that's a common thing people want to do.
> ...
>
> I do want to point out that several people, not just me, have worked
> together to make using a credential helper as easy and robust as
> possible.  I mention this not to contradict Jonathan, who I think is
> also trying to help in this regard, but mostly to mention that as a
> project we've been trying to gently nudge people into doing the more
> secure thing.

Two and a half things.

 - Perhaps we want to explicitly single out URLs that embed
   credential in the documentation and tell readers not to use that.
   I wonder if it would be possible to deprecate the support of such
   URLs over time.

 - The original talks about "malicious tool runs "git remote get-url
   ..." but if you let malicious tools to run as your self, you can
   easily steal the credential out of system keychain as well, so
   "do not let malicious things to run as/for you---they will do
   malicious things to you" may be a good general advice.  Those who
   need that kind of advice would not be helped all that much by
   moving away from using URLs that embed credential and instead
   start using credential helpers.

Thanks.

    

Re: Git remote origin leaks user access token

[H. Peter Anvin]

On 7/1/24 11:35, Jeff King wrote:
> On Mon, Jul 01, 2024 at 04:27:43PM +0000, brian m. carlson wrote:
> 
>> I do want to point out that several people, not just me, have worked
>> together to make using a credential helper as easy and robust as
>> possible.  I mention this not to contradict Jonathan, who I think is
>> also trying to help in this regard, but mostly to mention that as a
>> project we've been trying to gently nudge people into doing the more
>> secure thing.  If people have further suggestions on how to make this
>> easier for users in the future, I'm very eager to hear them.
> 
> One thing we could do is refuse to store credentials in plaintext
> config. That helps people who aren't aware of the recommendations you
> mentioned end up more secure (though at the expense of convenience, as
> subsequent fetches won't work if you don't have a credential helper set
> up).
> 
> Some old discussion and possible patches here if anybody wants to pick
> up the topic:
> 
>    https://lore.kernel.org/git/nycvar.QRO.7.76.6.1905172121130.46@tvgsbejvaqbjf.bet/
> 

That could be a default, but please in that case add an override option. 
I can't even begin to list the number of fail whales that have been 
committed in the name of "security" without some kind of No Dammit I 
Really Mean It™ override. Everything from MTAs refusing to deliver to 
shared mailboxes for role accounts (due to giving group access) to being 
unable to connect to old embedded devices because "SSL 3 is dangerous 
and deprecated" -- which, of course, is true, but when you are on an 
isolated network and can't downgrade the existing device to unencrypted 
and can't upgrade it to TLS, it is an amazing headache.

	-hpa

Re: Git remote origin leaks user access token

[Jeff King]

On Tue, Jul 02, 2024 at 02:13:47PM -0700, H. Peter Anvin wrote:

> > One thing we could do is refuse to store credentials in plaintext
> > config. That helps people who aren't aware of the recommendations you
> > mentioned end up more secure (though at the expense of convenience, as
> > subsequent fetches won't work if you don't have a credential helper set
> > up).
> > 
> > Some old discussion and possible patches here if anybody wants to pick
> > up the topic:
> > 
> >    https://lore.kernel.org/git/nycvar.QRO.7.76.6.1905172121130.46@tvgsbejvaqbjf.bet/
> > 
> 
> That could be a default, but please in that case add an override option. I
> can't even begin to list the number of fail whales that have been committed
> in the name of "security" without some kind of No Dammit I Really Mean It™
> override. Everything from MTAs refusing to deliver to shared mailboxes for
> role accounts (due to giving group access) to being unable to connect to old
> embedded devices because "SSL 3 is dangerous and deprecated" -- which, of
> course, is true, but when you are on an isolated network and can't downgrade
> the existing device to unencrypted and can't upgrade it to TLS, it is an
> amazing headache.

The patches there would actually work out of the box, because they
replace the config storage with the janky plaintext git-credential-store
mechanism. But it was that final compatibility step that I think made me
question whether it was really accomplishing much at all.

I do agree there should be an option to override, though (you can always
run "git config remote.origin.url" yourself, but I think it should be as
simple as a config or command line option to get the old behavior).

-Peff