Fuzzing - 标签 - 有价值炮灰 https://evilpan.com/tags/fuzzing/ Fuzzing - 标签 - 有价值炮灰 Hugo -- gohugo.iozh-CNi@pppan.net (evilpan) i@pppan.net (evilpan)This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.Sat, 09 Sep 2023 12:40:00 +0800 Fuzzing 在 Java 漏洞挖掘中的应用 https://evilpan.com/2023/09/09/java-fuzzing/ Sat, 09 Sep 2023 12:40:00 +0800 evilpan https://evilpan.com/2023/09/09/java-fuzzing/

前段时间泛微发布了 10.58.6 补丁，修复好几个笔者之前储备的 0day，本文就来介绍其中一系列比较有意思的漏洞，以及分享一下相关的挖掘思路。

meme

背景

最近几个月笔者都在研究 Java Web 方向，一方面是工作职责的调整，另一方面也想挑战一下新的领域。对于漏洞挖掘而言，选择一个具体目标是非常重要的，经过一段时间供应链和生态的学习以及同事建议，兼顾漏洞挖掘难度和实战效果选择了泛微OA作为第一个漏洞挖掘的目标。

代码审计

虽然本文介绍的是 Fuzzing，但之前也说过很多次，自动化漏洞挖掘只能作为一种辅助手段，是基于自身对代码结构的理解基础上的提效方式。

在真正开始挖漏洞之前，笔者花了好几周的时间去熟悉目标的代码，并且对一些不清晰的动态调用去进行运行时分析，最终才能在 20G 代码之中梳理出大致的鉴权和路由流程。

draft.png

本文介绍的就是其中红框中的漏洞

通过分析 JavaEE 应用注册的路由，注意到其中一个映射:

ServletMapping[url-pattern=/services/*, name=XFireServlet] ^/services(?=/)|^/services\z]

其对应的类为 org.codehaus.xfire.transport.http.XFireConfigurableServlet:

<servlet>
    <servlet-name>XFireServlet</servlet-name>
    <display-name>XFire Servlet</display-name>
    <servlet-class>org.codehaus.xfire.transport.http.XFireConfigurableServlet</servlet-class>
</servlet>
<servlet-mapping>
    <servlet-name>XFireServlet</servlet-name>
    <url-pattern>/services/*</url-pattern>
</servlet-mapping>

XFire 考古

XFire 并不是泛微自己的业务代码，而是一个 SOAP Web 服务框架，它是作为 Apache Axis 的有效替代方案而开发的。除了通过使用 StAX 实现良好性能的目标外，XFire 的目标还包括通过各种插件机制实现灵活性，API 的直观操作以及与通用标准的兼容性。此外 XFire 非常适合集成到基于 Spring Framework 的项目中。

值得一提的是，XFire 目前已经不再进行开发，其官方继任者是 Apache CXF。

XFire 的用法比较简单，首先在 META-INF/xfire/services.xml 中定义需要导出的服务，比如:

<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://xfire.codehaus.org/config/1.0">
    <service>
        <name>WorkflowService</name>
        <namespace>webservices.services.weaver.com.cn</namespace>
        <serviceClass>weaver.workflow.webservices.WorkflowService</serviceClass>
        <implementationClass>weaver.workflow.webservices.WorkflowServiceImpl</implementationClass>
        <serviceFactory>org.codehaus.xfire.annotations.AnnotationServiceFactory</serviceFactory>
    </service>
</beans>

这样 weaver.workflow.webservices.WorkflowService 就被认为是导出服务。

可以直接被客户端进行调用。调用方式主要是通过 SOAP 请求到 XFireServlet，例如调用上述服务可以发送 POST 请求到 /services/WorkflowService:

<?xml version="1.0" encoding="UTF-8"?>
  <Body>
    <getUserId>
<p>evilpan</p>
<p>2333</p>
    </getUserId>
  </Body>

表示以指定参数调用服务的 getUserId 方法。

SQL 注入

接下来回到漏洞本身，WorkflowService 服务的具体实现为 WorkflowServiceImpl，例如其中的 getUserId 就是服务导出的一个方法，其具体实现为:

@Override
public String getUserId(String var1, String var2) {
    if (Util.null2String(var2).equals("")) {
        return "-1";
    } else if (Util.null2String(var1).equals("")) {
        return "-2";
    } else {
        RecordSet var3 = new RecordSet();
        var3.executeQuery("select id from HrmResource where " + var1 + "=? and status<4 ", var2);
        return !var3.next() ? "0" : Util.null2s(var3.getString("id"), "0");
    }
}

可以看到，一个教科书式的 SQL 注入就已经找到了。

Service 鉴权

现在漏洞点找到了，触发路径也找到了，可实际测试的时候发现这个接口有些特殊的鉴权，其鉴权逻辑为判断请求地址是否是内网地址，如果是的话就放行。

考虑到很多系统是集群部署的，且前面有一层或者多层负载均衡，因此实际请求服务的可能是经过反向代理的请求，此时客户端的真实 IP 只能通过 X-Forward-For 等头部获取。

这本来无可厚非，但是 HTTP 请求头是可以被攻击者任意设置的，因此泛微在此基础上进行了复杂的过滤，精简后的伪代码如下:

private String getRemoteAddrProxy() {
    String ip = null;
    String tmpIp = null;
    tmpIp = this.getRealIp(this.request.getHeaders("RemoteIp"), ipList);
    if (ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) {
        ip = tmpIp;
    }
    boolean isInternalIp = IpUtils.internalIp(ip);
    if (isInternalIp) {
    ipList.add(this.request.getRemoteAddr());
    tmpIp = IpUtils.getRealIp(ipList);
    if (!IpUtils.internalIp(tmpIp)) {
        ip = tmpIp;
    }
    }

    return ip != null && ip.length() != 0 && !"unknown".equalsIgnoreCase(ip) ? ip : null;
}

IpUtils#internalIp 的判断更为复杂，连 byte[] 都出来了:

public static boolean internalIp(String ip) {
    if (ip != null && !ip.equals("127.0.0.1") && !ip.equals("::1") && !ip.equals("0:0:0:0:0:0:0:1")) {
    if (ip.indexOf(":") != -1 && ip.indexOf(":") == ip.lastIndexOf(":")) {
        ip = ip.substring(0, ip.indexOf(":"));
    }

    byte[] addr = (byte[])null;
    if (isIpV4(ip)) {
        addr = textToNumericFormatV4(ip.trim());
    } else {
        addr = textToNumericFormatV6(ip.trim());
    }

    return addr == null ? false : internalIp(addr);
    } else {
    return true;
    }
}

public static boolean internalIp(byte[] addr) {
  byte b0 = addr[0];
  byte b1 = addr[1];
  byte SECTION_1 = true;
  byte SECTION_2 = true;
  byte SECTION_3 = true;
  byte SECTION_4 = true;
  byte SECTION_5 = true;
  byte SECTION_6 = true;
  switch (b0) {
    case -84:
      if (b1 >= 16 && b1 <= 31) {
        return true;
      }
    case -64:
      switch (b1) {
        case -88:
          return true;
      }
    default:
      return false;
    case 10:
      return true;
  }
}

其逻辑是对 getRemoteAddrProxy 取出来的 IP，如果路径匹配 webserviceList 且 IP 匹配 webserviceIpList 前缀，就认为是内网地址的请求从而进行放过:

webserviceList = [
   "/online/syncOnlineData.jsp",
   "/services/",
   "/system/MobileLicenseOperation.jsp",
   "/system/PluginLicenseOperation.jsp",
   "/system/InPluginLicense.jsp",
   "/system/InMobileLicense.jsp"
];

webserviceIpList = [
   "localhost",
   "127.0.0.1",
   "192.168.",
   "10.",
   "172.16.",
   "172.17.",
   "172.18.",
   "172.19.",
   "172.20.",
   "172.21.",
   "172.22.",
   "172.23.",
   "172.24.",
   "172.25.",
   "172.26.",
   "172.27.",
   "172.28.",
   "172.29.",
   "172.30.",
   "172.31."
]

根据上面的代码，你能发现鉴权绕过的漏洞吗？

Fuzzing

也许对代码比较敏感的审计人员可以通过上述鉴权代码很快发现问题，但说实话我一开始并没有找到漏洞。于是我想到这个鉴权逻辑是否能单独抽离出来使用 Fuzzing 的思路去进行自动化测试。

之前发现 Java 也有一个基于 libFuzzer 的模糊测试框架 Jazzer，但是试用之后发现比较鸡肋，因为和二进制程序会自动 Crash 不同，Java 的 fuzz 需要自己指定 Sink，令其在触达的时候抛出异常来构造崩溃。

虽然说没法发现通用的漏洞，但是对于现在这个场景来说正好是绝配，我们可以将目标原始的鉴权代码抠出来，然后在未授权通过的时候抛出一个异常即可。构建的 Test Harness 代码如下:

public static void fuzzerTestOneInput(FuzzedDataProvider data) {
    String poc = data.consumeRemainingAsString();
    fuzzIP(poc);
}

public static void fuzzIP(String poc) {
    if (containsNonPrintable(poc)) return;
    XssRequestWeblogic x = new XssRequestWeblogic();
    String out = x.getRemoteAddr(poc);
    boolean check2 = check2(out);
    if (check2) {
        throw new FuzzerSecurityIssueHigh("Found IP [" + poc + "]");
    }
}

public static boolean check2(String ipstr) {
    for (String ip: webserviceIpList) {
        if (ipstr.startsWith(ip)) {
            return true;
        }
    }
    return false;
}

其中精简了一些泛微代码中读取配置相关的依赖，将无关的逻辑进行手动剔除。

编译好代码后，使用以下命令开始进行 fuzz:

$ ./jazzer --cp=target/Test-1.0-SNAPSHOT.jar --target_class=org.example.App

不多一会儿，就已经有了一个成功的结果！

fuzz.png

可以看到图中给出了 127.0.0.10 这个 payload，可以触发 IP 鉴权的绕过！反过来分析这个 PoC，可以发现之所以能绕过是因为 webserviceIpList 只检查了前缀，而 127.0.0.10 可以在 internalIp 返回 False，即认为不是内部 IP，但实际上 webserviceIpList 却认为是内部 IP，从而导致了绕过。

如果只是从代码上去分析的话，可能一时半会并不一定能发现这个问题，可是通过 Fuzzing 在覆盖率反馈的加持下，却可以在几秒钟之内找到正解，这也是人工审计无法比拟的。

漏洞补丁

通过 IP 的鉴权绕过和 XFire 组件的 SQL 注入，笔者实现了多套前台的攻击路径，并且在 HW 中成功打入多个目标。因为当时提交的报告中带了漏洞细节，因此这个漏洞自然也就被官方修补了。如果没有公开的话这个洞短期也不太会被撞到。

漏洞修复的关键补丁如下:

diff --git a/src/weaver/security/webcontainer/IpUtils.java b/src/weaver/security/webcontainer/IpUtils.java
index 6b3d8efc..e7482511 100644
--- a/src/weaver/security/webcontainer/IpUtils.java
+++ b/src/weaver/security/webcontainer/IpUtils.java
@@ -48,12 +48,16 @@ public class IpUtils {
    }

    public static boolean internalIp(String ip) {
-      if (ip != null && !ip.equals("127.0.0.1") && !ip.equals("::1") && !ip.equals("0:0:0:0:0:0:0:1")) {
+      if (ip == null || ip.equals("127.0.0.1") || ip.equals("::1") || ip.equals("0:0:0:0:0:0:0:1")) {
+         return true;
+      } else if (ip.startsWith("127.0.0.")) {
+         return true;
+      } else {
          if (ip.indexOf(":") != -1 && ip.indexOf(":") == ip.lastIndexOf(":")) {
             ip = ip.substring(0, ip.indexOf(":"));
          }

其中把 equals 换成了 startsWith，并且还过滤了我们之前使用的 WorkflowService 组件。当然还是沿袭泛微一贯的漏洞修复原则，不改业务代码，只增加安全校验，这也是对历史遗留问题的一种妥协吧。

总结

  1. 对于 Java 这样的内存安全编程语言也是可以 fuzz 的，只不过目的是找出逻辑漏洞而不是内存破坏；
  2. 漏洞挖掘初期花时间投入到代码审计中是有必要的，有助于理解项目整体结构并在后期进行针对性覆盖；
  3. 漏洞挖掘的时候重点关注边界的系统和服务，处于信任边界之外的组件更有可能过于信任外部输入导致安全问题；
  4. 对于看起来很复杂的数据处理模块，可以充分利用 Fuzzing 的优势，帮助我们快速找出畸形的 payload；
  5. 模块化 Fuzzing 的难点在于抽离代码并构建可编译或者可以独立运行的程序，即构建 Test Harness，跑起来测试用例你就已经成功了 90%；
  6. 软件开发和漏洞挖掘正好相反。开发者会出于厌恶情绪刻意避开复杂的历史遗留代码，而这些代码却是更可能出现问题的地方。因此安全研究员要学会克服自己的厌恶情绪，做到 —— “明知山有屎，偏向屎山行”。

版权声明: 自由转载-非商用-非衍生-保持署名 (CC 4.0 BY-SA)
原文地址: https://evilpan.com/2023/09/09/java-fuzzing/
微信订阅: 『有价值炮灰』
– TO BE CONTINUED.

]]> 针对二维码解析库的 Fuzzing 测试 https://evilpan.com/2023/06/10/fuzzing-qrcode/ Sat, 10 Jun 2023 11:30:00 +0800 evilpan https://evilpan.com/2023/06/10/fuzzing-qrcode/

Fuzzing QR Code for fun and no profit~

背景

在四月份的时候出了那么一个新闻，说微信有一个打开图片就崩溃的 bug，当时微信群里都在传播导致手机各种闪退。

wechat.png
聊天记录

由于当时笔者正在忙着卷 Java Web，没有第一时间去蹭这个热点，不过当时也稍微了解了一下 crash 的原理。最近对于 Java 的漏洞挖掘正好告一段落，于是就突然想起了这个事。

这个 bug 的根源在于一个畸形的二维码解码时导致的空指针错误，详细分析和修复的记录可以参考 fix(wechat_qrcode): Init nBytes after the count value is determined #3480。

在国内二维码可以说是随处可见的东西，如果说解码的核心 SDK 有漏洞，那么很可能影响非常广泛。加上许多应用，基于各种奇怪的业务和目的还实现了静默解码的功能，要是能够发现一个可以利用的漏洞，那也是一个典型的 0-click 场景。

因此笔者打算简单 Fuzz 一下相关的二维码解码代码，放在服务器后台慢慢跑着，也不会过多占用搬砖时间，希望哪天清晨 boki 醒来能够有些意外收获。

编译

Fuzz 的第一步自然是先能成功编译目标代码，然后再尝试使用带插桩的编译器进行编译。

之前出现问题的代码仓库是 https://github.com/opencv/opencv_contrib，这是 opencv 下的一个子仓库，提供了许多额外的 OpenCV 模块，根据 README 的介绍，编译这些模块的过程如下:

$ cd <opencv_build_directory>
$ cmake -DOPENCV_EXTRA_MODULES_PATH=<opencv_contrib>/modules <opencv_source_directory>
$ make -j5

也就是说编译这些模块还需要依赖 OpenCV 的源代码仓库，因此我们把这两个仓库都下载下来进行编译。这里图省事我就直接使用 AFL++ 进行编译了，使用 cmake 的编译命令如下:

cmake -DCMAKE_C_COMPILER=afl-clang-fast -DCMAKE_CXX_COMPILER=afl-clang-fast++ \
  -DCMAKE_CXX_FLAGS="-fsanitize=address,undefined -fno-sanitize-recover=all -g" \
  -DCMAKE_C_FLAGS="-fsanitize=address,undefined -fno-sanitize-recover=all -g" \
  -DCMAKE_EXE_LINKER_FLAGS="-fsanitize=address,undefined -fno-sanitize-recover=all" \
  -DCMAKE_MODULE_LINKER_FLAGS="-fsanitize=address,undefined -fno-sanitize-recover=all" \
  -DCMAKE_BUILD_TYPE=Debug,ASAN,UBSAN -DWITH_SSE2=ON -DMONOLITHIC_BUILD=ON -DBUILD_SHARED_LIBS=OFF \
  -DOPENCV_EXTRA_MODULES_PATH=/home/evilpan/fuzzing/opencv_contrib/modules \
  /home/evilpan/fuzzing/opencv

make -j128 -C modules/wechat_qrcode

关键点在于不编译动态库，而是使用静态库，因为 AFL 对于最终的测试程序只会测试静态编译代码中的覆盖率而不会考虑动态编译的库。

后来发现 cmake 可以不用指定那么多选项，只需要指定 afl-clang，config 之后在 make 时通过环境变量指定 AFL_USE_ASAN 即可，AFL 会选择好合适的编译参数。参考: https://aflplus.plus/docs/fuzzing_in_depth/

$ cmake -DCMAKE_C_COMPILER=afl-clang-fast -DCMAKE_CXX_COMPILER=afl-clang-fast++ -DBUILD_SHARED_LIBS=OFF
$ env AFL_USE_ASAN=1 make -j32

小试牛刀

编译完后就可以编写测试代码了。不过根据前面的 pull-request，在修复漏洞时也提供了一个 testcase:

TEST(Objdetect_QRCode_bug, issue_3478) {
    auto detector = wechat_qrcode::WeChatQRCode();
    std::string image_path = findDataFile("qrcode/issue_3478.png");
    Mat src = imread(image_path, IMREAD_GRAYSCALE);
    ASSERT_FALSE(src.empty()) << "Can't read image: " << image_path;
    std::vector<std::string> outs = detector.detectAndDecode(src);
    ASSERT_EQ(1, (int) outs.size());
    ASSERT_EQ(16, (int) outs[0].size());
    ASSERT_EQ("KFCVW50         ", outs[0]);
}

可以参考这个代码来编写我们的 test-harness。我这里是直接改掉了 test_main.cpp，不使用单元测试框架而是直接自己编写，一个初始的 test-harness 代码如下:

int main(int argc, char **argv) {
  if (argc < 2) return 1;
  std::string image_path(argv[1]);
  Mat src = imread(image_path, IMREAD_GRAYSCALE);
  if (!src.empty()) {
    auto detector = wechat_qrcode::WeChatQRCode();
    std::vector<std::string> outs = detector.detectAndDecode(src);
  }
  return 0
}

修改后只需要重新编译这个模块即可:

make -C modules/wechat_qrcode

生成的测试二进制文件为 build/bin/opencv_test_wechat_qrcode:

afl-fuzz -i corpus/ -o output -t +2000 -- ./opencv_test_wechat_qrcode @@

corpus 中随便丢了几张畸形二维码文件，直接开跑！

test1.png
Jack, slow fuzz

虽然能跑，但是慢的一批！

初步优化

上面的的 fuzz 代码实在太慢，必须要进行优化！组织架构调整！把寒气也传递给每一个 fuzzer！

由于前面的的运行是直接读取文件，因此一个直观的优化是使用 AFL++ 的 persistent mode，稍微修改一下代码，直接把 buffer 当做源图片进行读取，如下所示:

int fuzz_buf(unsigned char *buf, size_t size) {
  Mat src = imdecode(Mat(1, size, CV_8UC1, buf), IMREAD_GRAYSCALE);
  if (!src.empty()) {
    auto detector = wechat_qrcode::WeChatQRCode();
    std::vector<std::string> outs = detector.detectAndDecode(src);
    return outs.size();
  }
  return -1;
}

__AFL_FUZZ_INIT();

int main(int argc, char **argv) {
  // if (argc < 2) return 1;
  // return fuzz(argv[1]);
#ifdef __AFL_HAVE_MANUAL_CONTROL
  __AFL_INIT();
#endif
  unsigned char *buf = __AFL_FUZZ_TESTCASE_BUF;
  while (__AFL_LOOP(10000)) {
    int len = __AFL_FUZZ_TESTCASE_LEN;
    fuzz_buf(buf, len);
  }
  return 0;
}

这次执行就不需要 @@ 了，可以直接运行:

afl-fuzz -i corpus/ -o output -t +2000 -- ./opencv_test_wechat_qrcode_persist

test2.png
Fuzzing cv::Mat

可以看到速度已经有了显著的提升！并且跑了十几分钟后就已经出现了 Crash！

再次优化

先暂停前面的 fuzzer 来分析一下现有的 crash，执行出现的崩溃都大致如下所示:

$ ./opencv_test_wechat_qrcode output/default/crashes/id\:000001\,sig\:06\,src\:000478\,time\:871148\,execs\:98951\,op\:havoc\,rep\:4
terminate called after throwing an instance of 'cv::Exception'
  what():  OpenCV(4.7.0-dev) /home/jielv/fuzzing/opencv/modules/imgcodecs/src/loadsave.cpp:74: error: (-215:Assertion failed) size.width > 0 in function 'validateInputImageSize'

Aborted

其实，我对你是有一些失望的。当初把你写出来，是希望你能对标古河的。我是希望你跑起来后，你能够拼一把，快速给我几个 segment fault。对于你这个层级，不是丢出几个 Abort 就可以的。

虽然也有我 -g 的原因，但这里的 Abort 实际上都出现在上面的 imdecode 中，这跟我的预期有点跑偏，明明想跑的是二维码解码，结果却在无关的地方运行了半天。虽然 image codec 也是一个攻击面，但并不是现在想要搞的，而且这个攻击面肯定也被很多其他人搞过了，出现问题的几率并不是很大。

因此，我们需要进一步优化代码。现在 AFL 变异的是 jpg/png 的图片，但我们想要变异的其实是二维码的图片内容！因此这次优化有两个思路:

  1. 提供自定义的变异策略，每次返回一个变异的二维码；
  2. 还是让 AFL 自己变异，但是变异后的内容直接转成 cv::Mat 然后进行二维码解码；

不管使用哪个思路，都需要能够将图片和 cv::Mat 进行互相转换，否则即便有 crash 也可能不能生成合法的图片导致无法利用。

一开始想着偷个懒，直接让 ChatGPT 来帮我生成代码将 Mat 转成字符数组，如下所示:

std::vector<char> mat_to_vector(const cv::Mat& mat) {
    // Copy data from cv::Mat to vector<char>
    std::vector<char> data(mat.data, mat.data + mat.total() * mat.elemSize());
    return data;
}

然后，将原来的预料图片用 imread 读取成 cv::Mat，并用上面的函数转成 vector 并保存到磁盘中，形成新的预料，这样在变异的时候可以直接变异并生成 cv::Mat:

int fuzz_buf(unsigned char *buf, size_t size) {
  // Mat src = imdecode(Mat(1, size, CV_8UC1, buf), IMREAD_GRAYSCALE);
  Mat src = Mat(std::vector<unsigned char>(buf, buf + size));
  return fuzz_mat(src);
}

理想很美好，但是这样跑并没有结果！猜测是 Mat 中除了 data 数据，应该还有一些元数据(metadata)，用以表示矩阵的特性，比如行/列，直接填入数据无法表示原始的矩阵，从而在二维码解码时很早就出错退出了。

既然偷懒走不通，就只能认真看一下 Mat 了。

cv::Mat 是 OpenCV 中用于表示 n 维数组的数据结构，用于表示 n 维的单通道或者多通道数组，通常是结构比较紧凑的矩阵。对于稀疏数据的高维矩阵则一般用 SparseMat 来进行表示。

对于矩阵/数组 M 而言，其数据布局根据 data 和 step 决定，例如对于二维数组:

M.at(i,j) = M.data + M.step[0] * i + M.step[1] * j

注意 M.step[i] >= M.step[i+1]，事实上 M.step[i] >= M.step[i+1]*M.size[i+1]。这意味着对于二维矩阵而言，数据是按照行进行存储的(row-by-row)，而对于三维矩阵数据则是按面进行存储(plane-by-plane)。

我们的目标是创建一个代表二维码图片的 Mat，最好是能够保存到磁盘中并从磁盘读取，方便我们使用 afl-fuzz 指定语料并进行 fuzz。于是想着有没有什么序列化/反序列化是针对 cv::Mat 的，查了一下还真有，序列化的代码如下:

cv::Mat img = cv::imread("example.jpg"); // Load an image
cv::FileStorage fs("example.yml", cv::FileStorage::WRITE); // Create a file storage object for writing
fs << "image" << img; // Write the image to the file
fs.release(); // Close the file

反序列化过程和序列化过程类似:

cv::Mat img;

cv::FileStorage fs("example.yml", cv::FileStorage::READ); // Create a file storage object for reading
fs["image"] >> img; // Read the image from the file
fs.release(); // Close the file

这里是将 cv::Mat 序列化成了 YAML 数据，输出的格式如下:

%YAML:1.0
---
img: !!opencv-matrix
   rows: 480
   cols: 640
   dt: u
   data: [ 103, 103, 104, 107, 110, 112, 112, 111, 114, 113, 113, 115,
           ...
           134, 135, 134, 132 ]

如果将 YAML 文件作为语料的话，又涉及了 YAML 的解析以及 FileStorage 中的无关代码，和需求有所差距。不过从序列化的数据中我们能够看出一点，即 cv::Mat 中除了 data 数据外包含的额外元数据只有 rows、cols 和 dt。其中 dt 应该表示 data type，u 是 CV_8U 的缩写。

由于这是一个黑白的，480x640 的二维码图片，如果我们想要变异 cv::Mat，只需要保存行/列/类型不变，针对 data 区域进行 bitflip 变异即可！

不过，只进行 bitflip 变异的空间将会高达 2^(640*480)，无疑是个几何数据，即便是只针对小尺寸图片如 20x20 那也是不能接受的。因此我们还是寄希望于 AFL 的覆盖率反馈能产生合适的变异！

使用上述策略优化之后裁剪语料的长度，仅使用一个 29x29 的二维码图片生成的矩阵作为初始语料进行变异:

int fuzz_buf(void *buf, size_t size) {
  // Mat src = imdecode(Mat(1, size, CV_8UC1, buf), IMREAD_GRAYSCALE);
  if (size < 841) return -1;
  Mat src = Mat(29, 29, CV_8U, buf);
  return fuzz_mat(src);
}

跑起来之后发现速度又变得很慢，估计语料还是太大，先放在后台跑一会，然后去看了两集异世界厕纸番。回来之后发现居然有 crash:

test3.png

简单分析一下发现都是同一处代码的 crash，精简的 poc 执行输出如下:

$ opencv_test_wechat_qrcode poc.bin
/home/evilpan/fuzzing/opencv_contrib/modules/wechat_qrcode/src/zxing/qrcode/detector/detector.cpp:1022:50: runtime error: signed integer overflow: -2147483648 + -2147483648 cannot be represented in type 'int'

这是一个整数溢出，出现在 qrcdoe 检测过程中计算维度时:

int Detector::computeDimension(Ref<ResultPoint> topLeft, Ref<ResultPoint> topRight,
                               Ref<ResultPoint> bottomLeft, float moduleSizeX, float moduleSizeY) {
    int tltrCentersDimension = ResultPoint::distance(topLeft, topRight) / moduleSizeX;
    int tlblCentersDimension = ResultPoint::distance(topLeft, bottomLeft) / moduleSizeY;

    float tmp_dimension = ((tltrCentersDimension + tlblCentersDimension) / 2.0) + 7.0; // 问题在这行
    int dimension = cvRound(tmp_dimension);
    int mod = dimension & 0x03;  // mod 4

    switch (mod) {  // mod 4
        case 0:
            dimension++;
            break;
            // 1? do nothing
        case 2:
            dimension--;
            break;
    }
    return dimension;
}

计算锚点时 tltrCentersDimension + tlblCentersDimension 产生了整数溢出，PoC 如下:

poc.png
PoC: 整数溢出

当然，这个 PoC 直接扫码是扫不出来的，因为我们传入的是原始数据，而且是死在了 detector 之中。

虽然现在已经可以产生一些崩溃，但注意到图像并不是二值图像而是灰度图，因为我们原始的语料是 Mat.data() 保存而成的二进制数据，这个数据中每个像素还是 8 bit 的，只不过只有两种值，分别是 0 和 255，而我们变异过程中就成了灰度图。

为了解决这个问题，我们只能重新构建序列化的数据结构，确保每个字节的变异都能产生有效的二值图像。图像中每个像素只占 1 bit，由于内存是字节寻址的，每个字节可以保存 8 个像素。

写了个 MatWrapper 来封装 cols、rows、type 和 data 数据，并添加 serialize/deserialize 方法去实现序列化:

class MatWrapper {
public:
  int mRows;
  int mCols;
  int mType;
  int mSize;
  std::vector<uchar> mBuf;

  MatWrapper() {}

  void save(const std::string& filename, bool compact=false) {
    std::ofstream fs(filename);
    fs << serialize(compact);
    fs.close();
  }

  void load(const std::string& filename, bool compact=false) {
    std::stringstream ss;
    std::ifstream file(filename, std::ios::binary);
    ss << file.rdbuf();
    deserialize(ss.str(), compact);
  }

  void fromImage(const std::string& filename) {
    auto mat = imread(filename, IMREAD_GRAYSCALE);
    mRows = mat.rows;
    mCols = mat.cols;
    mType = mat.type();
    // assert(mat.elemSize() == 1);
    mSize = mat.total() * mat.elemSize();
    mBuf = std::vector<uchar>(mat.data, mat.data + mSize);
  }

  void toImage(const std::string& filename) {
    imwrite(filename, get());
  }

  Mat get() { return Mat(mRows, mCols, mType, mBuf.data()); }

  std::string serialize(bool compact = false) const { }
  bool deserialize(const std::string& buf, bool compact = false) { }
  // ...
};

compact 表示是否将 8 像素压缩为 1 字节，完整代码比较长这里就不贴了。写完之后先把之前的二维码图片语料批量转换为了自定义序列化的数据，然后使用 AFL 指定新的语料进行变异和 fuzz。一开始跑出来的都是我自己代码的 bug (囧)，挨个修完之后终于可以很快跑出上面的整数溢出了，而这次的 PoC 也是真正的黑白二维码图片。

但是！新的测试用例跑起来也是非常之慢，可能是反序列化的时候做了太多变换，导致速度其实和使用标准的压缩图片格式去跑差不多，总而言之感觉有点白给，但还是让它先跑一会。

二维码

在把上面的 Fuzzer 放在后台运行的时，我也想清楚了这个测试用例的问题所在。当前变异的策略虽然能够生成二值的 Bitmap 图像，但并不总是合法的二维码，所以代码覆盖率始终在 detect 阶段过不去而没有执行到 decode。

一个理想的策略是每次都能生成随机的、合法的二维码，并且在点阵的基础上进行变异。为此，我们需要先了解二维码的实现方式。

一个二维码通常由于多个部分组成，如下所示:

qrcode.png
ISO/IEC 18004 - QR Code bar code symbology specification

此外还有 M3 Micro QR Code，只包含一个定位点，不过比较少用，微信也扫不出来，这里先不介绍。

各个部分的简单介绍如下:

  • Quiet Zone: 二维码周围的白边，底色需要与二维码的颜色不同防止影响解析；
  • Postion Detection Patterns: 位置检测模式，也称为定位点，用于定位二维码；使用点格(module)表示外围黑边大小是 7x7，中间的黑块大小是 3x3；
  • Separators for Postion Detection Patterns: 定位点周围的分隔线，线宽为一个点格；
  • Timing Patterns: 时序模式，用于定位 x/y 轴，二维码弯曲时可以通过这两条线的弯曲去进行一定程度的修复；
  • Alignment Patterns: 对齐模式，在 Version 2 及以后才有，用于进一步辅助对齐。每个对齐模式的大小是黑格 5x5，白格 3x3，中间黑点占一格。对齐模式的个数和 Version 有关；
  • Format Infomation: 格式信息，占 30 个点格，两边各占 15 个，内容相同，互为备份；
  • Version Information: 版本信息，也是有两个互为备份的区块，各占 3x6 大小；
  • Data and Error Correction Codewords: 数据区，包含编码的数据正文以及纠错信息；

二维码的最小单位是点格(module)，一个二维码边长所占点格的大小称为二维码的维度(Dimension)，维度和版本有关:

Dimension = Version * 4 + 17

例如当 Version 等于 2 时，边长就是 25 个点格:

width.png

Format Information 区包含了纠错级别等信息，前面说过一共 15 点格，包括:

  • 纠错等级: 2 点格，即 4 个纠错等级；
  • 数据掩码: 3 点格，即 8 种掩码类型；
  • 纠错码: 10 点格；

纠错码计算使用 BCH Code，用到的 Code Words 就保存在前面说过的数据区。

了解二维码的基础知识之后，我们至少知道了在一个二维码中哪些能变哪些不能变。二维码的编码是相当复杂的，虽然我们可以使用现有的编码策略去生成二维码，但是这会导致我们错过可能由于编码问题导致的漏洞。

秉承着先跑起来再说的原则，三下五除二用 Python 写了一个非常丑陋的原型，首先是生成一个随机的二维码:

def random_qrcode() -> qrcode.QRCode:
    version = randint(1, 40)
    box_size = randint(1, 8)
    border = 1
    error_correction = randint(0, 3)
    mask_pattern = randint(0, 7)
    data = randstr(randint(1, 25))
    
    qr = qrcode.QRCode(
        version=version,
        error_correction=error_correction,
        box_size=box_size,
        border=border,
        image_factory=None,
        mask_pattern=mask_pattern)
    qr.add_data(data)
    qr.make()
    return qr

make 之后 qrcode 的 modules 已经生成了，所以我们在其基础上进行变异:

def mutate(qr: qrcode.QRCode, add_buf):
    if not add_buf or len(add_buf) == 1:
        # do not mutate
        return
    # flip modules in qrcode randomly
    width = len(qr.modules)
    rng = random.Random()
    flipped = set()
    for i in range(0, len(add_buf) - 1, 2):
        val = add_buf[i] + (add_buf[i+1] << 8)
        if val in flipped:
            continue
        flipped.add(val)
        rng.seed(val)
        x = rng.randint(0, width - 1) # col
        y = rng.randint(0, width - 1) # row
        # print("flip", (x, y))
        # avoid position patterns, 7x7 and 1 space
        if x < 8 and y < 8:
            continue
        if x < 8 and y >= (width - 8):
            continue
        if x >= (width - 8) and y < 8:
            continue
        qr.modules[y][x] = not qr.modules[y][x]

qr.modules 是表示点格的二维数组，我们的变异策略非常简单粗暴，就是直接基于输入的数据对点格进行随机的翻转，黑的变白的，白的变黑的。几个小优化:

  1. 使用 Random 来将 0xffff 大小的随机数 scale 到宽度 width 的范围；
  2. 对于已经翻转过的点格就不用再次翻转了；
  3. 随机翻转的范围排除掉三个角落的定位标志区；

现在我们已经可以生成随机的二维码图片了！接下来就需要将其与 Fuzzer 进行结合。在官方文档 Custom Mutators in AFL++ 中提到，我们可以编译一个 .so 并通过 AFL_CUSTOM_MUTATOR_LIBRARY 环境变量给 AFL++ 提供自定义的变异器，而且也可以使用 Python API 来提供变异器。

因此我们的 mutator 如下即可:

def fuzz(buf, add_buf, max_size):
    """
    Called per fuzzing iteration.
    """
    qr = random_qrcode()
    mutate(qr, add_buf)
    img = qr.make_image()
    stream = BytesIO()
    img.save(stream, "png")
    ret = stream.getvalue()
    if len(ret) > max_size:
        return bytearray(buf)
    return bytearray(ret)

注: fuzz 接口的参数 buf 一般包含原始 corpus 的内容，add_buf 则是变异后返回的内容，这里是 PNG 数据。所以前面想把 add_buf 作为变异源来修改 modules 的想法其实是有问题的，当时误以为 add_buf 是随机数据但熵根本不够，因此后面直接把输入数据忽略了，全部随机生成。

将其保存为 random_qrcode.py 并使用下面的命令去启动:

env AFL_CUSTOM_MUTATOR_ONLY=1 PYTHONPATH=$PWD/mutators AFL_PYTHON_MODULE=random_qrcode afl-fuzz -i corpus/ -o output -t +9000 -- ./opencv_test_wechat_qrcode_persist2

这里我指定了 AFL_CUSTOM_MUTATOR_ONLY=1，不需要 AFL 自身的变异，因为 AFL 的变异是基于原始语料的，而我并不希望在原始的图片二进制层级进行变异，否则就又回到了最初的场景。现在我们每次生成一张随机的二维码图片，且肯定是合法的 PNG 格式，避免遭遇图片解码时的异常。初始语料我也设置为表示坐标的点而不是图片。

当然，这个 fuzzer 跑起来巨慢！这是因为我们每次生成时都需要先生成一张二维码，变异，然后编码成 PNG 图片，再再将图片输入给目标进行解析。

解决方案可以通过 C++ 直接去生成二维码，然后将二维码直接转成 cv::Mat 去作为输入。这样一方面可以节省掉 PNG 编解码的过程，另一方面也可以摆脱 Python 的依赖。QR-Code-generator 也许是一个不错的方案。不过考虑到之前画蛇添足的失败尝试，能带来多少速度的提升也不甚确定。

另外当前覆盖率反馈的变异其实是有限的(如果有的话)，从文档中来看，LibFuzzer 对于自定义变异的支持可能会更完善一些。而且 LibFuzzer 可以天然支持多核，不用像 AFL 要自己手打一堆 slave。

Anyway，最终运行结果:

$ afl-whatsup -s output/
/usr/local/bin/afl-whatsup status check tool for afl-fuzz by Michal Zalewski

Summary stats
=============

       Fuzzers alive : 17
      Total run time : 32 days, 13 hours
         Total execs : 8 millions, 198 thousands
    Cumulative speed : 36 execs/sec
       Average speed : 2 execs/sec
       Pending items : 567 faves, 22476 total
  Pending per fuzzer : 33 faves, 1322 total (on average)
       Crashes saved : 0
         Hangs saved : 0
Cycles without finds : 0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0
  Time without finds : 35 seconds

meme

好吧，虽然 OpenCV “非常安全”，但是二维码解析库又不止这一个！于是又找了另外一个常用的解析库 ZXing 去进行测试，事实证明还是可以找出问题的！

总结

本文可以看做是一个典型的 Fuzzing 漏洞挖掘心路历程。即先用 Generic Fuzzer 跑起来，然后通过不断深入理解代码，改良变异策略，最终变成 Structure Aware Fuzzing 的结果！虽然 AFL 一把梭能让机器为自己打工很爽，但是想得到更好的结果还是免不了动手优化。而不看代码的话可能即便找到问题也无法理解成因，轻则无法编写利用导致 award-0，重则提交错误的 patch 导致后续被其他开发者 revert 并批判一番钉在历史的耻辱柱上。因此，自动化测试和代码审计相结合往往才能达到更加有效的漏洞挖掘效果。

参考链接

版权声明: 自由转载-非商用-非衍生-保持署名 (CC 4.0 BY-SA)
原文地址: https://evilpan.com/2023/06/10/fuzzing-qrcode/
微信订阅: 『有价值炮灰』
– TO BE CONTINUED.

]]> 漫谈漏洞挖掘 https://evilpan.com/2021/05/22/bug-hunting/ Sat, 22 May 2021 12:40:00 +0800 evilpan https://evilpan.com/2021/05/22/bug-hunting/ 聊聊漏洞分析、漏洞利用和漏洞挖掘。

前言

说到安全就不能不说漏洞，而说到漏洞就不可避免地会说到三座大山：

  • 漏洞分析
  • 漏洞利用
  • 漏洞挖掘

从笔者个人的感觉上来看，这三者尽管通常水乳交融、相互依赖，但难度是不尽相同的。本文就这三者分别谈谈自己的经验和想法。

漏洞分析

漏洞分析相对简单，通常公开的漏洞中就有一两句话描述了漏洞的成因，自己拉代码下来看也就能了解个大概。对于一些自己发现的bug，从崩溃日志中一般也能比较轻松地进行复现和调试。尽管有的bug排查起来相对繁琐，但总归是可以一步步减少范围锁定最终目标的。因此，网上对于漏洞分析的文章很多，一方面分析起来有迹可循，另一方面分析的漏洞也不一定是自己的“原创”漏洞，素材来源更加广泛。

漏洞分析虽然简单，却是每个安全研究人员的必经之路。就像练武中的扎马步、站梅花桩一样，是日积月累的基本功。之前研究内核时有段时间热衷于写漏洞分析的文章，后来随着日渐熟练，写文章记录的速度已经远远跟不上分析的进度，所以现在往往懒得动笔了。

基本功必不可少，但扎马步扎得再稳也不表示你能独步武林。有大佬曾经说过，如果他想的话，可以一天写好几篇分析文章还不带重样的。毕竟，漏洞分析的目的是为了学习、吸收、转化，以史为鉴，最终形成自己独到的理解。

漏洞利用

漏洞利用就相对复杂一点，尤其是对于二进制漏洞，成功的利用需要精巧的内存布局，因此需要对程序涉及到的数据结构要相当的了解。而且并不是所有漏洞都能转换为有效利用的，一般比较容易编写利用的漏洞，我们称之为品相好。对于品相不好的漏洞，我更喜欢将其称之为bug。当然也有人认为 bug 至少造成了程序崩溃，所以可以算一个DoS(拒绝服务)漏洞。

当然漏洞能否利用其实也是和人有关。对于复杂的系统，你认为无法利用的漏洞，大佬就能以一种你没想到的方式利用成功。比如安卓CVE-2019-2025(水滴)漏洞，属于Binder中的一个条件竞争，竞争窗口只有几条汇编指令。漏洞品相相当不好，连CVSS给出的可利用分数(Exploitability Score)也只有1.8分，但360的大佬们也通过玩弄调度器进行稳定利用提权了。

因此，关于漏洞利用的文章也就少了很多。一方面处于负责任披露安全问题的考虑，安全研究人员不会给出完整的利用细节，以免脚本小子滥用；另一方面对于公开的利用，你也总不能跟着写一篇文章灌水，毕竟利用思路很多时候是因人而异的，过于雷同就难免有炒冷饭的嫌疑，除非有一些独到的思考补充，或者有新的利用思路。

很多时候漏洞利用的文章看着看着就变成了漏洞利用分析的文章，这也说明了漏洞利用难度颇高，能独立写出原创利用并进行分享的人不多。就我的感觉而言，漏洞利用更像是另一种形式的软件开发，首先通过漏洞构造原语，然后通过原语实现最终的利用程序。

漏洞挖掘

漏洞挖掘可以说是安全研究人员向往的高地之一，不管你分析了多少漏洞，写了多少利用，如果你没有自己挖掘出过原创的漏洞，那你的安全研究生涯就是不完整的。但是漏洞挖掘这事儿并不是确定性的。漏洞分析只要有漏洞肯定能分析清楚，只不过是时间问题；漏洞利用只要不是明显的无法利用，那至少也存在利用成功的可能性。

漏洞挖掘则不然，即便你盯着某个应用使劲挖，也不能保证有结果，说不定对方根本就没有能触发的漏洞。都说世上没有绝对安全的系统，但是相对安全的系统一抓一大把，至少在出问题之前，你是不知道的。

我们能看到各种安全会议中介绍各种新发现的漏洞和问题，网上也有很多相关的文章，但更多是炫技式分享(show-off)，很少有分享怎么挖洞的。因此笔者就先抛砖引玉，谈谈自己的想法。

自从 AFL 横空出世之后，当今漏洞挖掘言必称 Fuzzing，仿佛这是李云龙他娘的意大利炮，不管三七二十一先来上一发就能轰出几个 0day。当然，我不是说 Fuzz 不好，只不过凡事都有其诞生和得以应用的环境。

Fuzzing 即模糊测试，在早期是 QA 测试中的一项黑盒测试技术，通过随机变异的输入来测试程序的鲁棒性。在程序的崩溃被用于漏洞利用后，也就一跃成为一种漏洞挖掘方法。随机变异输入的效率相对低下，可能变异了半天连 main 函数里第一个 if 都没有跳进去。AFL 率先提出并实现了根据路径/覆盖率等反馈来进行输入的变异，从而大大提升了测试用例的有效性。

AFL

自从 2013 年 AFL 提出以来，各类 Fuzzer 百花齐放，在学术上有了爆发性的论文增长；开源社区有 honggfuzz、libFuzzer 等优秀的项目；在工程上有 OSS-Fuzz 利用庞大机器集群进行持续测试的应用和 syzkaller 这种年均发现几千内核漏洞的工具等。

从产出的漏洞数量来看，Fuzzing 作为一种漏洞挖掘方法可谓一骑绝尘。当时，随着时间的推移，通用模糊测试策略已经越来越难发现新的漏洞，要么你有独特的测试语料，要么你有领先的运算资源。因此，一部分人就从通用 Fuzzer 转回到了针对特定目标变异的 Fuzzer(即 Structure Aware Fuzzer)。也就是说，只针对目标程序接受的数据类型进行特定变异，比如针对 PDF 文件格式每个字段变异等等。

别忘了，AFL 这种通用 Fuzzer 的出现，就是为了实现一次编码，到处 Fuzz 的目的；而针对不同目标去写 Fuzzer，显然有违初衷。另外，如果目标接受的是已知格式的输入还好，对于未知格式，还需要自己去分析和理解各个字段含义。在阅读代码和理解代码逻辑的过程中，目标程序的潜在问题很可能已经出现在你眼前了，再去编写一个不能复用的 Fuzzer，显得有些多此一举。这种发现漏洞的方法也就是下节所说的——代码审计。

代码审计，俗称看代码。有的人用 SourceInsight 看，有的人用 VIM 看，但不管怎么样还是用眼睛看。既然大家都长了两只眼睛，为什么有的人就能一个月看出十几个高危，有的人就只看了个寂寞？

看代码也是有方法的。虽然我比较想听听 @oldfresher 是怎么看代码的，但他似乎不太愿意分享，所以我只能说说自己的方法。

要挖漏洞首先要对漏洞进行分类，大致可以分为下面三种:

  • 设计漏洞
  • 实现漏洞
  • 操作漏洞

所谓设计漏洞就是软件设计过程中就存在逻辑问题，比如 WiFi 的 WEP，设计的问题往往是比较严重的，而且修复周期长，所幸这类问题不是太多；实现漏洞就是我们常见的软件漏洞，内存溢出、UAF、条件竞争等都算在里面；操作漏洞和实现漏洞往往类似，只不过更多是指配置错误而产生的漏洞，比如 nginx 配置错误导致的目录穿越问题就属于一种操作漏洞。

明确漏洞类型后也不是马上开始看代码，而是先进行初步的攻击面分析，也就是常说的威胁建模。主要分为下面几步:

  • 信息收集: 收集所有相关的资料，尤其是设计文档或者帮助手册等
  • 应用架构建模: 列举应用所含的组件以及状态机，注意各个组件之间隐含的信任关系
  • 威胁鉴定: 在各个流程中列举潜在的攻击点，并分别标记危害等级
  • 审计计划: 按优先级对实现的审计计划进行排序

代码审计听起来是个让人退缩任务，因为你面对的是一堆你不熟悉的代码，而且要求你快速地建立起自己的理解而且找到其中最深层的秘密(安全漏洞)。通常你不会有足够的时间审计项目的每一行代码，因此这其中的一个重点就是懂得如何分配精力，在最可能出现安全问题的代码中达到满意的审计覆盖率。

成功的代码审计过程一定是务实、灵活且面向结果的。虽然讲究方法，但并不意味着根据别人的方法就能成功。与很多人的认知不同，代码审计其实是一件需要创造力的技能。那位说了，看别人代码要什么创造力？要在应用中找到漏洞，审计者需要将自己代入作者的思维中理解代码，同时还需要跳出作者的思维，洞察到原作者没有预料到的可能性；这种技能与知识相对，像是骑车、游泳、弹琴一样，是需要通过学习和练习去掌握的，而一旦掌握就像本能的一部分难以忘记。当然代码审计也有知识的部分，比如需要了解各种漏洞类型和场景等。

这些都这只是代码审计中的冰山一角，篇幅原因无法面面俱到。比如代码审计策略的抉择，是深度优先还是广度优先(看到某个函数调用是否需要追进去看)；以及使用现代的静态分析工具来辅助审计，比如 Fority、CodeQL 等，后续有时间再单独进行介绍吧。

后记

漏洞分析是技术，漏洞利用是艺术，漏洞挖掘是法术。关于漏洞利用和漏洞挖掘哪个“技术含量”更高，还存在一定争议，但漏洞分析的基础地位毫无疑问。技术可以学，艺术可以练，法术呢？其实同样也可以通过练习提高自己的 漏洞挖掘水平。推荐一个忘了是什么地方的议题中提供的方法(也许是 CCC):

  1. 找到公开的漏洞通告，根据标题的内容自己去相关模块中审计看是否能发现该漏洞
  2. 如果发现不了，就回头接着看漏洞通告的细节，反思自己的审计方法
  3. 不断重复，直到让自己可以认为找漏洞只是时间问题而不是能力问题

任何行业都没有捷径，你看到的所谓魔法，很可能只是某人在某些事情上付出了你意想不到的时间。最后借用一句谚语作为结尾吧:

Ever tried. Ever failed. No matter.

Try again. Fail again. Fail better.

共勉。

]]> 深入浅出ELF https://evilpan.com/2020/08/09/elf-inside-out/ Sun, 09 Aug 2020 22:40:00 +0800 evilpan https://evilpan.com/2020/08/09/elf-inside-out/

本文介绍了ELF的基本结构和内存加载的原理，并用具体案例来分析如何通过ELF特性实现HIDS bypass、加固/脱壳以及辅助进行binary fuzzing。

前言

作为一个安全研究人员，ELF可以说是一个必须了解的格式，因为这关系到程序的编译、链接、封装、加载、动态执行等方方面面。有人就说了，这不就是一种文件格式而已嘛，最多按照SPEC实现一遍也就会了，难道还能复杂过FLV/MP4？曾经我也是这么认为的，直到我在日常工作时遇到了下面的错误:

$ r2 a.out
Segmentation fault

作为一个开源爱好者，我的radare2经常是用master分支编译的，经过在github中搜索，发现radare对于ELF的处理还有不少同类的问题，比如issue#17300以及issue#17379，这还只是近一个月内的两个open issue，历史问题更是数不胜数。

总不能说radare的开发者不了解ELF吧？事实上他们都是软件开发和逆向工程界的专家。不止radare，其实IDA和其他反编译工具也曾出现过各类ELF相关的bug。

说了那么多，只是为了引出一个观点: ELF既简单也复杂，值得我们去深入了解。网上已经有了很多介绍ELF的文章，因此本文不会花太多篇幅在SPEC的复制粘贴上，而是结合实际案例和应用场景去进行说明。

ELF 101

ELF的全称是Executable and Linking Format，这个名字相当关键，包含了ELF所需要支持的两个功能——执行和链接。不管是ELF，还是Windows的PE，抑或是MacOS的Mach-O，其根本目的都是为了能让处理器正确执行我们所编写的代码。

在上古时期，给CPU运行代码也不用那么复杂，什么代码段数据段，直接把编译好的机器码一把梭烧到中断内存空间，PC直接跳过来就执行了。但随着时代变化，大家总不能一直写汇编了，即便编译器很给力，也会涉及到多人协作、资源复用等问题。这时候就需要一种可拓展(Portable)的文件标准，一方面让开发者(编译器/链接器)能够高效协作，另一方面也需要系统能够正确、安全地将文件加载到对应内存中去执行，这就是ELF的使命。

view.png
view

从大局上看，ELF文件主要分为3个部分:

  • ELF Header
  • Section Header Table
  • Program Header Table

其中，ELF Header是文件头，包含了固定长度的文件信息；Section Header Table则包含了链接时所需要用到的信息；Program Header Table中包含了运行时加载程序所需要的信息，后面会进行分别介绍。

ELF头部的定义在elf/elf.h中(以glibc-2.27为例)，使用POD结构体表示，内存可使用结构体的字段一一映射，头部表示如下:

#define EI_NIDENT (16)

typedef struct
{
  unsigned char	e_ident[EI_NIDENT];	/* Magic number and other info */
  Elf32_Half	e_type;			/* Object file type */
  Elf32_Half	e_machine;		/* Architecture */
  Elf32_Word	e_version;		/* Object file version */
  Elf32_Addr	e_entry;		/* Entry point virtual address */
  Elf32_Off	e_phoff;		/* Program header table file offset */
  Elf32_Off	e_shoff;		/* Section header table file offset */
  Elf32_Word	e_flags;		/* Processor-specific flags */
  Elf32_Half	e_ehsize;		/* ELF header size in bytes */
  Elf32_Half	e_phentsize;		/* Program header table entry size */
  Elf32_Half	e_phnum;		/* Program header table entry count */
  Elf32_Half	e_shentsize;		/* Section header table entry size */
  Elf32_Half	e_shnum;		/* Section header table entry count */
  Elf32_Half	e_shstrndx;		/* Section header string table index */
} Elf32_Ehdr;

注释都很清楚了，挑一些比较重要的来说。其中e_type表示ELF文件的类型，有以下几种:

  • ET_NONE: 未知类型
  • ET_REL: 可重定向类型(relocatable)，通常是我们编译的*.o文件
  • ET_EXEC: 可执行类型(executable)，静态编译的可执行文件
  • ET_DYN: 共享对象(shared object)，动态编译的可执行文件或者动态库*.so
  • ET_CORE: coredump文件

e_entry是程序的入口虚拟地址，注意不是main函数的地址，而是.text段的首地址_start。当然这也要求程序本身非PIE(-no-pie)编译的且ASLR关闭的情况下，对于非ET_EXEC类型通常并不是实际的虚拟地址值。

其他的字段大多数是指定Section Header(e_sh)和Program Header(e_ph)的信息。Section/Program Header Table本身可以看做是数组结构，ELF头中的信息指定对应Table数组的位置、长度、元素大小信息。最后一个e_shstrndx表示的是section table中的第e_shstrndx项元素，保存了所有section table名称的字符串信息。

上节说了section header table是一个数组结构，这个数组的位置在e_shoff处，共有e_shnum个元素(即section)，每个元素的大小为e_shentsize字节。每个元素的结构如下:

typedef struct
{
  Elf32_Word	sh_name;		/* Section name (string tbl index) */
  Elf32_Word	sh_type;		/* Section type */
  Elf32_Word	sh_flags;		/* Section flags */
  Elf32_Addr	sh_addr;		/* Section virtual addr at execution */
  Elf32_Off	sh_offset;		/* Section file offset */
  Elf32_Word	sh_size;		/* Section size in bytes */
  Elf32_Word	sh_link;		/* Link to another section */
  Elf32_Word	sh_info;		/* Additional section information */
  Elf32_Word	sh_addralign;		/* Section alignment */
  Elf32_Word	sh_entsize;		/* Entry size if section holds table */
} Elf32_Shdr;

其中sh_name是该section的名称，用一个word表示其在字符表中的偏移，字符串表(.shstrtab)就是上面说到的第e_shstrndx个元素。ELF文件中经常使用这种偏移表示方式，可以方便组织不同区段之间的引用。

sh_type表示本section的类型，SPEC中定义了几十个类型，列举其中一些如下:

  • SHT_NULL: 表示该section无效，通常第0个section为该类型
  • SHT_PROGBITS: 表示该section包含由程序决定的内容，如.text、.data、.plt、.got
  • SHT_SYMTAB/SHT_DYNSYM: 表示该section中包含符号表，如.symtab、.dynsym
  • SHT_DYNAMIC: 表示该section中包含动态链接阶段所需要的信息
  • SHT_STRTAB: 表示该section中包含字符串信息，如.strtab、.shstrtab
  • SHT_REL/SHT_RELA: 包含重定向项信息
  • …

虽然每个section header的大小一样(e_shentsize字节)，但不同类型的section有不同的内容，内容部分由这几个字段表示:

  • sh_offset: 内容起始地址相对于文件开头的偏移
  • sh_size: 内容的大小
  • sh_entsize: 有的内容是也是一个数组，这个字段就表示数组的元素大小

与运行时信息相关的字段为:

  • sh_addr: 如果该section需要在运行时加载到虚拟内存中，该字段就是对应section内容(第一个字节)的虚拟地址
  • sh_addralign: 内容地址的对齐，如果有的话需要满足sh_addr % sh_addralign = 0
  • sh_flags: 表示所映射内容的权限，可根据SHF_WRITE/ALLOC/EXECINSTR进行组合

另外两个字段sh_link和sh_info的含义根据section类型的不同而不同，如下表所示:

type.png
type

至于不同类型的section，有的是保存符号表，有的是保存字符串，这也是ELF表现出拓展性和复杂性的地方，因此需要在遇到具体问题的时候查看文档去进行具体分析。

program header table用来保存程序加载到内存中所需要的信息，使用段(segment)来表示。与section header table类似，同样是数组结构。数组的位置在偏移e_phoff处，每个元素(segment header)的大小为e_phentsize，共有e_phnum个元素。单个segment header的结构如下:

typedef struct
{
  Elf32_Word	p_type;			/* Segment type */
  Elf32_Off	p_offset;		  /* Segment file offset */
  Elf32_Addr	p_vaddr;		/* Segment virtual address */
  Elf32_Addr	p_paddr;		/* Segment physical address */
  Elf32_Word	p_filesz;		/* Segment size in file */
  Elf32_Word	p_memsz;		/* Segment size in memory */
  Elf32_Word	p_flags;		/* Segment flags */
  Elf32_Word	p_align;		/* Segment alignment */
} Elf32_Phdr;

既然program header的作用是提供用于初始化程序进程的段信息，那么下面这些字段就是很直观的:

  • p_offset: 该segment的数据在文件中的偏移地址(相对文件头)
  • p_vaddr: segment数据应该加载到进程的虚拟地址
  • p_paddr: segment数据应该加载到进程的物理地址(如果对应系统使用的是物理地址)
  • p_filesz: 该segment数据在文件中的大小
  • p_memsz: 该segment数据在进程内存中的大小。注意需要满足p_memsz>=p_filesz，多出的部分初始化为0，通常作为.bss段内容
  • p_flags: 进程中该segment的权限(R/W/X)
  • p_align: 该segment数据的对齐，2的整数次幂。即要求p_offset % p_align = p_vaddr。

剩下的p_type字段，表示该program segment的类型，主要有以下几种:

  • PT_NULL: 表示该段未使用
  • PT_LOAD: Loadable Segment，将文件中的segment内容映射到进程内存中对应的地址上。值得一提的是SPEC中说在program header中的多个PT_LOAD地址是按照虚拟地址递增排序的。
  • PT_DYNAMIC: 动态链接中用到的段，通常是RW映射，因为需要由interpreter(ld.so)修复对应的的入口
  • PT_INTERP: 包含interpreter的路径，见下文
  • PT_HDR: 表示program header table本身。如果有这个segment的话，必须要在所有可加载的segment之前，并且在文件中不能出现超过一次。
  • …

在不同的操作系统中还可能有一些拓展的类型，比如PT_GNU_STACK、PT_GNU_RELRO等，不一而足。

至此，ELF文件中相关的字段已经介绍完毕，主要组成也就是Section Header Table和Program Header Table两部分，整体框架相当简洁。而ELF中体现拓展性的地方则是在Section和Segment的类型上(s_type和p_type)，这两个字段的类型都是ElfN_Word，在32位系统下大小为4字节，也就是说最多可以支持高达2^32 - 1种不同的类型！除了上面介绍的常见类型，不同操作系统或者厂商还能定义自己的类型去实现更多复杂的功能。

程序加载

在新版的ELF标准文档中，将ELF的介绍分成了三部分，第一部分介绍ELF文件本身的结构，第二部分是处理器相关的内容，第三部分是操作系统相关的内容。ELF的加载实际上是与操作系统相关的，不过大部分情况下我们都是在GNU/Linux环境中运行，因此就以此为例介绍程序的加载流程。

Linux中分为用户态和内核态，执行ELF文件在用户态的表现就是执行execve系统调用，随后陷入内核进行处理。

内核空间对execve的处理其实可以单独用一篇文章去介绍，其中涉及到进程的创建、文件资源的处理以及进程权限的设置等等。我们这里主要关注其中ELF处理相关的部分即可，实际上内核可以识别多种类型的可执行文件，ELF的处理代码主要在fs/binfmt_elf.c中的load_elf_binary函数中。

对于ELF而言，Linux内核所关心的只有Program Header部分，甚至大部分情况下只关心三种类型的Header，即PT_LOAD、PT_INTERP和PT_GNU_STACK。以3.18内核为例，load_elf_binary主要有下面操作:

  1. 对ELF文件做一些基本检查，保证e_phentsize = sizeof(struct elf_phdr)并且e_phnum的个数在一定范围内；
  2. 循环查看每一项program header，如果有PT_INTERP则使用open_exec加载进来，并替换原程序的bprm->buf;
  3. 根据PT_GNU_STACK段中的flag设置栈是否可执行；
  4. 使用flush_old_exec来更新当前可执行文件的所有引用；
  5. 使用setup_new_exec设置新的可执行文件在内核中的状态；
  6. setup_arg_pages在栈上设置程序调用参数的内存页；
  7. 循环每一项PT_LOAD类型的段，elf_map映射到对应内存页中，初始化BSS；
  8. 如果存在interpreter，将入口(elf_entry)设置为interpreter的函数入口，否则设置为原ELF的入口地址；
  9. install_exec_creds(bprm)设置进程权限等信息；
  10. create_elf_tables添加需要的信息到程序的栈中，比如ELF auxiliary vector；
  11. 设置current->mm对应的字段；

从内核的处理流程上来看，如果是静态链接的程序，实际上内核返回用户空间执行的就是该程序的入口地址代码；如果是动态链接的程序，内核返回用户空间执行的则是interpreter的代码，并由其加载实际的ELF程序去执行。

为什么要这么做呢？如果把动态链接相关的代码也放到内核中，就会导致内核执行功能过多，内核的理念一直是能不在内核中执行的就不在内核中处理，以避免出现问题时难以更新而且影响系统整体的稳定性。事实上内核中对ELF文件结构的支持是相当有限的，只能读取并理解部分的字段。

内核返回用户空间后，对于静态链接的程序是直接执行，没什么好说的。而对于动态链接的程序，实际是执行interpreter的代码。ELF的interpreter作为一个段，自然是编译链接的时候加进去的，因此和编译使用的工具链有关。对于Linux系统而言，使用的一般是GCC工具链，而interpreter的实现，代码就在glibc的elf/rtld.c中。

interpreter又称为dynamic linker，以glibc2.27为例，它的大致功能如下:

  • 将实际要执行的ELF程序中的内存段加载到当前进程空间中；
  • 将动态库的内存段加载到当前进程空间中；
  • 对ELF程序和动态库进行重定向操作(relocation)；
  • 调用动态库的初始化函数(如*.preinit_array, .init, .init_array*)；
  • 将控制流传递给目标ELF程序，让其看起来自己是直接启动的；

其中参与动态加载和重定向所需要的重要部分就是Program Header Table中PT_DYNAMIC类型的Segment。前面我们提到在Section Header中也有一部分参与动态链接的section，即.dynamic。我在自己解析动态链接文件的时候发现，实际上 .dynamic section中的数据，和PT_DYNAMIC中的数据指向的是文件中的同一个地方，即这两个entry的s_offset和p_offset是相同。每个元素的类型如下:

typedef struct
{
  Elf32_Sword	d_tag;			/* Dynamic entry type */
  union
    {
      Elf32_Word d_val;			/* Integer value */
      Elf32_Addr d_ptr;			/* Address value */
    } d_un;
} Elf32_Dyn;

d_tag表示实际类型，并且d_un和d_tag相关，可以说是很有拓展性了:) 同样的，标准中定义了几十个d_tag类型，比较常用的几个如下:

  • DT_NULL: 表示_DYNAMIC的结尾
  • DT_NEEDED: d_val保存了一个到字符串表头的偏移，指定的字符串表示该ELF所依赖的动态库名称
  • DT_STRTAB: d_ptr指定了地址保存了符号、动态库名称以及其他用到的字符串
  • DT_STRSZ: 字符串表的大小
  • DT_SYMTAB: 指定地址保存了符号表
  • DT_INIT/DT_FINI: 指定初始化函数和结束函数的地址
  • DT_RPATH: 指定动态库搜索目录
  • DT_SONAME: Shared Object Name，指定当前动态库的名字(logical name)
  • …

其中有部分的类型可以和Section中的SHT_xxx类型进行类比，完整的列表可以参考ELF标准中的Book III: Operating System Specific一节。

在interpreter根据DT_NEEDED加载完所有需要的动态库后，就实现了完整进程虚拟内存映像的布局。在寻找某个动态符号时，interpreter会使用广度优先的方式去进行搜索，即先在当前ELF符号表中找，然后再从当前ELF的DT_NEEDED动态库中找，再然后从动态库中的DT_NEEDED里查找。

因为动态库本身是位置无关的(PIE)，支持被加载到内存中的随机位置，因此为了程序中用到的符号可以被正确引用，需要对其进行重定向操作，指向对应符号的真实地址。这部分我在之前写的关于GOT,PLT和动态链接的文章中已经详细介绍过了，因此不再赘述，感兴趣的朋友可以参考该文章。

实际案例

有人也许会问，我看你bibi了这么多，有什么实际意义吗？呵呵，本节就来分享几个我认为比较有用的应用场景。

在渗透测试中，红队小伙伴们经常能拿到目标的后台shell权限，但是遇到一些部署了HIDS的大企业，很可能在执行恶意程序的时候被拦截，或者甚至触发监测异常直接被蓝队拔网线。这里不考虑具体的HIDS产品，假设现在面对两种场景:

  1. 目标环境的可写磁盘直接mount为noexec，无法执行代码
  2. 目标环境内核监控任何非系统路径的程序的执行都会直接告警

不管什么样的环境，我相信老红队都有办法去绕过，这里我们运用上面学到的ELF知识，其实有一种更为简单的解法，即利用interpreter。示例如下:

$ cat hello.c
#include <stdio.h>
int main() {
	return puts("hello!");
}
$ gcc hello.c -o hello
$ ./hello
hello!

$ chmod -x hello
$ ./hello
bash: ./hello: Permission denied
$ /lib64/ld-linux-x86-64.so.2 ./hello
hello!
$ strace /lib64/ld-linux-x86-64.so.2 ./hello 2>&1 | grep exec
execve("/lib64/ld-linux-x86-64.so.2", ["/lib64/ld-linux-x86-64.so.2", "./hello"], 0x7fff1206f208 /* 9 vars */) = 0

/lib64/ld-linux-x86-64.so.2本身应该是内核调用执行的，但我们这里可以直接进行调用。这样一方面可以在没有执行权限的情况下执行任意代码，另一方面也可以在一定程度上避免内核对execve的异常监控。

利用(滥用)interpreter我们还可以做其他有趣的事情，比如通过修改指定ELF文件的interpreter为我们自己的可执行文件，可让内核在处理目标ELF时将控制器交给我们的interpreter，这可以通过直接修改字符串表或者使用一些工具如patchelf来轻松实现。

对于恶意软件分析的场景，很多安全研究人员看到ELF就喜欢用ldd去看看有什么依赖库，一般ldd脚本实际上是调用系统默认的ld.so并通过环境变量来打印信息，不过对于某些glibc实现(如glibc2.27之前的ld.so)，会调用ELF指定的interpreter运行，从而存在非预期命令执行的风险。

当然还有更多其他的思路可以进行拓展，这就需要大家发挥脑洞了。

与逆向分析比较相关的就是符号表，一个有符号的程序在逆向时基本上和读源码差不多。因此对于想保护应用程序的开发者而言，最简单的防护方法就是去除符号表，一个简单的strip命令就可实现。strip删除的主要是Section中的信息，因为这不影响程序的执行。去除前后进行diff对比可看到删除的section主要有下面这些:

$ diff 0 1
1c1
< There are 35 section headers, starting at offset 0x1fdc:
---
> There are 28 section headers, starting at offset 0x1144:
32,39c32
<   [27] .debug_aranges    PROGBITS        00000000 00104d 000020 00      0   0  1
<   [28] .debug_info       PROGBITS        00000000 00106d 000350 00      0   0  1
<   [29] .debug_abbrev     PROGBITS        00000000 0013bd 000100 00      0   0  1
<   [30] .debug_line       PROGBITS        00000000 0014bd 0000cd 00      0   0  1
<   [31] .debug_str        PROGBITS        00000000 00158a 000293 01  MS  0   0  1
<   [32] .symtab           SYMTAB          00000000 001820 000480 10     33  49  4
<   [33] .strtab           STRTAB          00000000 001ca0 0001f4 00      0   0  1
<   [34] .shstrtab         STRTAB          00000000 001e94 000145 00      0   0  1
---
>   [27] .shstrtab         STRTAB          00000000 00104d 0000f5 00      0   0  1

其中**.symtab是符号表，.strtab**是符号表中用到的字符串。

仅仅去掉符号感觉还不够，熟悉汇编的人放到反编译工具中还是可以慢慢还原程序逻辑。通过前面的分析我们知道，ELF执行需要的只是Program Header中的几个段，Section Header实际上是不需要的，只不过在运行时动态链接过程会引用到部分关联的区域。大部分反编译工具，如IDA、Ghidra等，处理ELF是需要某些section信息来构建程序视图的，所以我们可以通过构造一个损坏Section Table或者ELF Header令这些反编译工具出错，从而干扰逆向人员。

当然，这个方法并不总是奏效，逆向人员可以通过动态调试把程序dump出来并对运行视图进行还原。一个典型的例子是Android中的JNI动态库，有的安全人员对这些so文件进行了加密处理，并且在.init/.initarray这些动态库初始化函数中进行动态解密。破解这种加固方法的策略就是将其从内存中复制出来并进行重建，重建的过程可根据segment对section进行还原，因为segment和section之间共享了许多内存空间，例如:

$ readelf -l main1
...
 Section to Segment mapping:
  Segment Sections...
   00
   01     .interp
   02     .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rel.dyn .rel.plt .init .plt .plt.got .text .fini .rodata .eh_frame_hdr .eh_frame
   03     .init_array .fini_array .dynamic .got .got.plt .data .bss
   04     .dynamic
   05     .note.ABI-tag .note.gnu.build-id
   06     .eh_frame_hdr
   07
   08     .init_array .fini_array .dynamic .got

在Section to Segment mapping中可以看到这些段的内容是跟对应section的内容重叠的，一个segment可以包含多个section，但是依然可以根据内存的读写属性、内存特征以及对应段的一般顺序进行区分。

如果程序中有比较详细的日志函数，我们还可以通过反编译工具的脚本拓展去修改.symtab/.strtab段来批量还原ELF文件的符号，从而高效地辅助动态调试。

考虑这么一种场景，我们在分析某个IoT设备时发现了一个定制的ELF网络程序，类似于httpd，其中有个静态函数负责处理输入数据。现在想要单独对这个函数进行fuzz应该怎么做？直接从网络请求中进行变异是一种方法，但是网络请求的效率太低，而且触达该函数的程序逻辑也可能太长。

既然我们已经了解了ELF，那就可以有更好的办法将该函数抽取出来进行独立调用。在介绍ELF类型的时候其实有提到，可执行文件可以有两种类型，即可执行类型(ET_EXEC)和共享对象(ET_DYN)，一个动态链接的可执行程序默认是共享对象类型的:

$ gcc hello.c -o hello
$ readelf -h hello | grep Type
  Type:  DYN (Shared object file)

而动态库(.so)本身也是共享对象类型，他们之间的本质区别在于前者链接了libc并且定义了main函数。对于动态库，我们可以通过dlopen/dlsym获取对应的符号进行调用，因此对于上面的场景，一个解决方式就是修改目标ELF文件，并且将对应的静态函数导出添加到dynamic section中，并修复对应的ELF头。

这个思想其实很早就已经有人实现了，比如lief的bin2lib。通过该方法，我们就能将目标程序任意的函数抽取出来执行，比如hugsy就用这个方式复现了Exim中的溢出漏洞(CVE-2018-6789)，详见Fuzzing arbitrary functions in ELF binaries(中文翻译)。

总结

本文主要介绍了32位环境下ELF文件的格式和布局，然后从内核空间和用户空间两个方向分析了ELF程序的加载过程，最后列举了几个依赖于ELF文件特性的案例进行具体分析，包括dynamic linker的滥用、程序加固和反加固以及在二进制fuzzing中的应用。

ELF文件本身并不复杂，只有三个关键部分，只不过在section和segment的类型上保留了极大的拓展性。操作系统可以根据自己的需求在不同字段上实现和拓展自己的功能，比如Linux中通过dymamic类型实现动态加载。但这不是必须的，例如在Android中就通过ELF格式封装了特有的.odex 、 .oat文件来保存优化后的dex。另外对于64位环境，大部分字段含义都是类似的，只是字段大小稍有变化(Elf32->Elf64)，并不影响文中的结论。

参考链接

]]>