1. 22 Sep, 2017 5 commits
  2. 12 Sep, 2017 3 commits
    • Jeff King's avatar
      cvsimport: shell-quote variable used in backticks · 5b4efea6
      Jeff King authored
      We run `git rev-parse` though the shell, and quote its
      argument only with single-quotes. This prevents most
      metacharacters from being a problem, but misses the obvious
      case when $name itself has single-quotes in it. We can fix
      this by applying the usual shell-quoting formula.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      5b4efea6
    • Jeff King's avatar
      archimport: use safe_pipe_capture for user input · 8d0fad0a
      Jeff King authored
      Refnames can contain shell metacharacters which need to be
      passed verbatim to sub-processes. Using safe_pipe_capture
      skips the shell entirely.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      8d0fad0a
    • Jeff King's avatar
      shell: drop git-cvsserver support by default · 9a42c03c
      Jeff King authored
      The git-cvsserver script is old and largely unmaintained
      these days. But git-shell allows untrusted users to run it
      out of the box, significantly increasing its attack surface.
      
      Let's drop it from git-shell's list of internal handlers so
      that it cannot be run by default.  This is not backwards
      compatible. But given the age and development activity on
      CVS-related parts of Git, this is likely to impact very few
      users, while helping many more (i.e., anybody who runs
      git-shell and had no intention of supporting CVS).
      
      There's no configuration mechanism in git-shell for us to
      add a boolean and flip it to "off". But there is a mechanism
      for adding custom commands, and adding CVS support here is
      fairly trivial. Let's document it to give guidance to
      anybody who really is still running cvsserver.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      9a42c03c
  3. 11 Sep, 2017 3 commits
  4. 30 Jul, 2017 7 commits
  5. 28 Jul, 2017 6 commits
    • Junio C Hamano's avatar
      a4f234bf
    • Jeff King's avatar
      connect: reject paths that look like command line options · aeeb2d49
      Jeff King authored
      If we get a repo path like "-repo.git", we may try to invoke
      "git-upload-pack -repo.git". This is going to fail, since
      upload-pack will interpret it as a set of bogus options. But
      let's reject this before we even run the sub-program, since
      we would not want to allow any mischief with repo names that
      actually are real command-line options.
      
      You can still ask for such a path via git-daemon, but there's no
      security problem there, because git-daemon enters the repo itself
      and then passes "."  on the command line.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Reviewed-by: default avatarJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      aeeb2d49
    • Jeff King's avatar
      connect: reject dashed arguments for proxy commands · 3be4cf09
      Jeff King authored
      If you have a GIT_PROXY_COMMAND configured, we will run it
      with the host/port on the command-line. If a URL contains a
      mischievous host like "--foo", we don't know how the proxy
      command may handle it. It's likely to break, but it may also
      do something dangerous and unwanted (technically it could
      even do something useful, but that seems unlikely).
      
      We should err on the side of caution and reject this before
      we even run the command.
      
      The hostname check matches the one we do in a similar
      circumstance for ssh. The port check is not present for ssh,
      but there it's not necessary because the syntax is "-p
      <port>", and there's no ambiguity on the parsing side.
      
      It's not clear whether you can actually get a negative port
      to the proxy here or not. Doing:
      
        git fetch git://remote:-1234/repo.git
      
      keeps the "-1234" as part of the hostname, with the default
      port of 9418. But it's a good idea to keep this check close
      to the point of running the command to make it clear that
      there's no way to circumvent it (and at worst it serves as a
      belt-and-suspenders check).
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Reviewed-by: default avatarJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      3be4cf09
    • Jeff King's avatar
      connect: factor out "looks like command line option" check · 2491f77b
      Jeff King authored
      We reject hostnames that start with a dash because they may
      be confused for command-line options. Let's factor out that
      notion into a helper function, as we'll use it in more
      places. And while it's simple now, it's not clear if some
      systems might need more complex logic to handle all cases.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Reviewed-by: default avatarJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      2491f77b
    • Jeff King's avatar
      t5813: add test for hostname starting with dash · 2d90add5
      Jeff King authored
      Per the explanation in the previous patch, this should be
      (and is) rejected.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Reviewed-by: default avatarJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      2d90add5
    • Junio C Hamano's avatar
      connect: reject ssh hostname that begins with a dash · 820d7650
      Junio C Hamano authored
      When commands like "git fetch" talk with ssh://$rest_of_URL/, the
      code splits $rest_of_URL into components like host, port, etc., and
      then spawns the underlying "ssh" program by formulating argv[] array
      that has:
      
       - the path to ssh command taken from GIT_SSH_COMMAND, etc.
      
       - dashed options like '-batch' (for Tortoise), '-p <port>' as
         needed.
      
       - ssh_host, which is supposed to be the hostname parsed out of
         $rest_of_URL.
      
       - then the command to be run on the other side, e.g. git
         upload-pack.
      
      If the ssh_host ends up getting '-<anything>', the argv[] that is
      used to spawn the command becomes something like:
      
          { "ssh", "-p", "22", "-<anything>", "command", "to", "run", NULL }
      
      which obviously is bogus, but depending on the actual value of
      "<anything>", will make "ssh" parse and use it as an option.
      
      Prevent this by forbidding ssh_host that begins with a "-".
      
      Noticed-by: Joern Schneeweisz of Recurity Labs
      Reported-by: Brian at GitLab
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      Reviewed-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      820d7650
  6. 05 May, 2017 15 commits
  7. 05 Dec, 2016 1 commit