git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Salvatore Bonaccorso <carnil@debian.org>
Cc: 889680@bugs.debian.org, git@vger.kernel.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
Date: Mon, 5 Feb 2018 12:43:12 -0800	[thread overview]
Message-ID: <20180205204312.GB104086@aiede.svl.corp.google.com> (raw)
In-Reply-To: <151785928011.30076.5964248840190566119.reportbug@eldamar.local>

+cc: upstream
Hi,

Salvatore Bonaccorso wrote[1]:

> the following vulnerability was published for git.
>
> CVE-2018-1000021[0]:
> |client prints server sent ANSI escape codes to the terminal, allowing
> |for unverified messages to potentially execute arbitrary commands
>
> Creating this bug to track the issue in the BTS. Apparently the CVE
> was sssigned without notifying/discussing it with upstream, at least
> according to [1].
>
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
>
> For further information see:
>
> [0] https://security-tracker.debian.org/tracker/CVE-2018-1000021
>     https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000021
> [1] https://bugzilla.novell.com/show_bug.cgi?id=1079389#c1

Thanks.  Upstream was notified about this and we dropped the ball on
passing it on to a more public forum.  Sorry about that.

I'd be interested in your advice on this.  There are cases where the
user may *want* ANSI escape codes to be passed through without change
and other cases where the user doesn't want that.  Commands like "git
diff" pass their output through a pager by default, which itself may
or may not sanitize the output.

In other words, there are multiple components at play:

 1. A terminal.  IMHO, it is completely inexcusable these days for a
    terminal to allow arbitrary code execution by writing output to
    it.  If bugs of that kind still exist, I think we should fix them
    (and perhaps even make it a requirement in Debian policy to make
    the expectations clear for new terminals).

    That said, for defense in depth, it can be useful to also guard
    against this kind of issue in other components.  In particular:

 2. A pager.  Are there clear guidelines for what it is safe and not
    safe for a pager to write to a terminal?

    "less -R" tries to only allow ANSI "color" escape sequences
    through but I wouldn't be surprised if there are some cases it
    misses.

 3. Output formats.  Some git commands are designed for scripting
    and do not have a sensible way to sanitize their output without
    breaking scripts.  Fortunately, in the case of "git diff", git
    has a notion of a "binary patch" where everything is sanitized,
    at the cost of the output being unreadable to a human (email-safe
    characters but not something that a human can read at a glance).
    So if we know what sequences to avoid writing to stdout, then we
    can treat files with those sequences as binary.

Pointers welcome.

Thanks,
Jonathan

[1] https://bugs.debian.org/889680

       reply	other threads:[~2018-02-05 20:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <151785928011.30076.5964248840190566119.reportbug@eldamar.local>
2018-02-05 20:43 ` Jonathan Nieder [this message]
2018-02-06 22:54   ` git: CVE-2018-1000021: client prints server sent ANSI escape codes to the terminal, allowing for unverified messages to potentially execute arbitrary commands Randall S. Becker
2018-02-07 16:52     ` Andreas Schwab
2018-02-07 17:15       ` Randall S. Becker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180205204312.GB104086@aiede.svl.corp.google.com \
    --to=jrnieder@gmail.com \
    --cc=889680@bugs.debian.org \
    --cc=carnil@debian.org \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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).