破壳漏洞(shellshock)分析CVE-2014-6271

标签：shellshock   破壳漏洞   bash   shell   

    前段时间的破壳漏洞让各个公司忙的够呛，漏洞也过去一段时间了，大牛们的各种分析网上也是转来转去。等他们消停了，该我好好收集资料消化消化这个漏洞了。

漏洞简介

为什么这个漏洞如此受关注?

1、影响范围广，漏洞存在时间长。

    Bash，Unix shell的一种。1989年发布第一个正式版本，原先是计划用在GNU操作系统上，但能运行于大多数类Unix系统的操作系统之上，包括Linux与Mac OS X v10.4都将它作为默认shell。它也被移植到Microsoft Windows上的Cygwin与MinGW，或是可以在MS-DOS上使用的DJGPP项目。在Novell NetWare与Android上也有移植。

   所以这个漏洞存在于目前主流的Linux和MacOSX操作系统。该漏洞会影响到与bash交互的各种应用程序，如HTTP，FTP，DHCP等等。

   出问题的bash代码已经存在20多年了。

漏洞原理

要理解这个漏洞首先要知道什么是bash环境变量，下面引用左耳朵耗子的文章

环境变量大家知道吧，这个不用我普及了吧。环境变量是操作系统运行shell中的变量，很多程序会通过环境变量改变自己的执行行为。在bash中要定义一个环境变量的语法很简单（注：=号的前后不能有空格）：

然后你就可以使用这个变量了，比如：echo $var什么的。但是，我们要知道，这个变量只是一个当前shell的“局部变量”，只在当前的shell进程中可以访问，这个shell进程fork出来的进程是访问不到的。

你可以做这样的测试：

上面的测试中，第三个命令执行了一个bash，也就是开了一个bash的子进程，你就会发现var不能访问了。

为了要让shell的子进程可以访问，我们需要export一下：

这样，这个环境变量就会在其子进程中可见了。

如果你要查看一下有哪些环境变量可以在子进程中可见（也就是是否被export了），你可使用env命令。不过，env命令也可以用来定义export的环境变量。如下所示：

有了这些基础知识还不够，我们还要知道一个基础知识——shell的函数。

bash的函数

在bash下定义一个函数很简单，如下所示：

有了上面的环境变量的基础知识后，你一定会想试试这个函数是否可以在子进程中调用，答案当然是不行的。

你看，和环境变量是一样的，如果要在子进程中可以访问的话，那么，还是一样的，需要export，export有个参数 -f，意思是export一个函数。如：

Bash 漏洞的测试代码

在Bash Shell下执行以下代码：

env x=‘() { :;}; echo vulnerable‘ bash -c "echo this is a test"
如果输出：
vulnerable

this is a test

表示存在漏洞。打了补丁会输出以下错误：

bash: 警告: x: ignoring function definition attempt

bash: `x‘ 函数定义导入错误

this is a test

原理分析

Shell里可以定义变量，POC中定义了一个命名为x的变量，内容是一个字符串：
() { :;}; echo vulnerable
而根据漏洞信息得知，这个漏洞产生于Shell在处理函数定义时，执行了函数体之后的命令。但这里x的值是个字符串，它是怎么转变成函数的呢。

实际这个和Bash实现有关，在Bash中定义一个函数，格式为：
function function_name() {
body;
}
当Bash在初始化环境变量时，语法解析器发现小括号和大括号的时候，就认为它是一个函数定义：
[lu4nx@lx-pc ~]$ say_hello=‘() { echo hello world; }‘
[lu4nx@lx-pc ~]$ export say_hello
[lu4nx@lx-pc ~]$ bash -c ‘say_hello‘
hello world
上面代码在新的Bash进程中，say_hello成了新环境中的一个函数，它的演变过程如下：

1、新的bash在初始时，扫描到环境变量say_hello出现小括号和大括号，认定它是一个函数定义

2、bash把say_hello作为函数名，其值作为函数体

typeset命令可以列出当前环境中所有变量和函数定义，我们用typeset看看这个字符串怎么变成函数的。继续上面定义的say_hello函数：
[lu4nx@lx-pc ~]$ bash -c ‘typeset‘ | fgrep -A 10 say_hello
say_hello ()
{
echo hello world
}
这里新启动了个Bash进程，然后执行了typeset，typeset会返回当前环境（新的环境）中所有定义，这里清楚看到say_hello被变成函数了。

漏洞产生原因

而这个漏洞在于，Bash把函数体解析完了之后，去执行了函数定义后面的语句，为啥会这样呢。

通过结合补丁，我对Bash的源码简单分析了下，Bash初始化时调用了builtins/evalstring.c里的parse_and_execute函数。是的，就等于Bash初始化环境时调用了类似其他高级语言中的eval函数，它负责解析字符串输入并执行。

继续看parse_and_execute的源码，关键点在这里：
218 else if (command = global_command)
219 {
220 struct fd_bitmap *bitmap;
它判断命令是否是一个定义成全局的，新的bash进程启动后，say_hello不仅被解析成函数了，还变成全局的了：
[lu4nx@lx-pc data]$ bash -c ‘typeset -f‘
say_hello ()
{
echo hello world
}
declare -fx say_hello
declare命令是Bash内置的，用来限定变量的属性，-f表示say_hello是一个函数，-x参数表示say_hello被export成一个环境变量，所以这句话的意思是让say_hello成了全局有效的函数。

其实Bash本身其实是想在启动时初始环境变量以及定义一些函数，而初始的方式就是去把 变量名=值 这样的赋值语句用eval去执行一次，如果出现了函数定义，就把它转变成函数，除此之外就不想让它干其他的了，可偏偏它在扫描到函数定义时，把它转变成函数的过程中不小心执行了后面的命令，这其实不是eval的错，这是做语法解析时没考虑严格，所以补丁加了这么一句话来判断函数体合法性：

if ((flags & SEVAL_FUNCDEF)  && command->type != cm_function_def)

上面的官方补丁打了补丁之后，随后被绕过

执行下面命令：

上面这段代码运行起来会报错，但是它要的就是报错，报错后会在你在当前目录下生成一个echo的文件，这个文件的内容是一个时间文本。下面是上面 这段命令执行出来的样子。

官方提供的第一个补丁主要修改了：

1、参数类型和个数的限制，从注释中即可看出：

#define SEVAL_FUNCDEF 0x080       /* only allow function definitions */
#define SEVAL_ONECMD  0x100       /* only allow a single command */

2、给builtins/evalstring.c文件里的parse_and_execute加入了类型判断：

if ((flags & SEVAL_FUNCDEF) && command->type != cm_function_def)
{
不合法，不是函数定义
break;
}

...

// 逻辑为真就表明参数不合法
if (flags & SEVAL_ONECMD)
break;

从上面即可看出补丁思路：如果不是函数定义、命令（command）超过一个就判为不合法。什么才算合法呢，Bypass POC给出了答案：
env X=‘() { (x)=>\‘ ./bash -c ‘my echo hello‘
只要函数体满足() {打头就行了。并且这条POC也满足单个命令（command），因为没出现“;”。

Bash Shell在eval的时候遇到语法问题(x)=被忽略了。语法出错后，在缓冲区中就会只剩下了 “>\”这两个字符

接着就来到重点了，新的bash进程执行了这条命令：
$>\

my echo hello

如果你了解bash，你会知道 \ 是用于命令行上换行的，于是相当于执行了
$>\my echo hello

然后在路径下生成了my文件，内容为hello。

Bash语法极其怪异，让我们逐一分析。

字符\是个转移字符，会保留后面跟的文本，\my实际等于字符串my，如果没有\，新的bash进程会把my当作是命令。因为如果你在终端只输入\并回车，当前bash进程会阻塞等待你输入，在POC里，“输入”的就是my。

字符>就是传说中的重定向，假设要把进程A的输出写入到文件B中，就写成如下：
A > B
其实你写成> B A形式也可以，不信试试：
[lu4nx@lx-pc /tmp]$ > hi date
[lu4nx@lx-pc /tmp]$ cat hi
2014年 09月 27日 星期六 01:06:06 CST
这种前缀写法我也是头一次见到，这次分析Shell源码，看得出它的设计极其像一个Lisp解析器，我以为这种写法是照顾Lisper，因为 Bash结构基本上就是一个交互式（REPL）和eval，而Lisp解析器的核心就是eval，直到我看了Shell的Yacc语法分析 （parse.y）后，我才恍然大悟。重定向的语法定义如下：
redirection: ‘>‘ WORD
{
redir.filename = $2;
$$ = make_redirection (1, r_output_direction, redir);
}
这里表示，输出的文件是取自$2，$2在这段表示参数WORD，如果输入的语句是> A B，那么WORD的实参就是A;如果输入的语句是A > B，那么WORD的实参就是B。

所以POC的思路就是定义一个语法不合法的函数体，绕过函数定义的检测代码，然后执行了后面的命令，最终让Bash在初始化的时候执行了>\my echo hello。

 参考改编文章

http://coolshell.cn/

http://blog.knownsec.com/2014/09/bash_3-0-4-3-command-exec-analysis/

http://blog.knownsec.com/2014/09/bash_3-0-4-3-command-exec-patch-bypass-analysis/

http://www.antiy.com/response/CVE-2014-6271.html

破壳漏洞(shellshock)分析CVE-2014-6271

标签：shellshock   破壳漏洞   bash   shell   

原文地址：http://blog.csdn.net/tinyletero/article/details/40261593