首页 > 代码库 > 破壳漏洞(shellshock)分析CVE-2014-6271

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

2024-07-28 02:20:11   219人阅读

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


漏洞简介

GNU Bash 4.3及之前版本在评估某些构造的环境变量时存在安全漏洞，向环境变量值内的函数定义后添加多余的字符串会触发此漏洞，攻击者可利用此漏洞改变或绕过环境限制，以执行Shell命令。某些服务和应用允许未经身份验证的远程攻击者提供环境变量以利用此漏洞。此漏洞源于在调用Bash Shell之前可以用构造的值创建环境变量。这些变量可以包含代码，在Shell被调用后会被立即执行。
破壳漏洞的严重性被定义为10级（最高），今年4月爆发的OpenSSL“心脏出血”漏洞才5级！

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

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中要定义一个环境变量的语法很简单（注：=号的前后不能有空格）：

1
$ var="hello world"

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

你可以做这样的测试：

1
2
3
4
5
$ var="hello coolshell"
$echo$var
hello coolshell
$bash
$echo$var

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

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

1
$exportvar="hello coolshell"

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

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

1
$envvar="hello haoel"

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

bash的函数

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

1
2
3
$ foo(){echo"hello coolshell"; }
$ foo
hello coolshell

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

1
2
3
4
5
6
$ foo(){echo"hello coolshell"; }
$ foo
hello coolshell
$bash
$ foo
bash: foo:commandnot found

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

1
2
3
4
5
6
7
$ foo(){echo"hello coolshell"; }
$ foo
hello coolshell
$export-f foo
$bash
$ foo
hello coolshell

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)

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

执行下面命令：

1
envX=‘() { (a)=>\‘ sh -c"echo date";catecho

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

1
2
3
4
5
$envX=‘() { (a)=>\‘ sh -c "echo date";catecho
sh: X: line 1: syntax error near unexpected token `=‘
sh: X: line 1: `‘
sh: error importingfunctiondefinition for`X‘
Sat Sep 27 22:06:29 CST 2014
原理分析：


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

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


联系
我们