當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選項，該選項的指定鏈接服務器時執行的命令。
- ProxyCommand
- Specifies the command to use to connect to the server. The
- command string extends to the end of the line, and is executed
- with the user’s shell. In the command string, any occurrence
- of ‘%h’ will be substituted by the host name to connect,‘%p’
- by the port, and ‘%r’ by the remote user name.
該選項常用的場景是通過代理服務器與目標機器相連，因此被稱作ProxyCommand，如下圖。
本地的機器(Local)無法直接與目標機器(Target)相連，必須通過一個代理機器(Proxy)才能和目標機器建立連接。此場景多見于企業或有較強訪問控制的需求的地方。
因此在這種情況下，ssh客戶端可以采用ProxyCommand選項，通過下面命令最終和目標機器建立連接。
- ssh -o ProxyCommand=’ssh user@proxy nc %h 22′ user@Target
加上ProxyCommand選項后。ssh客戶端會先用當前用戶的shell執行ProxyCommand中的內容。
例如下面的命令，在Linux桌面環境中執行，就會彈出gedit文本編輯器。
- 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。
- git clone ssh://-oProxyCommand=”gedit /tmp/xxx”
下面我們來詳細看一看其中的過程，當git遇上ssh后，最終是如何觸發這個漏洞執行的。
git客戶端在執行上面的命令后，通過一系列的參數解析后，進入git_connect函數，向git的服務端建立連接。
- struct child_process *git_connect(int fd[2], const char *url,
- const char *prog, int flags)
- {
- char *hostandport, *path;
- struct child_process *conn = &no_fork;
- enum protocol protocol;
- struct strbuf cmd = STRBUF_INIT;
- /* Without this we cannot rely on waitpid() to tell
- * what happened to our children.
- */
- signal(SIGCHLD, SIG_DFL);
- protocol = parse_connect_url(url, &hostandport, &path);
- if ((flags & CONNECT_DIAG_URL) && (protocol != PROTO_SSH)) {
- printf(“Diag: url=%s\n”, url ? url : “NULL”);
- printf(“Diag: protocol=%s\n”, prot_name(protocol));
- printf(“Diag: hostandport=%s\n”, hostandport ? hostandport : “NULL”);
- printf(“Diag: path=%s\n”, path ? path : “NULL”);
- conn = NULL;
- } else if (protocol == PROTO_GIT) {
- …..
- } else {
- conn = xmalloc(sizeof(*conn));
- child_process_init(conn);
- strbuf_addstr(&cmd, prog);
- strbuf_addch(&cmd, ‘ ‘);
- sq_quote_buf(&cmd, path);
- /* remove repo-local variables from the environment */
- conn->env = local_repo_env;
- conn->use_shell = 1;
- conn->in = conn->out = -1;
- if (protocol == PROTO_SSH) {
- const char *ssh;
- int putty = 0, tortoiseplink = 0;
- char *ssh_host = hostandport;
- const char *port = NULL;
- transport_check_allowed(“ssh”);
- get_host_and_port(&ssh_host, &port);
- if (!port)
- port = get_port(ssh_host);
- ssh = getenv(“GIT_SSH_COMMAND”);
- if (!ssh) {
- const char *base;
- char *ssh_dup;
- /*
- * GIT_SSH is the no-shell version of
- * GIT_SSH_COMMAND (and must remain so for
- * historical compatibility).
- */
- conn->use_shell = 0;
- ssh = getenv(“GIT_SSH”);
- if (!ssh)
- ssh = “ssh”;
- ssh_dup = xstrdup(ssh);
- base = basename(ssh_dup);
- free(ssh_dup);
- }
- argv_array_push(&conn->args, ssh);
- if (port) {
- /* P is for PuTTY, p is for OpenSSH */
- argv_array_push(&conn->args, putty ? “-P” : “-p”);
- argv_array_push(&conn->args, port);
- }
- argv_array_push(&conn->args, ssh_host);
- } else {
- transport_check_allowed(“file”);
- }
- argv_array_push(&conn->args, cmd.buf);
- if (start_command(conn))
- die(“unable to fork”);
- …..
- }
- }
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
- /*
- * Extract protocol and relevant parts from the specified connection URL.
- * The caller must free() the returned strings.
- */
- static enum protocol parse_connect_url(const char *url_orig, char **ret_host, char **ret_path)
對于正常的ssh鏈接，如 ssh://user@host.xzy/path/to/repo.git/，經parse_connect_url解析后，其返回的ret_host和ret_path的值應該為 user@host.xzy 和 /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/
【本文是51CTO專欄作者“綠盟科技博客”的原創稿件，轉載請通過51CTO聯系原作者獲取授權】
