1. 树叶云首页
  2. 技术资讯

当git遇上ssh——CVE-2017-1000117漏洞浅析

管理••技术资讯

Git是一个开源的分布式版本控制系统，主要用于项目管理。

而SSH是一种应用层的安全通信协议，最常用的就是为通信双方在在不安全网络上提供安全的远程登录。

当他们二者相遇会发生什么有趣的事呢?这里以CVE-2017-1000117漏洞为例，简要剖析该漏洞的成因及防护方法。

漏洞相关信息：

版本控制软件爆出远程命令执行漏洞 涉及Git、SVN、Mercurial、CVS版本控制

简述：几个流行的版本控制系统受到可能严重的远程命令执行漏洞的影响。受影响产品的开发人员本周发布了更新补丁来修补安全漏洞。该缺陷影响版本控制软件, 如 Git (CVE-2017-1000117)、Apache Subversion (CVE-2017-9800)、Mercurial (CVE-2017-1000116) 和 CVS。由于CVS 系统上次更新已经是9年前的事情了, 因此没有为它分配 CVE 标识符。

背景知识

ssh客户端登录时，有一个ProxyCommand选项，该选项的指定链接服务器时执行的命令。

  1. ProxyCommand 
  2.  
  3.    Specifies the command to use to connect to the server.  The 
  4.  
  5.    command string extends to the end of the line, and is executed 
  6.  
  7.    with the user’s shell.  In the command string, any occurrence 
  8.  
  9.    of ‘%h’ will be substituted by the host name to connect,‘%p’ 
  10.  
  11.    by the port, and ‘%r’ by the remote user name. 

该选项常用的场景是通过代理服务器与目标机器相连，因此被称作ProxyCommand，如下图。

本地的机器(Local)无法直接与目标机器(Target)相连，必须通过一个代理机器(Proxy)才能和目标机器建立连接。此场景多见于企业或有较强访问控制的需求的地方。

因此在这种情况下，ssh客户端可以采用ProxyCommand选项，通过下面命令最终和目标机器建立连接。

  1. ssh -o ProxyCommand=’ssh user@proxy nc %h 22′ user@Target 

加上ProxyCommand选项后。ssh客户端会先用当前用户的shell执行ProxyCommand中的内容。

例如下面的命令，在Linux桌面环境中执行，就会弹出gedit文本编辑器。

  1. ssh -oProxyCommand=gedit user@Target 

即便最后的user@hostname不合法，也不会影响ProxyCommand中先执行的命令，照样可以弹出gedit。

好了介绍完了ProxyCommand，可以理解为这个选项如处理不当，是可以进行命令注入的!

CVE-2017-1000117漏洞

CVE-2017-1000117这个漏洞就是没有正确处理ssh链接的请求，导致受害人通过Git版本控制系统，访问恶意链接时，存在安全隐患，一旦黑客攻击成功，可在受害人机器上执行任意命令。

git clone是Git版本控制系统中常用的将远程仓库克隆到本地的命令。当使用git clone访问下面的恶意ssh链接时，会在本地执行命令，弹出gedit。

  1. git clone ssh://-oProxyCommand=”gedit /tmp/xxx” 

下面我们来详细看一看其中的过程，当git遇上ssh后，最终是如何触发这个漏洞执行的。

 

git客户端在执行上面的命令后，通过一系列的参数解析后，进入git_connect函数，向git的服务端建立连接。

  1. struct child_process *git_connect(int fd[2], const char *url, 
  2. const char *prog, int flags) 
  3.  
  4. { 
  5.  
  6. char *hostandport, *path; 
  7.  
  8. struct child_process *conn = &no_fork; 
  9.  
  10. enum protocol protocol; 
  11.  
  12. struct strbuf cmd = STRBUF_INIT; 
  13.  
  14.   
  15.  
  16. /* Without this we cannot rely on waitpid() to tell 
  17.  
  18. * what happened to our children. 
  19.  
  20. */ 
  21.  
  22. signal(SIGCHLD, SIG_DFL); 
  23.  
  24.   
  25.  
  26. protocol = parse_connect_url(url, &hostandport, &path); 
  27.  
  28. if ((flags & CONNECT_DIAG_URL) && (protocol != PROTO_SSH)) { 
  29.  
  30. printf(“Diag: url=%s\n”, url ? url : “NULL”); 
  31.  
  32. printf(“Diag: protocol=%s\n”, prot_name(protocol)); 
  33.  
  34. printf(“Diag: hostandport=%s\n”, hostandport ? hostandport : “NULL”); 
  35.  
  36. printf(“Diag: path=%s\n”, path ? path : “NULL”); 
  37.  
  38. conn = NULL; 
  39.  
  40. } else if (protocol == PROTO_GIT) { 
  41.  
  42. ….. 
  43.  
  44. } else { 
  45.  
  46. conn = xmalloc(sizeof(*conn)); 
  47.  
  48. child_process_init(conn); 
  49.  
  50.   
  51.  
  52. strbuf_addstr(&cmd, prog); 
  53.  
  54. strbuf_addch(&cmd, ‘ ‘); 
  55.  
  56. sq_quote_buf(&cmd, path); 
  57.  
  58.   
  59.  
  60. /* remove repo-local variables from the environment */ 
  61.  
  62. conn->env = local_repo_env; 
  63.  
  64. conn->use_shell = 1; 
  65.  
  66. conn->in = conn->out = -1; 
  67.  
  68. if (protocol == PROTO_SSH) { 
  69.  
  70. const char *ssh; 
  71.  
  72. int putty = 0, tortoiseplink = 0; 
  73.  
  74. char *ssh_host = hostandport; 
  75.  
  76. const char *port = NULL; 
  77.  
  78. transport_check_allowed(“ssh”); 
  79.  
  80. get_host_and_port(&ssh_host, &port); 
  81.  
  82.   
  83.  
  84. if (!port) 
  85.  
  86. port = get_port(ssh_host); 
  87.  
  88.   
  89.  
  90. ssh = getenv(“GIT_SSH_COMMAND”); 
  91.  
  92. if (!ssh) { 
  93.  
  94. const char *base; 
  95.  
  96. char *ssh_dup; 
  97.  
  98. /* 
  99.  
  100. * GIT_SSH is the no-shell version of 
  101.  
  102. * GIT_SSH_COMMAND (and must remain so for 
  103.  
  104. * historical compatibility). 
  105.  
  106. */ 
  107.  
  108. conn->use_shell = 0; 
  109.  
  110.   
  111.  
  112. ssh = getenv(“GIT_SSH”); 
  113.  
  114. if (!ssh) 
  115.  
  116. ssh = “ssh”; 
  117.  
  118.   
  119.  
  120. ssh_dup = xstrdup(ssh); 
  121.  
  122. base = basename(ssh_dup); 
  123.  
  124.   
  125.  
  126. free(ssh_dup); 
  127.  
  128. } 
  129.  
  130.   
  131.  
  132. argv_array_push(&conn->args, ssh); 
  133.  
  134.   
  135.  
  136. if (port) { 
  137.  
  138. /* P is for PuTTY, p is for OpenSSH */ 
  139.  
  140. argv_array_push(&conn->args, putty ? “-P” : “-p”); 
  141.  
  142. argv_array_push(&conn->args, port); 
  143.  
  144. } 
  145.  
  146. argv_array_push(&conn->args, ssh_host); 
  147.  
  148. } else { 
  149.  
  150. transport_check_allowed(“file”); 
  151.  
  152. } 
  153.  
  154. argv_array_push(&conn->args, cmd.buf); 
  155.  
  156.   
  157.  
  158. if (start_command(conn)) 
  159.  
  160. die(“unable to fork”); 
  161.  
  162.   
  163.  
  164. ….. 
  165.  
  166. } 
  167.  
  168.   
  169.  
  170. } 

git_connect函数的第二个参数url，即为传入的ssh链接，在此例中为 “ssh://-oProxyCommand=gedit /tmp/xxx”。

在git_connect函数中通过parse_connect_url函数将待连接的url解析出来，返回url的主机名、相对路径及url采用的协议。

 

https://github.com/git/git/blob/master/connect.c#L620

  1. /* 
  2.  
  3. * Extract protocol and relevant parts from the specified connection URL. 
  4.  
  5. * The caller must free() the returned strings. 
  6.  
  7. */ 
  8.  
  9. static enum protocol parse_connect_url(const char *url_orig, char **ret_host,  char **ret_path) 

对于正常的ssh链接，如 ssh://[email protected]/path/to/repo.git/，经parse_connect_url解析后，其返回的ret_host和ret_path的值应该为 [email protected] 和 /path/to/repo.git/ 。

但由于没有对ssh做正确过滤及识别，对于恶意的ssh链接，返回的ret_host和ret_path的值则是 -oProxyCommand=gedit 和 /tmp/xxx ，误将 -oProxyCommand=gedit 作为了主机名ret_host。

在后续处理中，git_connect得到本地ssh的路径，将上面获取的ssh host和path填充到struct child_process *conn中，再通过start_command调用本地ssh执行。

在start_command函数中，最终调用exec系列函数执行ssh，由于错误的把 -oProxyCommand=gedit 作为远程待连接的host，最终引发了命令执行。

但像上面ssh://-oProxyCommand=”gedit /tmp/xxx”的链接比较暴露，直接在链接中就出现命令。比较隐蔽的方法是，在正常仓库的目录下建立一个子模块submodule，而将恶意的ssh链接藏在.gitmodule文件中。

修复防护方法

看完上面漏洞发生的成因，其实可以发现这个过程就是git处理ssh这类智能协议的传输过程：ssh远程登录git服务器后，通过执行git-upload-pack处理下载的数据，这种处理方式较http哑协议传输更高效。

但是在这过程中，对一些恶意的ssh链接，没有正确识别，在解析时误将 -oProxyCommand 这类参数当做了远程主机名host，从而产生了漏洞。

在新版本中，我们看到增加了对host和path的识别过滤。

对包含疑似命令的host和path及时进行了阻止，阻断了漏洞的发生。

 

建议用户及时排查，更新系统存在漏洞的Git版本，在日常通过Git进行项目管理时，仔细检查项目中是否存在一些恶意ssh链接来预防安全问题。

原文链接：http://blog.nsfocus.net/git-ssh-cve-2017-1000117/

【本文是专栏作者“绿盟科技博客”的原创稿件，转载请通过联系原作者获取授权】

戳这里，看该作者更多好文

文章来源网络，作者：管理，如若转载，请注明出处：https://shuyeidc.com/wp/132661.html<

赞 (0)
管理的头像管理
00
上一篇2025-02-27 03:09
下一篇 2025-02-27 03:11

相关推荐

  • 站群服务器和普通服务器到底哪个更适合GEO，怎么选？技术资讯

    站群服务器和普通服务器到底哪个更适合GEO，怎么选？

    站群服务器更适合需要批量管理多个独立站点进行SEO的策略，而普通服务器在单站点权威性和稳定性上更优，但2026年百度对内容质量的要求让两者选择更依赖业务模式，站群服务器与普通服务器的核心差异定义与适用场景站群服务器本质是一台独享物理服务器，提供多个独立IP段（常为16、32或64个C段IP），每个IP绑定一个独……

    管理的头像管理
    2026-07-28
    0
  • 物理服务器和云服务器做站群到底选哪个，哪个更稳定？技术资讯

    物理服务器和云服务器做站群到底选哪个，哪个更稳定？

    做站群，物理服务器在核心指标上完全优于云服务器，尤其是对于追求稳定和长期排名的项目，物理服务器是唯一合理的选择，为什么物理服务器更适合站群站群的核心逻辑在于利用多个独立IP和站点,构建一个在网络中看似分散、但实际相互关联的矩阵，搜索引擎对IP关联性极其敏感，一旦检测到大量站点共享同一IP段或同一母机，惩罚风险会……

    管理的头像管理
    2026-07-28
    0
  • 国内高防服务器哪家防御真实靠谱，怎么选？技术资讯

    国内高防服务器哪家防御真实靠谱，怎么选？

    国内高防服务器哪家防御真实靠谱？答案很明确：只有那些持证上岗、自建机房、自己掌握清洗算法的服务商才靠得住，简米科技和酷番云就是这类代表，判断高防服务器真实防御能力的三个硬指标很多朋友选高防服务器，上来就问“你家多少G防御”，但数字背后水分很大，要判断防御是否真实,得看这三个方面：防御带宽是否独享？ 有些服务商宣……

    管理的头像管理
    2026-07-28
    0
  • 裸金属服务器和物理服务器有什么区别？，怎么选？技术资讯

    裸金属服务器和物理服务器有什么区别？，怎么选？

    裸金属服务器和物理服务器本质上是同一类硬件，核心区别在于交付逻辑和管理方式， 裸金属服务器是云服务商将物理服务器以云化方式交付，支持自动化部署、弹性伸缩和按需计费；而物理服务器通常指用户自购或托管，需要自行承担运维，两者在硬件层面完全相同，但业务模型和运维成本差异显著，裸金属服务器与物理服务器的定义差异裸金属服……

    管理的头像管理
    2026-07-28
    0
  • 做GEO站群选哪家服务器服务商靠谱，怎么选？技术资讯

    做GEO站群选哪家服务器服务商靠谱，怎么选？

    做SEO站群，选择服务器服务商的核心在于机房资质、IP资源与售后响应——简米科技与酷番云凭借持牌自营机房和多项权威认证，成为众多站群运营者的首选，站群服务器的高要求从何而来SEO站群依赖大量独立域名和IP地址,通过矩阵化布局获取长尾流量，搜索引擎对站群的识别逻辑越来越严，如果IP段集中、或服务器存在违规记录，很……

    管理的头像管理
    2026-07-28
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注