首页 > 代码库 > 破壳漏洞(shellshock)分析CVE-2014-6271
破壳漏洞(shellshock)分析CVE-2014-6271
前段时间的破壳漏洞让各个公司忙的够呛,漏洞也过去一段时间了,大牛们的各种分析网上也是转来转去。等他们消停了,该我好好收集资料消化消化这个漏洞了。
漏洞简介
为什么这个漏洞如此受关注?
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 | $ export var= "hello coolshell" |
这样,这个环境变量就会在其子进程中可见了。
如果你要查看一下有哪些环境变量可以在子进程中可见(也就是是否被export了),你可使用env命令。不过,env命令也可以用来定义export的环境变量。如下所示:
1 | $ env var= "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: command not 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_hellodeclare
命令是Bash内置的,用来限定变量的属性,-f表示say_hello
是一个函数,-x参数表示say_hello
被export成一个环境变量,所以这句话的意思是让say_hello
成了全局有效的函数。
其实Bash本身其实是想在启动时初始环境变量以及定义一些函数,而初始的方式就是去把 变量名=值
这样的赋值语句用eval去执行一次,如果出现了函数定义,就把它转变成函数,除此之外就不想让它干其他的了,可偏偏它在扫描到函数定义时,把它转变成函数的过程中不小心执行了后面的命令,这其实不是eval的错,这是做语法解析时没考虑严格,所以补丁加了这么一句话来判断函数体合法性:
if ((flags & SEVAL_FUNCDEF) && command->type != cm_function_def)
上面的官方补丁打了补丁之后,随后被绕过
执行下面命令:
1 | env X=‘() { (a)=>\‘ sh -c "echo date" ; cat echo |
上面这段代码运行起来会报错,但是它要的就是报错,报错后会在你在当前目录下生成一个echo的文件,这个文件的内容是一个时间文本。下面是上面 这段命令执行出来的样子。
1 2 3 4 5 | $ env X=‘() { (a)=>\‘ sh -c "echo date" ; cat echo sh: X: line 1: syntax error near unexpected token `=‘ sh: X: line 1: `‘ sh: error importing function definition 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