{"thread":{"id":"47763","subject":"Re: git: CVE-2018-1000021: client prints server sent ANSI escape codes to the terminal, allowing for unverified messages to potentially execute arbitrary commands","startedAt":"2018-02-05T20:43:21Z","lastAt":"2018-02-07T17:15:22Z","messageCount":4,"participants":["Jonathan Nieder","Randall S. Becker","Andreas Schwab"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"338250","messageId":"20180205204312.GB104086@aiede.svl.corp.google.com","threadId":"47763","inReplyTo":"151785928011.30076.5964248840190566119.reportbug@eldamar.local","subject":"Re: git: CVE-2018-1000021: client prints server sent ANSI escape codes to the terminal, allowing for unverified messages to potentially execute arbitrary commands","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2018-02-05T20:43:12Z","receivedAt":"2018-02-05T20:43:21Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"+cc: upstream\nHi,\n\nSalvatore Bonaccorso wrote[1]:\n\n> the following vulnerability was published for git.\n>\n> CVE-2018-1000021[0]:\n> |client prints server sent ANSI escape codes to the terminal, allowing\n> |for unverified messages to potentially execute arbitrary commands\n>\n> Creating this bug to track the issue in the BTS. Apparently the CVE\n> was sssigned without notifying/discussing it with upstream, at least\n> according to [1].\n>\n> If you fix the vulnerability please also make sure to include the\n> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.\n>\n> For further information see:\n>\n> [0] https://security-tracker.debian.org/tracker/CVE-2018-1000021\n>     https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000021\n> [1] https://bugzilla.novell.com/show_bug.cgi?id=1079389#c1\n\nThanks.  Upstream was notified about this and we dropped the ball on\npassing it on to a more public forum.  Sorry about that.\n\nI'd be interested in your advice on this.  There are cases where the\nuser may *want* ANSI escape codes to be passed through without change\nand other cases where the user doesn't want that.  Commands like \"git\ndiff\" pass their output through a pager by default, which itself may\nor may not sanitize the output.\n\nIn other words, there are multiple components at play:\n\n 1. A terminal.  IMHO, it is completely inexcusable these days for a\n    terminal to allow arbitrary code execution by writing output to\n    it.  If bugs of that kind still exist, I think we should fix them\n    (and perhaps even make it a requirement in Debian policy to make\n    the expectations clear for new terminals).\n\n    That said, for defense in depth, it can be useful to also guard\n    against this kind of issue in other components.  In particular:\n\n 2. A pager.  Are there clear guidelines for what it is safe and not\n    safe for a pager to write to a terminal?\n\n    \"less -R\" tries to only allow ANSI \"color\" escape sequences\n    through but I wouldn't be surprised if there are some cases it\n    misses.\n\n 3. Output formats.  Some git commands are designed for scripting\n    and do not have a sensible way to sanitize their output without\n    breaking scripts.  Fortunately, in the case of \"git diff\", git\n    has a notion of a \"binary patch\" where everything is sanitized,\n    at the cost of the output being unreadable to a human (email-safe\n    characters but not something that a human can read at a glance).\n    So if we know what sequences to avoid writing to stdout, then we\n    can treat files with those sequences as binary.\n\nPointers welcome.\n\nThanks,\nJonathan\n\n[1] https://bugs.debian.org/889680\n"},{"id":"338542","messageId":"00b601d39f9d$7a40b820$6ec22860$@nexbridge.com","threadId":"47763","inReplyTo":"20180205204312.GB104086@aiede.svl.corp.google.com","subject":"RE: git: CVE-2018-1000021: client prints server sent ANSI escape codes to the terminal, allowing for unverified messages to potentially execute arbitrary commands","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2018-02-06T22:54:37Z","receivedAt":"2018-02-06T22:55:00Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On February 5, 2018 3:43 PM, Jonathan Nieder wrote:\n> \n> Salvatore Bonaccorso wrote[1]:\n> \n> > the following vulnerability was published for git.\n> >\n> > CVE-2018-1000021[0]:\n> > |client prints server sent ANSI escape codes to the terminal, allowing\n> > |for unverified messages to potentially execute arbitrary commands\n> >\n> > Creating this bug to track the issue in the BTS. Apparently the CVE\n> > was sssigned without notifying/discussing it with upstream, at least\n> > according to [1].\n> >\n> > If you fix the vulnerability please also make sure to include the CVE\n> > (Common Vulnerabilities & Exposures) id in your changelog entry.\n> >\n> > For further information see:\n> >\n> > [0] https://security-tracker.debian.org/tracker/CVE-2018-1000021\n> >     https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000021\n> > [1] https://bugzilla.novell.com/show_bug.cgi?id=1079389#c1\n> \n> Thanks.  Upstream was notified about this and we dropped the ball on\n> passing it on to a more public forum.  Sorry about that.\n> \n> I'd be interested in your advice on this.  There are cases where the user\nmay\n> *want* ANSI escape codes to be passed through without change and other\n> cases where the user doesn't want that.  Commands like \"git diff\" pass\ntheir\n> output through a pager by default, which itself may or may not sanitize\nthe\n> output.\n> \n> In other words, there are multiple components at play:\n> \n>  1. A terminal.  IMHO, it is completely inexcusable these days for a\n>     terminal to allow arbitrary code execution by writing output to\n>     it.  If bugs of that kind still exist, I think we should fix them\n>     (and perhaps even make it a requirement in Debian policy to make\n>     the expectations clear for new terminals).\n> \n>     That said, for defense in depth, it can be useful to also guard\n>     against this kind of issue in other components.  In particular:\n> \n>  2. A pager.  Are there clear guidelines for what it is safe and not\n>     safe for a pager to write to a terminal?\n> \n>     \"less -R\" tries to only allow ANSI \"color\" escape sequences\n>     through but I wouldn't be surprised if there are some cases it\n>     misses.\n> \n>  3. Output formats.  Some git commands are designed for scripting\n>     and do not have a sensible way to sanitize their output without\n>     breaking scripts.  Fortunately, in the case of \"git diff\", git\n>     has a notion of a \"binary patch\" where everything is sanitized,\n>     at the cost of the output being unreadable to a human (email-safe\n>     characters but not something that a human can read at a glance).\n>     So if we know what sequences to avoid writing to stdout, then we\n>     can treat files with those sequences as binary.\n> \n> Pointers welcome.\n\nOne possible (albeit brute force) approach, in dealing with the specifics of\nthis CVE, may be to explicitly translate ESC-] into BLANK-], leaving a\npotential attack visible but ineffective. This only addresses the attack\nvector documented in the particular CVE but it can be done efficiently. The\nsequence does not appear significant in ANSI - the CVE documents the xterm\nsituation.  Checking very old termcap, the impact would be on unfiltering\nemulations derived (this is a sample) from nec 5520, freedom 100, Sun\nworkstations sun-s/-e-s, fortune, etc. Based on the seemingly limited use of\nthis sequence, having a config item may be overkill, but it could be set\nenabled by default.\n\nWhat I don't know - and it's not explicitly in the CVE - is just how many\nother terminal types with similar vulnerabilities are out there, but I'm\nsuspecting it's larger than one would guess - mostly, it seems like this\nparticular sequence is intended to be used for writing status line output\n(line 25?) instead of sticking it in a prompt. This can be used prettifies a\nlengthy bash prompt to display the current branch and repository at the\nbottom of the screen instead of in the inline prompt, but that's the user's\nchoice and not something git has to deal with. There were some green-screen\nterminals with other weird ESC sequences back in the day that could really\nget into trouble with this, including loading/executing programs in terminal\nmemory via output - really. I'm sure it seemed like a good idea at the time,\nbut I can see how it could have been used for evil.\n\nA more general solution might be to permit the configuration of a list of\nblocked character sequences and apply those as a filter. Something like\ncore.filter-mask=\"\\E]\", \"\\EA\".\n\nJust my $0.02 ramblings.\n\nCheers,\nRandall\n\n-- Brief whoami:\n NonStop developer since approximately 211288444200000000\n UNIX developer since approximately 421664400\n-- In my real life, I talk too much.\n\n\n\n"},{"id":"338633","messageId":"871shwpwrm.fsf@linux-m68k.org","threadId":"47763","inReplyTo":"00b601d39f9d$7a40b820$6ec22860$@nexbridge.com","subject":"Re: git: CVE-2018-1000021: client prints server sent ANSI escape codes to the terminal, allowing for unverified messages to potentially execute arbitrary commands","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2018-02-07T16:52:45Z","receivedAt":"2018-02-07T16:52:54Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"On Feb 06 2018, \"Randall S. Becker\" <rsbecker@nexbridge.com> wrote:\n\n> What I don't know - and it's not explicitly in the CVE - is just how many\n> other terminal types with similar vulnerabilities are out there, but I'm\n> suspecting it's larger than one would guess - mostly, it seems like this\n> particular sequence is intended to be used for writing status line output\n> (line 25?) instead of sticking it in a prompt. This can be used prettifies a\n> lengthy bash prompt to display the current branch and repository at the\n> bottom of the screen instead of in the inline prompt, but that's the user's\n> choice and not something git has to deal with. There were some green-screen\n> terminals with other weird ESC sequences back in the day that could really\n> get into trouble with this, including loading/executing programs in terminal\n> memory via output - really. I'm sure it seemed like a good idea at the time,\n> but I can see how it could have been used for evil.\n\nDo you also want to block \"+++AT\"?  :-)\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"338636","messageId":"001f01d3a037$3296deb0$97c49c10$@nexbridge.com","threadId":"47763","inReplyTo":"871shwpwrm.fsf@linux-m68k.org","subject":"RE: git: CVE-2018-1000021: client prints server sent ANSI escape codes to the terminal, allowing for unverified messages to potentially execute arbitrary commands","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2018-02-07T17:15:00Z","receivedAt":"2018-02-07T17:15:22Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On February 7, 2018 11:53 AM, Andreas Schwab wrote:\n> On Feb 06 2018, \"Randall S. Becker\" <rsbecker@nexbridge.com> wrote:\n> \n> > What I don't know - and it's not explicitly in the CVE - is just how\n> > many other terminal types with similar vulnerabilities are out there,\n> > but I'm suspecting it's larger than one would guess - mostly, it seems\n> > like this particular sequence is intended to be used for writing\n> > status line output (line 25?) instead of sticking it in a prompt. This\n> > can be used prettifies a lengthy bash prompt to display the current\n> > branch and repository at the bottom of the screen instead of in the\n> > inline prompt, but that's the user's choice and not something git has\n> > to deal with. There were some green-screen terminals with other weird\n> > ESC sequences back in the day that could really get into trouble with\n> > this, including loading/executing programs in terminal memory via\n> > output - really. I'm sure it seemed like a good idea at the time, but I\ncan see\n> how it could have been used for evil.\n> \n> Do you also want to block \"+++AT\"?  :-)\n\nOh dear. Oh dear. You *do* know that actually could be bad. I wonder how\nmany git users are still using dial-up to clone/push. Of course, they would\nprobably not even see this message after trying to download it.\n\nChuckles,\nRandall\n\n-- Brief whoami:\n NonStop developer since approximately 211288444200000000\n UNIX developer since approximately 421664400\n-- In my real life, I talk too much.\n\n\n\n"}]}