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逻辑

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

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

#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攻击

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

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

原文：http://www.cnblogs.com/LittleHann/p/3993927.html