{"thread":{"id":"61710","subject":"Re: Git remote origin leaks user access token","startedAt":"2024-07-01T11:46:07Z","lastAt":"2024-07-02T21:21:22Z","messageCount":6,"participants":["Jonathan Nieder","brian m. carlson","Jeff King","Junio C Hamano","H. Peter Anvin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"497880","messageId":"ZoKW-yDJMsz9JPSI@google.com","threadId":"61710","inReplyTo":"CALFtjBBvk+JPmU_GzrnM=ANwaQDdiLtzh4YkZFbcVENyCu9fxA@mail.gmail.com","subject":"Re: Git remote origin leaks user access token","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2024-07-01T11:46:03Z","receivedAt":"2024-07-01T11:46:07Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"(+cc: git@vger.kernel.org, git-security -> bcc)\nHi!\n\nlimin wrote:\n\n> Hi, I found a potential security issue when running a tool in my private\n> project. I think this exposes my personal access token to danger when using\n> \"git remote get-url origin\".\n\nI'm moving this conversation to the public Git mailing list, as this\nbehavior is well known.\n\nI look forward to working together on ways to reduce the impact (for\nexample, ways to encourage people to use their system's password\nkeychain instead of including credentials in URLs).\n\nReport left unsnipped below, for reference.\n\nThanks,\nJonathan\n\n> Version\n>\n> 2.45.2\n>\n> Description\n>\n> Lots of people are using personal access token to clone their private\n> repository. To use a access token, you can include your username and token\n> in https url to clone projects on github, gitlab or any other DevOps\n> Platform:\n>\n> git clone https://:@github.com/username/repository.git\n>\n> However, we can get the token back easily by just using git remote get-url\n> origin.\n>\n> cd privateProject\n> git remote get-url origin\n> > https://username:ghp_xxxxx@github.com/username/repository.git\n>\n> This can be dangerous, because we often run third party tools in our\n> private repository. If a malicious tool runs git remote get-url origin, it\n> can steal our personal access token of github/gitlab. In this case, our\n> github/gitlab will be controlled by attackers which can have severe\n> consequences.\n>\n> I found this issue during code auditing via safety tool\n> . After scanning a project using safety\n> check -r requirements.txt --save-json test.json, safety saved results into\n> test.json file. However, when I looked into test.json, I found my personal\n> access token in this file.\n>\n> \"report_meta\": {\n> \"scan_target\": \"files\",\n> \"scanned\": [\n> \"/home/kali/huntr/azure-sdk-for-python/tools/azure-sdk-tools/ci_tools/versioning/requirements.txt\"\n> ],\n> \"target_languages\": [\n> \"python\"\n> ],\n> \"git\": {\n> \"branch\": \"main\",\n> \"tag\": \"\",\n> \"commit\": \"b182b0c4f9d07d18f118130bc941c3b7a75667b1\",\n> \"dirty\": false,\n> \"origin\": \"https://outh2:ghp_xxxx@github.com/sunriseXu/xxxx.git\"\n> },\n> }\n>\n> So, I looked into the source code of safety. The class GIT\n> \n> is\n> responsible for collecting repository information in current repo where\n> safety runs.\n>\n> class GIT:\n> ORIGIN_CMD: Tuple[str, ...] = (\"remote\", \"get-url\", \"origin\")\n> def __run__(self, cmd: Tuple[str, ...], env_var: Optional[str] =\n> None) -> Optional[str]:\n> if env_var and os.environ.get(env_var):\n> return os.environ.get(env_var)\n>\n> try:\n> return subprocess.run(self.git + cmd, stdout=subprocess.PIPE,\n>\n> stderr=subprocess.DEVNULL).stdout.decode('utf-8').strip()\n> except Exception as e:\n> LOG.exception(e)\n>\n> return None\n> def origin(self) -> Optional[str]:\n> # get the origin of repository\n> return self.__run__(self.ORIGIN_CMD, env_var=\"SAFETY_GIT_ORIGIN\")\n>\n> Impact\n>\n> This can have severe consequences. *Any* tools running in private\n> repositories have ability to steal personal access token if the token is\n> written in git remote url explicitly. Git should mask user’s access token\n> when using cli command git remote get-url origin.\n"},{"id":"497905","messageId":"ZoLY_yxpQBjmp8O3@tapette.crustytoothpaste.net","threadId":"61710","inReplyTo":"ZoKW-yDJMsz9JPSI@google.com","subject":"Re: Git remote origin leaks user access token","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-07-01T16:27:43Z","receivedAt":"2024-07-01T16:27:45Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2024-07-01 at 11:46:03, Jonathan Nieder wrote:\n> (+cc: git@vger.kernel.org, git-security -> bcc)\n> Hi!\n> \n> limin wrote:\n> \n> > Hi, I found a potential security issue when running a tool in my private\n> > project. I think this exposes my personal access token to danger when using\n> > \"git remote get-url origin\".\n> \n> I'm moving this conversation to the public Git mailing list, as this\n> behavior is well known.\n> \n> I look forward to working together on ways to reduce the impact (for\n> example, ways to encourage people to use their system's password\n> keychain instead of including credentials in URLs).\n\nI'll point out that we already document this in the Git FAQ (git help\ngitfaq):\n\n----\nHow do I specify my credentials when pushing over HTTP?\n\nThe easiest way to do this is to use a credential helper via the\n`credential.helper` configuration. Most systems provide a standard\nchoice to integrate with the system credential manager. For example,\nGit for Windows provides the `wincred` credential manager, macOS has the\n`osxkeychain` credential manager, and Unix systems with a standard\ndesktop environment can use the `libsecret` credential manager. All of\nthese store credentials in an encrypted store to keep your passwords or\ntokens secure.\n\nIn addition, you can use the `store` credential manager which stores in a file\nin your home directory, or the `cache` credential manager, which does not\npermanently store your credentials, but does prevent you from being prompted for\nthem for a certain period of time.\n\nYou can also just enter your password when prompted. While it is possible to\nplace the password (which must be percent-encoded) in the URL, this is not\nparticularly secure and can lead to accidental exposure of credentials, so it is\nnot recommended.\n----\n\nWe also have a FAQ entry about how to read credentials from the\nenvironment as well, since that's a common thing people want to do.\n\nI also recently added support for putting credentials that are not\nusername and password (e.g., Bearer tokens) in credential helpers\nspecifically for this purpose, since people were using\n`http.extraHeader` for this, which is equally insecure.\n\nI do want to point out that several people, not just me, have worked\ntogether to make using a credential helper as easy and robust as\npossible. I mention this not to contradict Jonathan, who I think is\nalso trying to help in this regard, but mostly to mention that as a\nproject we've been trying to gently nudge people into doing the more\nsecure thing. If people have further suggestions on how to make this\neasier for users in the future, I'm very eager to hear them.\n-- \nbrian m. carlson (they/them or he/him)\nToronto, Ontario, CA\n"},{"id":"497912","messageId":"20240701183515.GF3199@coredump.intra.peff.net","threadId":"61710","inReplyTo":"ZoLY_yxpQBjmp8O3@tapette.crustytoothpaste.net","subject":"Re: Git remote origin leaks user access token","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2024-07-01T18:35:15Z","receivedAt":"2024-07-01T18:35:19Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jul 01, 2024 at 04:27:43PM +0000, brian m. carlson wrote:\n\n> I do want to point out that several people, not just me, have worked\n> together to make using a credential helper as easy and robust as\n> possible. I mention this not to contradict Jonathan, who I think is\n> also trying to help in this regard, but mostly to mention that as a\n> project we've been trying to gently nudge people into doing the more\n> secure thing. If people have further suggestions on how to make this\n> easier for users in the future, I'm very eager to hear them.\n\nOne thing we could do is refuse to store credentials in plaintext\nconfig. That helps people who aren't aware of the recommendations you\nmentioned end up more secure (though at the expense of convenience, as\nsubsequent fetches won't work if you don't have a credential helper set\nup).\n\nSome old discussion and possible patches here if anybody wants to pick\nup the topic:\n\n https://lore.kernel.org/git/nycvar.QRO.7.76.6.1905172121130.46@tvgsbejvaqbjf.bet/\n\n-Peff\n"},{"id":"497914","messageId":"xmqqsewtvsrg.fsf@gitster.g","threadId":"61710","inReplyTo":"ZoLY_yxpQBjmp8O3@tapette.crustytoothpaste.net","subject":"Re: Git remote origin leaks user access token","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-07-01T19:04:03Z","receivedAt":"2024-07-01T19:04:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" writes:\n\n> I'll point out that we already document this in the Git FAQ (git help\n> gitfaq):\n>\n> ----\n> How do I specify my credentials when pushing over HTTP?\n> ...\n>\n> We also have a FAQ entry about how to read credentials from the\n> environment as well, since that's a common thing people want to do.\n> ...\n>\n> I do want to point out that several people, not just me, have worked\n> together to make using a credential helper as easy and robust as\n> possible. I mention this not to contradict Jonathan, who I think is\n> also trying to help in this regard, but mostly to mention that as a\n> project we've been trying to gently nudge people into doing the more\n> secure thing.\n\nTwo and a half things.\n\n - Perhaps we want to explicitly single out URLs that embed\n credential in the documentation and tell readers not to use that.\n I wonder if it would be possible to deprecate the support of such\n URLs over time.\n\n - The original talks about \"malicious tool runs \"git remote get-url\n ...\" but if you let malicious tools to run as your self, you can\n easily steal the credential out of system keychain as well, so\n \"do not let malicious things to run as/for you---they will do\n malicious things to you\" may be a good general advice. Those who\n need that kind of advice would not be helped all that much by\n moving away from using URLs that embed credential and instead\n start using credential helpers.\n\nThanks.\n\n \n\n"},{"id":"497999","messageId":"ada57994-b7cc-4a21-b41d-400d63b243d5@zytor.com","threadId":"61710","inReplyTo":"20240701183515.GF3199@coredump.intra.peff.net","subject":"Re: Git remote origin leaks user access token","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2024-07-02T21:13:47Z","receivedAt":"2024-07-02T21:14:12Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"On 7/1/24 11:35, Jeff King wrote:\n> On Mon, Jul 01, 2024 at 04:27:43PM +0000, brian m. carlson wrote:\n> \n>> I do want to point out that several people, not just me, have worked\n>> together to make using a credential helper as easy and robust as\n>> possible. I mention this not to contradict Jonathan, who I think is\n>> also trying to help in this regard, but mostly to mention that as a\n>> project we've been trying to gently nudge people into doing the more\n>> secure thing. If people have further suggestions on how to make this\n>> easier for users in the future, I'm very eager to hear them.\n> \n> One thing we could do is refuse to store credentials in plaintext\n> config. That helps people who aren't aware of the recommendations you\n> mentioned end up more secure (though at the expense of convenience, as\n> subsequent fetches won't work if you don't have a credential helper set\n> up).\n> \n> Some old discussion and possible patches here if anybody wants to pick\n> up the topic:\n> \n> https://lore.kernel.org/git/nycvar.QRO.7.76.6.1905172121130.46@tvgsbejvaqbjf.bet/\n> \n\nThat could be a default, but please in that case add an override option. \nI can't even begin to list the number of fail whales that have been \ncommitted in the name of \"security\" without some kind of No Dammit I \nReally Mean It™ override. Everything from MTAs refusing to deliver to \nshared mailboxes for role accounts (due to giving group access) to being \nunable to connect to old embedded devices because \"SSL 3 is dangerous \nand deprecated\" -- which, of course, is true, but when you are on an \nisolated network and can't downgrade the existing device to unencrypted \nand can't upgrade it to TLS, it is an amazing headache.\n\n\t-hpa\n\n"},{"id":"498001","messageId":"20240702212121.GC120950@coredump.intra.peff.net","threadId":"61710","inReplyTo":"ada57994-b7cc-4a21-b41d-400d63b243d5@zytor.com","subject":"Re: Git remote origin leaks user access token","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2024-07-02T21:21:21Z","receivedAt":"2024-07-02T21:21:22Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jul 02, 2024 at 02:13:47PM -0700, H. Peter Anvin wrote:\n\n> > One thing we could do is refuse to store credentials in plaintext\n> > config. That helps people who aren't aware of the recommendations you\n> > mentioned end up more secure (though at the expense of convenience, as\n> > subsequent fetches won't work if you don't have a credential helper set\n> > up).\n> > \n> > Some old discussion and possible patches here if anybody wants to pick\n> > up the topic:\n> > \n> > https://lore.kernel.org/git/nycvar.QRO.7.76.6.1905172121130.46@tvgsbejvaqbjf.bet/\n> > \n> \n> That could be a default, but please in that case add an override option. I\n> can't even begin to list the number of fail whales that have been committed\n> in the name of \"security\" without some kind of No Dammit I Really Mean It™\n> override. Everything from MTAs refusing to deliver to shared mailboxes for\n> role accounts (due to giving group access) to being unable to connect to old\n> embedded devices because \"SSL 3 is dangerous and deprecated\" -- which, of\n> course, is true, but when you are on an isolated network and can't downgrade\n> the existing device to unencrypted and can't upgrade it to TLS, it is an\n> amazing headache.\n\nThe patches there would actually work out of the box, because they\nreplace the config storage with the janky plaintext git-credential-store\nmechanism. But it was that final compatibility step that I think made me\nquestion whether it was really accomplishing much at all.\n\nI do agree there should be an option to override, though (you can always\nrun \"git config remote.origin.url\" yourself, but I think it should be as\nsimple as a config or command line option to get the old behavior).\n\n-Peff\n"}]}