CVE: 2014-6271、CVE: 2014-7169 PATCH方案分析

目录

1. RedHat官方给的PATCH第一套方案
2. RedHat官方给的PATCH临时方案
3. RedHat官方给的PATCH第二套方案

1. RedHat官方给的PATCH第一套方案

0x1: Patch修补原理

patch修复的重点有以下几个地方

1. 在builtins/common.h中增加了2种宏定义，对环境变量允许传入和解析的参数进行了限制，这是一种参数化防御的思想

2. 在builtins/evalstring.c中的parse_and_execute()函数中对即将解析的环境变量参数进行了边界检测

类型的定义在command.h中，对指令的类型进行了定义

/command.h

patch的修复思路是对传入的参数的类型进行判断，如果参数不是一个cm_function_def，即不是一个完整的函数定义指令，则认为产生了代码注入

0x2: 修补后存在的bypass问题

patch修复代码的关键点在于对输入参数的类型判断，即

我们可以从这点进行反向思考，如果我们能使我们的command的类型达到cm_function_def的目的，就可以bypass这个patch code了

poc

env X=‘() { (a)=>\‘ sh -c "echo whoami"; cat echo 

通过构造半开的半闭合"{"来伪造出一个未完成的函数定义，通过这个半开的函数定义"{"，在通过检测逻辑代码的时候，command->type被识别成了cm_function_def，然后在代码解析执行的时候又重新暴露出代码执行的目的，一个典型的bypass逻辑

Relevant Link:

http://ftp.gnu.org/pub/gnu/bash/bash-4.1-patches/bash41-012

2. RedHat官方给的PATCH临时方案

A workaround is available which can mitigate this issue without patching bash. Please note that this workaround has only been subjected to very limited testing, and it may have unintended consequences

0x1: 临时方案的防御思路

bash_ld_preload.c

#include <sys/types.h>
#include <stdlib.h>
#include <string.h>

static void __attribute__ ((constructor)) strip_env(void);
extern char **environ;

static void strip_env()
{
    char *p,*c;
    int i = 0;
    for (p = environ[i]; p!=NULL;i++ )
    {
        c = strstr(p,"=() {");
        if (c != NULL)
        {
            *(c+2) = ‘\0‘;
        }
        p = environ[i];
    }
}

Compile it:

gcc bash_ld_preload.c -fPIC -shared -Wl,-soname,bash_ld_preload.so.1 -o bash_ld_preload.so

Copy bash_ld_preload.so to /lib:

cp bash_ld_preload.so /lib/

修改apache的.so加载路径

vim /etc/init.d/httpd
LD_PRELOAD=/lib/bash_ld_preload.so
export LD_PRELOAD

重启apache

service httpd restart

继续用bypass poc攻击

加载了了patch之后，.so文件对我们的传入的畸形参数进行过滤、清洗，从功能上来说是达到了修复的目的

0x2: 临时方案的风险

这种方案可能导致依赖进行自定义函数的bash指令的程序失效，如果机器上的程序使用了bash脚本命令，并且其中包含了"(){"函数定义，或者是其他的用途，则会直接被删除，风险系数较高，官方的建议是这种临时方案需要谨慎使用

Relevant Link:

http://seclists.org/oss-sec/2014/q3/650
http://ftp.gnu.org/pub/gnu/bash/bash-4.2-patches/bash42-048

3. RedHat官方给的PATCH第二套方案

0x1: Patch的修复原理

1. 对输入的参数进行了参数化定义

2. 对输入参数进行边界剥离

3.  对边界剥离后的参数进行合法性判断

通过这种方案，很好的防御住了半开的代码注入

0x2: Patch方案的风险

经过代码评估，Redhat的这次方案应该没有明显的问题，可以作为稳定的Patch升级方案

Relevant Link:

https://rhn.redhat.com/errata/RHSA-2014-1306.html

Copyright (c) 2014 LittleHann All rights reserved