写在前面

看代码和写代码有很大的一点不同，后者通常对于准确的代码补全是刚需，而看代码往往只需要跳转定义、交叉引用等一些基本功能。对于大部分人而言，看代码和写代码的一个相同之处就是使用 IDE 来看。

具体代码审计的习惯往往是因人而异的。有的人喜欢用 JetBrains 看，有的人喜欢用 VSCode 看，有的人喜欢用 SourceInsight 看，还有的人喜欢用 Notepad++ 来看。

此外，有一些通过本地构建代码索引并从浏览器阅读代码的方案，比如：

• https://github.com/oracle/opengrok
• https://github.com/livegrep/livegrep

而对于一些大型的代码工程，通常官方或者社区也构建了一些在线的代码阅读网站，比如：

• https://cs.android.com/ - Google Android 源码
• https://source.chromium.org/chromium - Google Chrome 源码
• http://aospxref.com/ - Android 源码，基于 opengrok
• https://elixir.bootlin.com/linux/latest/source - Linux 源码

各种阅读代码的方法都有它们的优点，笔者大部分也都尝试过，但大部分时间还是喜欢用 VIM 来看。即便切换到其他 IDE，也习惯性先装个 VIM Binding 插件，总感觉不用 HJKL 移动就难受。

虽然笔者是 VIM 爱好者，但并不排斥其他的 IDE。对于一些依赖完整的项目，比如 Java Maven 工程，也会优先使用 IDEA 去进行阅读，充分利用现代 IDE 的语言支持。

示例

VIM 的好处在于其本身只是一个文本编辑器，而不是完整的 IDE。很多时候我们审计的代码只是一些零散的 Broken Code，比如泄露的 iBoot 源码、某些 Jar 包反编译出来的代码等，面对这些代码很多 IDE 都无法做到完整的语言支持，进而也退化成了一个只能依赖 Ctrl+F 的文本编辑器，既然如此还不如选择自己喜欢的。

如图是最近刚放出来的 MS-DOS 4.0 的源代码，虽然都是汇编，但使用 VIM 依然可以识别出大部分的符号，并且很方便搜索跳转：

后文会简单介绍一下实现的细节。

设计思路

作为一个笔者自用的代码审计小工具，一开始就有比较简单的设计目标：

1. 主要在 macOS 和 Linux 桌面环境和命令行环境使用，支持在服务器中使用；
2. 支持大部分 VIM 衍生应用，比如 NEOVIM、VIM-GTK、MacVIM 等，支持自定义快捷键；
3. 支持对大部分编程语言构建索引方便跳转，对于冷门的语言也支持快速的搜索功能；
4. 实现对漏洞扫描工具输出的集成，比如 semgrep、CodeQL 以及 SARIF 的支持；

对于前两个目标，我们只需要实现一个简单的 VIM 插件，并使用环境变量去触发这些快捷键的开启。因为代码审计本身大都只需要在“只读”模式下，因此很多 VIM 的编辑命令可以腾出来用作其他功能。

对于语言支持，目前选用的是 ctags 和 cscope 卧龙凤雏两兄弟。尽管年代久远，但实际效果还是不错的，许多商业工具实际上也是在此基础上进行优化。

对于工具集成，主要使用的是 VIM 的 quickfix 功能，即前面图片中下方区域。只需要针对特定工具的输出定义 errorformat 即可显示。然后使用快捷键映射 cnext/cprev 可以快速的在结果中进行跳转。

依赖

要实现上面的功能，我们首选需要引入一些社区中的优秀插件作为依赖：

• Plug ‘vim-scripts/taglist.vim’ - 用于在左边显示符号信息；
• Plug ‘skywind3000/asyncrun.vim’ - 在 VIM 中异步运行命令；

如果只需要模糊搜索的支持，也可以引入神器 FZF：

• Plug ‘junegunn/fzf’
• Plug ‘junegunn/fzf.vim’

以及一些常用的 SHELL 命令行工具：

• ctags - Universal Ctags；
• cscope - 查找代码定义，符号；
• ripgrep - Rust 实现的 grep 搜索；
• fzf - 模糊搜索；

构建索引

通常使用 ctags 和 cscope 构建索引的过程如下：

cd src
ctags --fields=+l

find . -name "*.c" -o -name "*.cpp" -o -name "*.h" > cscope.files
cscope -b -q -k

不过这会在源码目录生成 .tags 和 cscope.out 等索引文件。虽然我们可以指定在其他地方生成数据库，但是每次都执行一遍总归是比较繁琐，因此笔者写了一个简单的 Python 脚本用于管理代码对应的数据库。

由于数据库保存到非标准的位置，那么就需要在 VIM Script 中指定对应的 cscope 和 ctags 路径，顺便也就定义一些快捷键了。

这么一来二去，也就有了这个项目：audit.vim。

audit.vim

该项目定义为一个基于 VIM 的轻量级的代码审计工具，为了尊重每个人不同的快捷键习惯，因此采用了自定义安装的方式，即只需将 plugin/audit.vim 放到 $HOME/.vim/plugin 中，额外的插件可以根据个人需求进行安装，比如使用 VimPlug 的可以直接把 Plug 写到自己的 vimrc 中。

配套的 avim.py 脚本用于管理代码的索引文件：

$ avim.py -h
usage: avim.py [-h] [-g] {make,rm,info,open,lv} ...

lightweight code audit system with vim

positional arguments:
  {make,rm,info,open,lv}
                        sub actions
    make                create new audit session from current directory
    rm                  remove audit session
    info                show info of audit sessions
    open                vim wrapper to open files
    lv                  live grep without tags and cscope

options:
  -h, --help            show this help message and exit
  -g                    use gvim instead of vim

索引文件统一放在 $HOME/audit.vim 目录中，防止污染目标源码。同时 open 会以 READ-ONLY 模式打开 VIM 并设置好对应的 ctags 和 cscope 路径。目前为了防止审计超大型代码时候引入过多的无效文件，使用的是文件后缀白名单模式。虽然在 tag 生成方面可能有所遗漏，但搜索还是全量的，在实践中效果还算不错。

如果你平时审计过程中有沉淀过一些漏洞模式，比如 semgrep 规则，那么可以很容易使用 AsyncRun 的方式去进行快速扫描和漏洞验证，感兴趣的可以自行尝试。

最后

好了这就是本期灌水的所有内容了，你们一般都习惯用什么方式来进行代码审计呢，快点在评论区跟小编一起聊聊吧！(逃

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

四大组件

接触过 Android 的人应该都听说过 “四大组件”，开发应用首先需要学习的就是各个组件的生命周期。所谓四大组件，分别是指 Activity、Service、Broadcast Receiver 和 Content Provider，关于这些组件的实现细节可以参考官方的文档: Application Fundamentals。

在安全研究中，四大组件值得我们特别关注，因为这是应用与外界沟通的重要桥梁，甚至在应用内部也是通过这些组件构建起了相互间松耦合的联系。比如应用本身可以不申请相机权限，但可以通过组件间的相互通信让（系统）相机应用打开摄像头并取得拍到的照片，仿佛是自身进行拍照的一样。

而在组件交互的过程中，最为核心的数据结构就是 Intent，这是大部分组件之间进行通信的载体。

Intent 101

根据官方的说法，Intent 是 “对某种要执行的操作的抽象描述”，直译过来也可以叫做 “意图”，比如说想要打开摄像机拍照、想要打开浏览器访问网址，想要打开设置界面，……都可以用 Intent 来描述。

Intent 的主要形式有两种，分别是显式 Intent 和隐式 Intent；二者的差别主要在于前者显式指定了 Component，后者没有指定 Component，但是会通过足够的信息去帮助系统去理解意图，比如 ACTION、CATAGORY 等。

Intent 的最主要功能是用来启动 Activity，因此我们以这个场景为例，从源码中分析一下 Intent 的具体实现。启动 Activity 的常规代码片段如下：

Intent intent = new Intent(context, SomeActivity.class);
startActivity(intent);

这里用的是显式 Intent，但不是重点。一般在某个 Activity 中调用，因此调用的是 Activity.startActivity，代码在 frameworks/base/core/java/android/app/Activity.java 中，这里不复制粘贴了，总而言之调用链路如下：

• Activity.startActivity()
• Activity.startActivityForResult()
• Instrumentation.execStartActivity()
• ActivityTaskManager.getService().startActivity()
• IActivityTaskManager.startActivity()

最后一条调用是个接口，这是个很常见的 pattern 了，下一步应该去找其实现，不出意外的话这个实现应该在另一个进程中。事实上也正是在 system_server 中：

• ActivityTaskManagerService.startActivity()
• ActivityTaskManagerService.startActivityAsUser()
• ActivityStarter.execute()

最后一个方法通过前面传入的信息去准备启动 Activity，包括 caller、userId、flags，callingPackage 以及最重要的 intent 信息，如下：

private int startActivityAsUser(...) {
    // ...
    return getActivityStartController()
            .obtainStarter(
                intent, "startActivityAsUser")
            .setCaller(caller)
            .setCallingPackage(callingPackage)
            .setCallingFeatureId(callingFeatureId)
            .setResolvedType(resolvedType)
            .setResultTo(resultTo)
            .setResultWho(resultWho)
            .setRequestCode(requestCode)
            .setStartFlags(startFlags)
            .setProfilerInfo(profilerInfo)
            .setActivityOptions(bOptions)
            .setUserId(userId)
            .execute();
}

ActivityStarter.execute() 主要的逻辑如下:

int execute() {
    // ...
    if (mRequest.activityInfo == null) {
        mRequest.resolveActivity(mSupervisor);
    }
    res = resolveToHeavyWeightSwitcherIfNeeded();
    res = executeRequest(mRequest);

}

其中，resolveActivity 用于获取要启动的 Activity 信息，例如在隐式启动的情况下，可能有多个符合要求的目标，也会弹出菜单询问用户选用哪个应用打开。executeRequest 中则主要进行相关权限检查，在所有权限满足条件后再调用 startActivityUnchecked 去执行真正的调用。

其中大部分流程我在 Android12 应用启动流程分析 中已经介绍过了，这里更多是关注 Intent 本身的作用。从上面的分析中发现，可以将其看作是多进程通信中的消息载体，而其源码定义也能看出 Intent 本身是可以可以序列化并在进程间传递的结构。

public class Intent implements Parcelable, Cloneable { ... }

Intent 本身有很多方法和属性，这里暂时先不展开，后面介绍具体漏洞的时候再进行针对性的分析。后文主要以四大组件为着手点，分别介绍一些常见的漏洞模式和设计陷阱。

Activity

Activity 也称为活动窗口，是与用户直接交互的图形界面。APP 主要开发工作之一就是设计各个 activity，并规划他们之间的跳转和连结。通常一个 activity 表示一个全屏的活动窗口，但也可以有其他的存在形式，比如浮动窗口、多窗口等。作为 UI 窗口，一般使用 XML 文件进行布局，并继承 Activity 类实现其生命周期函数 onCreate 和 onPause 等生命周期方法。

如果开发者定义的 Activity 想通过 Context.startActivity 启动的话，就必须将其声明到 APP 的 manifest 文件中，即 AndroidManifest.xml。应用被安装时，PackageManager 会解析其 manifest 文件中的相关信息并将其注册到系统中，以便在 resolve 时进行搜索。

在 adb shell 中可以通过 am start-activity 去打开指定的 Activity，通过指定 Intent 去进行启动：

am start-activity [-D] [-N] [-W] [-P <FILE>] [--start-profiler <FILE>]
        [--sampling INTERVAL] [--streaming] [-R COUNT] [-S]
        [--track-allocation] [--user <USER_ID> | current] <INTENT>

作为用户界面的载体，Activity 承载了许多用户输入/处理、以及外部数据接收/展示等工作，因此是应用对外的一个主要攻击面。下面就介绍几种较为常见的攻击场景。

生命周期

Activity 经典的生命周期图示如下：

通常开发者只需要实现 onCreate 方法，但是对于一些复杂的业务场景，正确理解其生命周期也是很必要的。以笔者在内测中遇到的某应用为例，其中某个 Activity 中执行了一些敏感的操作，比如开启摄像头推流，或者开启了录音，但只在 onDestroy 中进行了推流/录音的关闭。这样会导致在 APP 进入后台时候，这些操作依然在后台运行，攻击者可以构造任务栈使得受害者在面对恶意应用的钓鱼界面时候仍然执行目标应用的后台功能，从而形成特殊的钓鱼场景。正确的做法应该是在 onPaused 回调中对敏感操作进行关闭。

攻击者实际可以通过连续发送不同的 Intent 去精确控制目标 Activity 生命周期回调函数的触发时机，如果开发时没有注意也会造成应用功能的状态机异常甚至是安全问题。

Implicit Exported

前面说过，开发者定义的 Activity 要想使用 startActivity 去启动，就必须在 AndroidManifest.xml 中使用 <activity> 进行声明，一个声明的示例如下：

<activity xmlns:android="http://schemas.android.com/apk/res/android" android:theme="@android:01030055" android:name="com.evilpan.RouterActivity">
  <intent-filter>
    <action android:name="android.intent.action.VIEW"/>
    <category android:name="android.intent.category.DEFAULT"/>
    <category android:name="android.intent.category.BROWSABLE"/>
    <data android:scheme="demo" android:host="router"/>
  </intent-filter>
</activity>

activity 中支持许多属性。其中一个重要的属性就是 android:exported，表示当前 Activity 是否可以被其他应用的组件启动。该属性有几个特点：

1. 属性可以缺省，缺省值默认为 false；
2. 如果 Activity 没有显式设置该属性，且该 Activity 中定义了 <intent-filter>，那么缺省值就默认为 true；

也就是说，开发者可能没有显式指定 Activity 导出，但由于指定了 intent-filter，因此实际上也是导出的，即可以被其他应用唤起对应的 Activity。这种情况在早期很常见，比如 APP 设计了一组更换密码的界面，需要先输入旧密码然后再跳转到输入新密码的界面，如果后者是导出的，攻击者就可以直接唤起输入新密码的界面，从而绕过了旧密码的校验逻辑。

Google 已经深刻意识到了这个问题，因此规定在 Android 12 之后，如果应用的 Activity 中包含 intent-filter，就必须要显式指定 android:exported 为 true 或者 false，不允许缺省。在 Android 12 中未显式指定 exported 属性且带有 intent-filter 的 Activity 的应用在安装时候会直接被 PackageManager 拒绝。

Fragment Injection

Activity 作为 UI 核心组件，同时也支持模块化的开发，比如在同一个界面中展示若干个可复用的子界面。随着这种设计思路诞生的就是 Fragments 组件，即 “片段”。使用 FragmentActivity 可以在一个 Activity 中组合一个或者多个片段，方便进行代码复用，片段的生命周期受到宿主 Activity 的影响。

Fragment Injection 漏洞最早在 2013 年爆出，这里只介绍其原理，本节末尾附有原始的文章以及论文。漏洞的核心是系统提供的 PreferenceActivity 类，开发者可以对其进行继承实现方便的设置功能，该类的 onCreate 函数有下面的功能：

protected void onCreate() {
    // ...
    String initialFragment = getIntent().getStringExtra(EXTRA_SHOW_FRAGMENT);
    Bundle initialArguments = getIntent().getBundleExtra(EXTRA_SHOW_FRAGMENT_ARGUMENTS);
    // ...
    if (initialFragment != null) {
        switchToHeader(initialFragment, initialArguments);
    }
}

private void switchToHeaderInner(String fragmentName, Bundle args) {
    getFragmentManager().popBackStack(BACK_STACK_PREFS,
            FragmentManager.POP_BACK_STACK_INCLUSIVE);
    if (!isValidFragment(fragmentName)) {
        throw new IllegalArgumentException("Invalid fragment for this activity: "
                + fragmentName);
    }

    Fragment f = Fragment.instantiate(this, fragmentName, args);
}

可以看到从 Intent 中获取了一个字符串和一个 Bundle 参数，并最终传入 switchToHeaderInner 中，用于实例化具体的 Fragment。实例化的过程如下：

public static Fragment instantiate(Context context, String fname, Bundle args) {
    // ...
    Class clazz = sClassMap.get(fname);
    if (clazz == null) {
            // Class not found in the cache, see if it's real, and try to add it
            clazz = context.getClassLoader().loadClass(fname);
            sClassMap.put(fname, clazz);
    }
    Fragment f = (Fragment)clazz.newInstance();
    if (args != null) {
            args.setClassLoader(f.getClass().getClassLoader());
            f.mArguments = args;
    }
    return f;
}

经典的反射调用，将传入的字符串实例化为 Java 类，并设置其参数。这是什么，这就是反序列化啊！而实际的漏洞也正是出自这里，由于传入的参数攻击者可控，那么攻击者可以将其设置为某个内部类，从而触及开发者预期之外的功能。在原始的报告中，作者使用了 Settings 应用中的某个设置 PIN 密码的 Fragment 作为目标传入，这是个私有片段，从而导致了越权修改 PIN 码的功能。在当时的其他用户应用中，还有许多也使用了 PreferenceActivity，因此漏洞影响广泛，而且造成的利用根据应用本身的功能而异（也就是看有没有好用的 Gadget）。

注意上面的代码摘自最新的 Android 13，其中 switchToHeaderInner 方法加入了 isValidFragment 的判断，这正是 Android 当初的修复方案之一，即强制要求 PreferenceActivity 的子类实现该方法，不然就在运行时抛出异常。不过即便如此，还是有很多开发者为了图方便直接继承然后返回 true 的。

Fragment Injection 看似是 PreferenceActivity 的问题，但其核心还是对于不可信输入的校验不完善，在后文的例子中我们会多次看到类似的漏洞模式。

参考文章：

• A New Vulnerability in the Android Framework: Fragment Injection
• ANDROID COLLAPSES INTO FRAGMENTS.pdf (wp)
• Understanding fragment injection
• How to fix Fragment Injection vulnerability

点击劫持

Activity 既然作为 UI 的主要载体，那么与用户的交互也是其中关键的一项功能。在传统 Web 安全中就已经有过点击劫持的方法，即将目标网站想要让受害者点击的案件放在指定位置（如iframe），并在宿主中使用相关组件对目标进行覆盖和引导，令受害者在不知不觉中执行了敏感操作，比如点赞投币收藏一键离职等。

Android 中也出现过类似的攻击手段，比如在系统的敏感弹窗前面覆盖攻击者自定义的 TextView，引导受害者确认某些有害操作。当然这需要攻击者的应用拥有浮窗权限（SYSTEM_ALERT_WINDOW），在较新的 Android 系统中，该权限的申请需要用户多次的确认。

近两年中在 AOSP 中也出现过一些点击劫持漏洞，包括但不限于：

• CVE-2020-0306：蓝牙发现请求确认框覆盖
• CVE-2020-0394：蓝牙配对对话框覆盖
• CVE-2020-0015：证书安装对话框覆盖
• CVE-2021-0314：卸载确认对话框覆盖
• CVE-2021-0487：日历调试对话框覆盖
• …

对于系统应用而言，防御点击劫持的方法一般是通过使用 android.permission.HIDE_NON_SYSTEM_OVERLAY_WINDOWS 权限并在布局参数中指定 SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS 来防止 UI 被覆盖。

而对于普通应用，没法申请 HIDE_NON_SYSTEM_OVERLAY_WINDOWS 权限，防御措施一般有两种，一是通过将布局的 filterTouchesWhenObscured 设置为 true 来禁止窗体被覆盖后的输入事件；二是重载 View.onFilterTouchEventForSecurity 方法，并在其中检测其他应用的覆盖情况。在 Android 12 中系统已经默认开启了 filterTouchesWhenObscured 属性，这也是 security by default 的一种经典实现。

关于点击劫持的操作细节和缓解方案，可以参考 OPPO 安全实验室的这篇文章： 《不可忽视的威胁：Android中的点击劫持攻击》

另外一个与点击劫持类似的漏洞称为 StrandHogg，细节可以参考下述的原始文章。其关键点是使用了 Activity 的 allowTaskReparenting 和 taskAffinity 属性，将其任务栈伪装成目标应用，这样在打开目标应用时由于 TaskStack 后进先出的特性会导致用户看到的是攻击者的应用，从而造成应用的钓鱼场景。

后来还是同一个安全团队有提出了 StrandHogg 2.0 版本，主要利用了 ActivityStarter 中的 AUTOMERGE 特性。假设有 A、B 两个应用，在 A1 中调用 startActivites(B1, A2, B2) 之后，任务栈会从 (A1, B1) 以及 (A2, B2) 合并为 (A1, B1, A2, B2)，也就是在同一个任务栈中覆盖了其他应用的 Activity，从而导致钓鱼场景。不过这个漏洞比较特化，因此谷歌很早就已经修复了，详情可以阅读下面的参考文章：

• The StrandHogg vulnerability
• StrandHogg 2.0 – New serious Android vulnerability
• StrandHogg 2.0 (CVE-2020-0096) 修复方案

Intent Redirection

Intent Redirection，顾名思义就是将用户传入的不可信输入进行了转发，类似于服务端的 SSRF 漏洞。一个典型漏洞例子如下：

protected void onCreate (Bundle savedInstanceState) {
   Intent target = (Intent) getIntent().getParcelableExtra("target");
   startActivity(target);
}

将用户传入的 target Parcelable 直接转换成了 Intent 对象，并将这个对象作为 startActivity 的参数进行调用。就这个例子而言，可能造成的危害就是攻击者可以用任意构造的 Intent 数据去启动目标 APP 中的任意应用，哪怕是未导出的私有应用。而目标未导出的应用中可能进一步解析了攻击者提供的 Intent 中的参数，去造成进一步的危害，比如在内置 Webview 中执行任意 Javascript 代码，或者下载保存文件等。

实际上 Intent Redirection 除了可能用来启动私有 Activity 组件，还可以用于其他的的接口，包括：

• startActivity
• startService
• sendBroadcast
• setResult

注：每种方法可能还有若干衍生方法，比如 startActivityForResult

前面三个可能比较好理解，分别是启动界面、启动服务和发送广播。最后一个 setResult 可能会在排查的时候忽略，这主要用来给当前 Activity 的调用者返回额外数据，主要用于 startActivityForResult 的场景，这同样也可能将用户的不可信数据污染到调用者处。

从防御的角度上来说，建议不要直接把外部传入的 Intent 作为参数发送到上述四个接口中，如果一定要这么做的话，需要事先进行充分的过滤和安全校验，比如：

1. 将组件本身的 android:exported 设置为 false，但这只是防止了用户主动发送的数据，无法拦截通过 setResult 返回的数据；
2. 确保获取到的 Intent 来自于可信的应用，比如在组件上下文中调用 getCallingActivity().getPackageName().equals("trust.app")，但注意恶意的应用可以通过构造数据令 getCallingActivity 返回 null；
3. 确保待转发的 Intent 没有有害行为，比如 component 不指向自身的非导出组件，不带有 FLAG_GRANT_READ_URI_PERMISSION 等（详见后文 ContentProvider 漏洞）；
4. …

但事实证明，即便是 Google 自己，也未必能够确保完善的校验。无恒实验室近期提交的高危漏洞 CVE-2022-20223 就是个很典型的例子：

private void assertSafeToStartCustomActivity(Intent intent) {
    // Activity can be started if it belongs to the same app
    if (intent.getPackage() != null && intent.getPackage().equals(packageName)) {
        return;
    }
    // Activity can be started if intent resolves to multiple activities
    List<ResolveInfo> resolveInfos = AppRestrictionsFragment.this.mPackageManager
            .queryIntentActivities(intent, 0 /* no flags */);
    if (resolveInfos.size() != 1) {
        return;
    }
    // Prevent potential privilege escalation
    ActivityInfo activityInfo = resolveInfos.get(0).activityInfo;
    if (!packageName.equals(activityInfo.packageName)) {
        throw new SecurityException("Application " + packageName
                + " is not allowed to start activity " + intent);
    }
}

其中使用了 ActivityInfo.packageName 来判断启动目标的包名是否与当前 caller 的包名一致，可事实上显式 Intent 是通过 componentName 去指定启动目标，优先级高于 Intent.packageName 且后者可以被伪造，这就造成了检查的绕过。上述短短几行代码中其实还有另外一个漏洞，感兴趣的可以参考下面的参考链接。

因此，遇到潜在的 Intent 重定向问题时，可以多花点时间仔细审查，说不定就能够找到一个可利用的场景。

• Remediation for Intent Redirection Vulnerability
• AOSP Bug Hunting with appshark (1): Intent Redirection

Service

Service 的主要功能有两个，一是给 APP 提供一个后台的长时间运行环境，二是对外提供自身的服务。与 Activity 的定义类似，Service 必须要在 manifest 中进行声明才能使用。注意 Service 中的代码也是和 Activity 一样运行在主线程的，并且默认和应用处于进程。

根据 Service 的两大主要功能区分，启动 Service 也有对应的两种形式：

1. Context.startService()：启动后台服务并让系统进行调度；
2. Context.bindService()：让（外部）应用绑定服务，并使用其提供的接口，可以理解为 RPC 的服务端；

两种方式启动服务的生命周期图示如下：

蓝色部分都是在客户端去进行调用，系统收到请求后会启动对应的服务，如果对应的进程没有启动也会通知 zygote 去启动。不管是哪种方法创建服务，系统都会为其调用 onCreate 和 onDestroy 方法。整体流程和 Activity 的启动流程类似，这里不再赘述。

shell 中同样提供了 start-activity 命令来方便启动服务：

am start-service [--user <USER_ID> | current] <INTENT>

下面来介绍一些 Service 组件相关的漏洞。

生命周期

前面介绍了 Service 启动的生命周期，总体和 Activity 流程差不多，但需要注意有几点不同：

1. 与 Activity 生命周期回调方法不同，不需要调用 Serivce 回调方法的超类实现，比如 onCreate、onDestory 等；
2. Service 类的直接子类运行在主线程中，同时处理多个阻塞的请求时候一般需要在新建线程中执行；
3. IntentService 是 Service 的子类，被设计用于运行在 Worker 线程中，可以串行处理多个阻塞的 Intent 请求；API-30 以后被标记为废弃接口，建议使用 WorkManager 或者 JobIntentService 去实现；
4. 客户端通过 stopSelf 或者 stopService 来停止绑定服务，但服务端并没有对应的 onStop 回调，只有在销毁前收到 onDestory；
5. 前台服务必须为状态栏提供通知，让用于意识到服务正在运行；

对于绑定服务而言，Android 系统会根据绑定的客户端引用计数来自动销毁服务，但如果服务实现了 onStartCommand() 回调，就必须显式地停止服务，因为系统会将其视为已启动的状态。此外，如果服务允许客户端再次绑定，就需要实现 onUnbind 方法并返回 true，这样客户端在下次绑定时候会接收到同样的 IBinder，示例图如下所示：

服务的声明周期相比于 Activity 更加复杂，因为涉及到进程间的绑定关系，因此也就更可能在不了解的情况下编写出不健壮甚至有问题的代码。

Implicit Export

和 Activity 一样，Service 也要在 manifest 中使用 service 去声明，也有 android:exported 属性。甚至关于该属性的默认值定义也是一样的，即默认是 false，但包含 intent-filter 时，默认就是 true。同样，在 Android 12 及以后也强制性要求必须显式指定服务的导出属性。

服务劫持

与 Activity 不同的是，Android 不建议使用隐式 Intent 去启动服务。因为服务在后台运行，没有可见的图形界面，因此用户看不到隐式 Intent 启动了哪个服务，且发送者也不知道 Intent 会被谁接收。

服务劫持是一个典型的漏洞，攻击者可以为自己的 Service 声明与目标相同的 intent-filter 并设定更高的优先级，这样可以截获到本应发往目标服务的 Intent，如果带有敏感信息的话还会造成数据泄露。

而在 bindService 中这种情况的危害则更加严重，攻击者可以伪装成目标 IPC 服务去返回错误甚至是有害的数据。因此，在 Android 5.0 （API-21）开始，使用隐式 Intent 去调用 bindService 会直接抛出异常。

如果待审计的目标应用在 Service 中提供了 intent-filter，那么就需要对其进行重点排查。

AIDL

绑定服务可以被用来用作 IPC 服务端，如果服务端绑定的时候返回了 AIDL 接口的实例，那么就意味着客户端可以调用该接口的任意方法。一个实际案例是 Tiktok 的 IndependentProcessDownloadService，在 DownloadService 的 onBind 中返回了上述 AIDL 接口的实例：

com/ss/android/socialbase/downloader/downloader/DownloadService.java:

if (this.downloadServiceHandler != null) {
    return this.downloadServiceHandler.onBind(intent);
}

而其中有个 tryDownload 方法可以指定 url 和文件路径将文件下载并保存到本地。虽然攻击者没有 AIDL 文件，但还是可以通过反射去构造出合法的请求去进行调用，PoC 中关键的代码如下：

private ServiceConnection mServiceConnection = new ServiceConnection() {
    public void onServiceConnected(ComponentName cName, IBinder service) {
        processBinder(service);
    }

    public void onServiceDisconnected(ComponentName cName) { }
};

protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    Intent intent = new Intent("com.ss.android.socialbase.downloader.remote");
    intent.setClassName(
        "com.zhiliaoapp.musically",
        "com.ss.android.socialbase.downloader.downloader.IndependentProcessDownloadService");
    bindService(intent, mServiceConnection, BIND_AUTO_CREATE);
}

private void processBinder(IBinder binder) {
    ClassLoader cl = getForeignClassLoader(this, "com.zhiliaoapp.musically");
    Object handler = cl.loadClass("com.ss.android.socialbase.downloader.downloader.i$a")
            .getMethod("asInterface", IBinder.class)
            .invoke(null, binder);

    Object payload = getBinder(cl);

    cl.loadClass("com.ss.android.socialbase.downloader.downloader.i")
            .getMethod("tryDownload", cl.loadClass("com.ss.android.socialbase.downloader.model.a"))
            .invoke(handler, payload);
}

private Object getBinder(ClassLoader cl) throws Throwable {
    Class utilsClass = cl.loadClass("com.ss.android.socialbase.downloader.utils.g");
    Class taskClass = cl.loadClass("com.ss.android.socialbase.downloader.model.DownloadTask");
    return utilsClass.getDeclaredMethod("convertDownloadTaskToAidl", taskClass)
            .invoke(null, getDownloadTask(taskClass, cl));
}

关键在于使用 Context.getForeignClassLoader 获取其他应用的 ClassLoader。

漏洞细节参考： vulnerabilities in the TikTok Android app

Intent Redirect

这个其实和 Activity 中的对应漏洞类似，客户端启动/绑定 Service 的时候也指定了隐式或者显式的 Intent，其中的不可信数据如果被服务端用来作为启动其他组件的参数，就有可能造成一样的 Intent 重定向问题。注意除了 getIntent() 之外还有其他数据来源，比如服务中实现的 onHandleIntent 的参数。

其实最早提出 Intent 重定向危害的 “LaunchAnywhere” 漏洞就是出自系统服务，准确来说是 AccountManagerService 的漏洞。AccountManager 正常的执行流程为：

1. 普通应用（记为 A）去请求添加某类账户，调用 AccountManager.addAccount；
2. AccountManager 会去查找提供账号的应用（记为 B）的 Authenticator 类；
3. AccountManager 调用 B 的 Authenticator.addAccount 方法；
4. AccountManager 根据 B 返回的 Intent 去调起 B 的账户登录界面（AccountManagerResponse.getParcelable）；

在第 4 步时，系统认为 B 返回的数据是指向 B 的登陆界面的，但实际上 B 可以令其指向其他组件，甚至是系统组件，就造成了一个 Intent 重定向的漏洞。这里 Intent 的来源比较曲折，但本质还是攻击者可控的。

关于该漏洞的细节和利用过程可参考：launchAnyWhere: Activity组件权限绕过漏洞解析(Google Bug 7699048 )

Receiver

Broadcast Receiver，简称 receiver，即广播接收器。前面介绍的 Activity 和 Service 之间的联动都是一对一的，而很多情况下我们可能想要一对多或者多对多的通信方案，广播就承担了这个功能。比如，Android 系统本身就会在发生各种事件的时候发送广播通知所有感兴趣的应用，比如开启飞行模式、网络状态变化、电量不足等等。这是一种典型的发布/订阅的设计模式，广播数据的载体也同样是 Intent。

与前面 Activity 与 Service 不同的是，Receiver 可以在 manifest 中进行声明注册，称为静态注册；也可以在应用运行过程中进行动态注册。但无论如何，定义的广播接收器都要继承自 BroadcastReceiver 并实现其声明周期方法 onReceive(context, intent)。

注意 BroadcastReceiver 的父类是 Object，不像 Activity 与 Service 是 Context，因此 onReceive 还会额外传入一个 context 对象。

shell 中发送广播的命令如下：

am broadcast [--user <USER_ID> | all | current] <INTENT>

下面还是按顺序介绍一些常见的问题。

Implicit Export

使用静态注册的 receiver 倒没什么特殊，示例如下：

<receiver android:name=".MyBroadcastReceiver"  android:exported="true">
    <intent-filter>
        <action android:name="android.intent.action.BOOT_COMPLETED"/>
        <action android:name="android.intent.action.INPUT_METHOD_CHANGED" />
    </intent-filter>
</receiver>

同样存在和之前一样的默认 export 问题，相信大家已经看腻了，就不再啰嗦了。接着看动态注册的情况，比如：

BroadcastReceiver br = new MyBroadcastReceiver();
IntentFilter filter = new IntentFilter(ConnectivityManager.CONNECTIVITY_ACTION);
filter.addAction(Intent.ACTION_AIRPLANE_MODE_CHANGED);
this.registerReceiver(br, filter);

与清单中的定义相比，动态注册的方式可能更容易忽略导出权限的问题。上述代码片段动态注册了一个广播，但没有显式声明 exported 属性，因此默认是导出的。事实上使用 registerReceiver 似乎没有简单的方法去设置 exported=false，而 Google 官方的建议是对于不需要导出的广播接收器使用 LocalBroadcastManager.registerReceiver 进行注册，或者在注册的时候指定 permission 权限。

对于指定 permission 权限的情况，如果是自定义权限，需要在应用清单中声明，比如：

<permission android:name="com.evilpan.MY_PERMISSION"
    android:protectionLevel="signature"/>
<uses-permission android:name="com.evilpan.MY_PERMISSION" />

signature 表示只有在请求授权的应用使用与声明权限的应用相同的证书进行签名时系统才会授予的权限。如果证书匹配，则系统会在不通知用户或征得用户明确许可的情况下自动授予权限。详见 protectionLevel。

最后在动态注册时指定该权限即可：

this.registerReceiver(br, filter, "com.evilpan.MY_PERMISSION", null);

注册未带有权限限制的导出广播接收器会导致接收到攻击者伪造的恶意数据，如果在 onReceive 时校验不当，可能会出现越权或者 Intent 重定向等漏洞，造成进一步的安全危害。

这类安全问题很多，比较典型的就有 Pwn2Own 上用于攻破三星 Galaxy S8 的 PpmtReceiver 漏洞。

信息泄露

上面主要是从限制广播发送方的角度去设置权限，但其实这个权限也能限制广播的接收方，只不过发送消息的时候要进行额外的指定，比如要想只让拥有上述权限的接收方受到广播，则发送代码如下：

Intent it = new Intent(this, ...);
it.putExtra("secret", "chicken2beautiful")
sendBroadcast(it, "com.evilpan.MY_PERMISSION");

如果不带第二个参数的话，默认是所有满足条件的接受方都能受到广播信息的。此时若是发送的 Intent 中带有敏感数据，就可能会造成信息泄露问题。

一个实际案例就是 CVE-2018-9581，系统在广播 android.net.wifi.RSSI_CHANGED 时携带了敏感数据 RSSI，此广播能被所有应用接收，从而间接导致物理位置信息泄露。（搞笑？）

可见对于 Broadcast Receiver 而言，permission 标签的作用尤其明显。对于系统广播而言，比如 BOOT_COMPLETED，通常只有系统应用才有权限发送。这都是在 framework 的 AndroidManifest.xml 中进行定义的。

而对于应用的自定义广播，通常是使用上述自定义权限，那么也就自然想到一个问题，如果多个应用定义了同一个权限会怎么样？其实这是正是一个历史漏洞，在早期 Android 的策略是优先采用第一个定义的权限，但在 Andorid 5 之后就已经明确定义了两个应用不同定义相同的权限（除非他们的签名相同），否则后安装的应用会出现 INSTALL_FAILED_DUPLICATE_PERMISSION 错误警告。感兴趣的考古爱好者可以参考下面的相关文章：

• Vulnerabilities with Custom Permissions
• Custom Permission Vulnerability and the ‘L’ Developer Preview

Intent Redirection

原理不多说了，直接看案例吧。漏洞出在 Tiktok 的 NotificationBroadcastReceiver 中，定义了 intent-filter 导致组件默认被设置为导出，因此可以接收到外部应用的广播，而且又将广播中的不可信数据直接拿来启动 Activity，如下：

漏洞细节可参考：Oversecured detects dangerous vulnerabilities in the TikTok Android app

ContentProvider

Content Provider，即内容提供程序，简称为 Provider。Android 应用通常实现为 MVC 结构（Model-View-Controller），Model 部分即为数据来源，供自身的 View 即图形界面进行展示。但有时候应用会想要将自身的数据提供给其他数据使用，或者从其他应用中获取数据。

定义一个 ContentProvider 的方式，只需要继承自 ContentProvider 类并实现六个方法： query，insert， update， delete， getType 以及 onCreate。其中除了 onCreate 是系统在主线程调用的，其他方法都由客户端程序进行主动调用。自定义的 provider 必须在程序清单中进行声明，后文会详细介绍。

可以看到 Provider 主要实现了类似数据库的增删改查接口，从客户端来看，查询过程也和查询传统数据库类似，例如，下面是查询系统短信的代码片段：

Cursor cursor = getContentResolver().query(
    Telephony.Sms.Inbox.CONTENT_URI,           // 指定要查询的表名
    new String[] { Telephony.Sms.Inbox.BODY }, // projection 指定索要查询的列名
    selectionClause,                           // 查询的过滤条件
    selectionArgs,                             // 查询过滤的参数 
    Telephony.Sms.Inbox.DEFAULT_SORT_ORDER);   // 返回结果的排序
while (cursor.moveToNext()) {
    Log.i(TAG, "msg: " + cursor.getString(0));
}

其中 ContentResolver 是 ContentInterface 子类，后者是 ContentProvider 的客户端远程接口，可以实现其透明的远程代理调用。 content_uri 可以看作是查询的表名，projection 可以看作是列名，返回的 cursor 是查询结果行的迭代器。

与前面三个组件不同，在 shell 中访问 provider 组件的工具是 content。

下面来介绍 Provider 中常见的问题。

Permissions

鉴于 provider 作为数据载体，那么安全访问与权限控制自然是重中之重。例如上面代码示例中访问短信的接口，如果所有人都能随意访问，那就明显会带来信息泄露问题。前面简单提到过，应用中定义的 Provider 必须要在其程序清单文件中进行声明，使用的是 provider 标签。其中有我们常见的 exported 属性，表示是否可被外部访问，permission 属性则表示访问所需的权限，当然也可以分别对读写使用不同的权限，比如 readPermission/writePermission 属性。

比如，前文提到的短信数据库声明如下：

<provider android:name="SmsProvider"
    android:authorities="sms"
    android:multiprocess="false"
    android:exported="true"
    android:singleUser="true"
    android:readPermission="android.permission.READ_SMS" />

其他应用若想访问，则需在清单文件中声明请求对应权限。

<uses-permission android:name="android.permission.READ_SMS" />

这都很好理解，其他组件也有类似的特性。除此之外，Provider 本身还提供了更为细粒度的权限控制，即 grantUriPermissions。这是一个布尔值，表示是否允许临时为客户端授予该 provider 的访问权限。临时授予权限的运行流程一般如下：

1. 客户端给 Provider 所在应用发送一个 Intent，指定想要访问的 Content URI，比如使用 startActivityForResult 发送；
2. 应用收到 Intent 后，判断是否授权，如果确认则准备一个 Intent，并设置好 flags 标志位 FLAG_GRANT_[READ|WRITE]_URL_PERMISSION，表示允许读/写对应的 Content URI（可以不和请求的 URI 一致），最后使用 setResult(code, intent) 返回给客户端；
3. 客户端的 onActivityResult 收到返回的 Intent，使用其中的 URI 来临时对目标 Provider 进行访问；

以读为例，Intent.flags 中如果包含 FLAG_GRANT_READ_URI_PERMISSION，那么该 Intent 的接收方（即客户端）会被授予 Intent.data 部分 URI 的临时读取权限，直至接收方的生命周期结束。另外，Provider 应用也可以主动调用 Context.grantUriPermission 方法来授予目标应用对应权限：

public abstract void grantUriPermission (String toPackage, 
                Uri uri, 
                int modeFlags)
public abstract void revokeUriPermission (String toPackage, 
                Uri uri, 
                int modeFlags)

grantUriPermissions 属性可以在 URI 粒度对权限进行读写控制，但有一个需要注意的点：通过 grantUriPermissions 临时授予的权限，会无视 readPermission、writePermission、permission 和 exported 属性施加的限制。也就是说，即便 exported=false，客户端也没有申请对应的 uses-permission，可一旦被授予权限，依然可以访问对应的 Content Provider！

另外，<provider> 还有一个子标签 grant-uri-permission，即便 grantUriPermissions 被设置为 false，通过临时获取权限依然可以访问该标签下定义的 URI 子集，该子集可以用前缀或者通配符去指定 URI 的可授权路径范围。

Provider 权限设置不当可能会导致应用数据被预期之外的恶意程序访问，轻则导致信息泄露，重则会使得自身沙盒数据被覆盖而导致 RCE，后文会看到多个这样的案例。

FileProvider

前面说过自定义 Provider 需要实现六个方法，但 Android 中已经针对某些常用场景的 Provider 编写好了对应的子类，用户可根据需要继承这些子类并实现少部分子类方法即可。其中一个常用场景就是用 ContentProvider 分享应用的文件，系统提供了 FileProvider 来方便应用自定义文件分享和访问，但是使用不当的话很可能会出现任意文件读写的问题。

FileProvider 提供了使用 XML 去指定文件访问控制的功能，一般 Provider 应用只需继承 FileProvider 类：

public class MyFileProvider extends FileProvider {
   public MyFileProvider() {
       super(R.xml.file_paths)
   }
}

file_paths 是用户自定义的 XML，也可以在清单文件中使用 meta-data 去指定：

<provider xmlns:android="http://schemas.android.com/apk/res/android" android:name="com.evilpan.MyFileProvider" android:exported="false" android:authorities="com.evilpan.fileprovider" android:grantUriPermissions="true">
  <meta-data android:name="android.support.FILE_PROVIDER_PATHS" android:resource="@7F15000E"/>
</provider>

resource 指向 res/xml/file_paths.xml。该文件中定义了可供访问的文件路径，FileProvider 只会对提前指定的文件生成 Content URI。一个文件路径配置示例如下：

<paths>
  <root-path name="root" path=""/>
  <files-path name="internal_files" path="."/>
  <cache-path name="cache" path=""/>
  <external-path name="external_files" path="images"/>
</paths>

paths 标签支持多种类型的子标签，分别对应不同目录的子路径：

• files-path: Context.getFilesDir()
• cache-path: Context.getCacheDir()
• external-path: Environment.getExternalStorageDirectory()
• external-files-path: Context.getExternalFilesDir()
• external-cache-path: Context.getExternalCacheDir()
• external-media-path: Context.getExternalMediaDirs()[0]

比较特殊的是 root-path，表示系统的根目录 /。FileProvider 生成的 URI 格式一般是 content://authority/{name}/{path}，比如对于上述 Provider，可用 content://com.evilpan.fileprovider/root/proc/self/maps 来访问 /proc/self/maps 文件。

由此可见，FileProvider 指定 root-path 是一个危险的标志，一旦攻击者获得了临时权限，就可以读取所有应用的私有数据。

比如，TikTok 历史上就有过这么一个真实的漏洞：

<provider android:name="android.support.v4.content.FileProvider" android:exported="false" android:authorities="com.zhiliaoapp.musically.fileprovider" android:grantUriPermissions="true">
        <meta-data android:name="android.support.FILE_PROVIDER_PATHS" android:resource="@xml/k86"/>
    </provider>

这里直接使用了 FileProvider，甚至都不需要继承。xml/k86.xml 文件内容如下：

<?xml version="1.0" encoding="utf-8"?>
<paths xmlns:amazon="http://schemas.amazon.com/apk/res/android" xmlns:android="http://schemas.android.com/apk/res/android" xmlns:app="http://schemas.android.com/apk/res-auto">
    <root-path name="name" path=""/>
    <external-path name="share_path0" path="share/"/>
    <external-path name="download_path2" path="Download/"/>
    <cache-path name="gif" path="gif/"/>
    ...
</paths>

获取临时权限之后就可以实现应用的任意文件读写。

The Hidden …

在 ContentProvider 类中，除了前面说过的 6 个必须实现的方法，还有一些其他隐藏的方法，一般使用默认实现，也可以被子类覆盖实现，比如

• openFile
• openFileHelper
• call
• …

这些隐藏的方法可能在不经意间造成安全问题，本节会通过一些案例去分析其中的原因。

openFile

如果 ContentProvider 想要实现共享文件读写的功能，还可以通过覆盖 openFile 方法去实现，该方法的默认实现会抛出 FileNotFoundException 异常。

虽然开发者实现上不太会直接就返回打开的本地文件，而是有选择地返回某些子目录文件。但是如果代码写得不严谨，就可能会出现路径穿越等问题，一个经典的漏洞实现如下：

 @Override
public ParcelFileDescriptor openFile(Uri uri, String mode) throws FileNotFoundException {
    File file = new File(getContext().getFilesDir(), uri.getPath());
    if(file.exists()){
        return ParcelFileDescriptor.open(file, ParcelFileDescriptor.MODE_READ_ONLY);
    }
    throw new FileNotFoundException(uri.getPath());
}

另外一个同族的类似方法是 openAssetFile，其默认实现是调用 openFile：

public @Nullable AssetFileDescriptor openAssetFile(@NonNull Uri uri, @NonNull String mode)
        throws FileNotFoundException {
    ParcelFileDescriptor fd = openFile(uri, mode);
    return fd != null ? new AssetFileDescriptor(fd, 0, -1) : null;
}

有时候开发者虽然知道要要防御路径穿越，但防御的姿势不对，也存在被绕过的可能，比如：

public ParcelFileDescriptor openFile(Uri uri, String mode) {
    File f = new File(DIR, uri.getLastPathSegment());
    return ParcelFileDescriptor.open(f, ParcelFileDescriptor.MODE_READ_ONLY);
}

这里想用 getLastPathSegment 去只获取最后一级的文件名，但实际上可以被 URL encode 的路径绕过，比如 %2F..%2F..path%2Fto%2Fsecret.txt 会返回 /../../path/to/secret.txt。

还有一种错误的防御是使用 UriMatcher.match 方法去查找 ../，这也会被 URL 编码绕过。正确的防御和过滤方式如下：

public ParcelFileDescriptor openFile (Uri uri, String mode) throws FileNotFoundException {
  File f = new File(DIR, uri.getLastPathSegment());
  if (!f.getCanonicalPath().startsWith(DIR)) {
    throw new IllegalArgumentException();
  }
  return ParcelFileDescriptor.open(f, ParcelFileDescriptor.MODE_READ_ONLY);
}

详见：Path Traversal Vulnerability

openFileHelper

ContentProvider 中还有一个鲜为人知的 openFileHelper 方法，其默认实现是使用当前 Provider 中的 _data 列数据去打开文件，源码如下：

protected final @NonNull ParcelFileDescriptor openFileHelper(@NonNull Uri uri,
        @NonNull String mode) throws FileNotFoundException {
    Cursor c = query(uri, new String[]{"_data"}, null, null, null);
    int count = (c != null) ? c.getCount() : 0;
    if (count != 1) {
        // If there is not exactly one result, throw an appropriate
        // exception.
        if (c != null) {
            c.close();
        }
        if (count == 0) {
            throw new FileNotFoundException("No entry for " + uri);
        }
        throw new FileNotFoundException("Multiple items at " + uri);
    }

    c.moveToFirst();
    int i = c.getColumnIndex("_data");
    String path = (i >= 0 ? c.getString(i) : null);
    c.close();
    if (path == null) {
        throw new FileNotFoundException("Column _data not found.");
    }

    int modeBits = ParcelFileDescriptor.parseMode(mode);
    return ParcelFileDescriptor.open(new File(path), modeBits);
}

这个方法的主要作用是方便子类用于快速实现 openFile 方法，通常不会直接在子类去覆盖。不过由于其中基于 _data 列去打开文件的特性可能会攻击者插入恶意数据后间接地实现任意文件读写。

一个经典案例就是三星手机的 SemClipboardProvider，在插入时未校验用户数据：

public Uri insert(Uri uri, ContentValues values) {
    long row = this.database.insert(TABLE_NAME, "", values);
    if (row > 0) {
        Uri newUri = ContentUris.withAppendedId(CONTENT_URI, row);
        getContext().getContentResolver().notifyChange(newUri, null);
        return newUri;
    }
    throw new SQLException("Fail to add a new record into " + uri);
}

而该 Provider 又在 system_server 进程中，拥有极高的运行权限，攻击者通过利用这个漏洞去就能实现系统层面的任意文件读写，其 PoC 如下：

ContentValues vals = new ContentValues();
vals.put("_data", "/data/system/users/0/newFile.bin");
URI semclipboard_uri = URI.parse("content://com.sec.android.semclipboardprovider")
ContentResolver resolver = getContentResolver();
URI newFile_uri = resolver.insert(semclipboard_uri, vals);
return resolver.openFileDescriptor(newFile_uri, "w").getFd(); 

该漏洞与其他漏洞一起曾被用于在野攻击中，由 Google TAG 团队捕获，对这一条 Fullchain 的分析可以参考 Project Zero 近期的文章：A Very Powerful Clipboard: Analysis of a Samsung in-the-wild exploit chain

call

ContentProvider 中提供了 call 方法，用于实现调用服务端定义方法，其函数签名如下：

public Bundle call (String authority, 
                String method, 
                String arg, 
                Bundle extras)
public Bundle call (String method, 
                String arg, 
                Bundle extras)

默认的实现是个空函数直接返回 null，开发者可以通过覆盖该函数去实现一些动态方法，返回值也会传回到调用者中。

看起来和常规的 RPC 调用类似，但这里有个小陷阱，开发者文档中也特别标注了：Android 系统并没有对 call 函数进行权限检查，因为系统不知道在 call 之中对数据进行了读还是写，因此也就无法根据 Manifest 中定义的权限约束进行判断。因此要求开发者自己对 call 中的逻辑进行权限校验。

如果开发者实现了该方法，但是又未进行校验或者校验不充分，就可能出现越权调用的情况。一个案例是 CVE-2021-23243， OPPO 某系统应用中 HostContentProviderBase 的 call 方法实现中，直接用 DexClassLoader 去加载了传入 dex 文件，直接导致攻击者的代码在特权进程中运行，所有继承该基类的 Provider 都会受到影响。

另外在某些系统 Provider 中，可以通过 call 方法去获取某些远程对象实例，例如在文章 Android 中的特殊攻击面（三）—— 隐蔽的 call 函数 中，作者就通过 SliceProvider 与 KeyguardSliceProvider 获取到了系统应用内部的 PendingIntent 对象，进一步利用实现了伪造任意广播的功能。

其他

除了上述和四大组件直接相关的漏洞，Android 系统中还有许多不太好分类的漏洞，本节主要挑选其中几个最为常见的漏洞进行简单介绍。

PendingIntent

PendingIntent 是对 Intent 的表示，本身并不是 Intent 对象，但是是一个 Parcelable 对象。将该对象传递给其他应用后，其他应用就可以以发送方的身份去执行所指向的 Intent 指定的操作。 PendingIntent 使用下述静态方法之一进行创建：

• getActivity(Context, int, Intent, int);
• getActivities(Context, int, Intent[], int);
• getBroadcast(Context, int, Intent, int);
• getService(Context, int, Intent, int);

PendingIntent 本身只是系统对原始数据描述符的一个引用，可以大致将其理解为 Intent 的指针。也因为如此，即便创建 PendingIntent 的应用关闭后，其他应用仍然可以使用该数据。如果原始应用后来进行了重启并以同样的参数创建了一个 PendingIntent，那么实际上返回 PendingIntent 与之前创建的会指向同样的 token。注意判断 Intent 是否相同是使用 filterEquals 方法，其中会判断 action，data， type，identity，class，categories 是否相同，注意 extra 并不在此列，因此仅有 extra 不同的 Intent 也会被认为是相等的。

由于 PendingIntent 可代表其他应用的特性，在某些场景下可能被用于滥用。例如，如果开发者创建了这样一个默认的 PendingIntent 并传递给其他应用：

pi = PendingIntent.getActivity(this, 0, new Intent(), 0);
bundle.putParcelable("pi", pi)
// send bundle

恶意的应用在收到此 PendingIntent 后，可以获取到原始的 intent，并使用 Intent.fillin 去填充空字段，如果原始 Intent 是上述空 Intent，那么攻击者就可以将其修改为特定的 Intent，从而以目标的身份去启动应用，包括未导出的私有应用。一个经典的案例就是早期的 broadAnywhere 漏洞，Android Settings 应用中的 addAccount 方法内创建了一个 PendingIntent 广播，但 intent 内容为空，这导致收到 intent 的的恶意应用可以 fillin 填充广播的 action，从而实现越权发送系统广播，实现伪造短信、回复出厂设置等功能。

为了缓解这类问题，Andorid 中对 Intent.fillin 的改写做了诸多限制，比如已有的字段不能修改，component 和 selector 字段不能修改（除非额外设置 FILL_IN_COMPONENT/SELECTOR），隐式 Intent 的 action 不能修改等。

不过有研究者提出了针对隐式 Intent 的利用方法，即通过修改 flag 添加 FLAG_GRANT_WRITE_URI_PERMISSION，并修改 data 的 URI 指向受害者私有的 Provider，将 package 改为攻击者；同时攻击者在自身的 Activity 中声明相同的 intent filter，这样在转发 intent 时会启动攻击者应用，同时也获取了目标私有 Provider 的访问权限，从而实现私有文件窃取或者覆盖。关于该攻击思路详情可以阅读下面的参考文章。

• broadAnywhere：Broadcast组件权限绕过漏洞（Bug: 17356824）
• PendingIntent重定向：一种针对安卓系统和流行App的通用提权方法——BlackHat EU 2021议题详解（上）
• PendingIntent重定向：一种针对安卓系统和流行App的通用提权方法——BlackHat EU 2021议题详解（下）

在 Android 12+ 之后，PendingIntent 在创建时候要求显式指定 FLAG_MUTABLE 或者 FLAG_IMMUTABLE，表示是否可以修改。

DeepLink

在大部分操作系统中都有 deeplink 的概念，即通过自定义 schema 打开特定的应用。比如通过点击 https://evilpan.com/ 可以唤起默认浏览器打开目标网页，点击 tel://10086 会唤起拨号界面，点击 weixin://qr/xxx 会唤起微信，等等。其他系统暂且不论，在 Android 中这主要是通过隐式 Intent 去实现的。

应用要想注册类似的自定义协议，需要在应用清单文件中进行声明：

<intent-filter>
  <action android:name="android.intent.action.VIEW"/>
  <category android:name="android.intent.category.DEFAULT"/>
  <category android:name="android.intent.category.BROWSABLE"/>
<data android:scheme="weixin" android:host="qr"/>
</intent-filter>

由于这类隐式 Intent 可以直接通过点击链接去触发，因此更受攻击者喜爱。如果处理对应 Intent 的组件没有过滤好用户传入的内容，很可能会造成 1-click 的漏洞。相关案例可以参考文章：Android 中的特殊攻击面（二）——危险的deeplink

Webview

在 Andorid 系统中，Webview 主要用于应用在自身的 Activty 中展示网页内容，并提供了一些额外的接口来给开发者实现自定义的控制。更高的拓展性也就意味着更多出错的可能，尤其是如今 Android 客户端开发式微，Java 开发也朝着 “大前端” 的方向发展。原本许多使用原生应用实现的逻辑逐渐转移到了 web 页面中，比如 h5、小程序等，这样一来，webview 的攻击面也就扩宽了不少。

常规的 Webview 安全问题主要是在与一些配置的不安全，比如覆盖 onReceivedSslError 忽略 SSL 错误导致中间人攻击，setAllowFileAccessFromFileURLs 导致本地私有文件泄露等。但现在的漏洞更多出在 JSBridge 上，这是 Java 代码与网页中的 JavaScript 代码沟通的桥梁。

由于 Webview 或者说 JS 引擎的沙箱特性，网页中的 Javascript 代码本身无法执行许多原生应用才能执行的操作，比如无法从 Javascript 中发送广播，无法访问应用文件等。而由于业务的复杂性，很多逻辑又必须在 Java 层甚至是 Native 层才能实现，因此这就需要用到 JSBridage。传统的 JSBridge 通过 Webview.addJavascriptInterface 实现，一个简单示例如下：

class JsObject {
    @JavascriptInterface
    public String toString() { return "injectedObject"; }
}
webview.getSettings().setJavaScriptEnabled(true);
webView.addJavascriptInterface(new JsObject(), "injectedObject");
webView.loadData("", "text/html", null);
webView.loadUrl("javascript:alert(injectedObject.toString())");

Java 层返回数据给 Javascript 一般是通过直接使用 loadUrl 执行 JS 代码实现。当然除了这种方式注册 Bridge，还有很多应用特异的实现，比如使用 console.log 传输数据并在 Java 层使用 onConsoleMessage 回调去接收。但无论如何，这都导致攻击面的增加，大型应用甚至注册了上百个 jsapi 来供网页调用。

从历史漏洞来看，Webview 漏洞的成因主要是 jsapi 域名校验问题和 Bridge 代码本身的漏洞，由于篇幅原因就不展开了。

后记

本文中主要通过 Android 中的四大组件介绍了一系列相关的逻辑问题，尽可能地囊括了笔者所了解的历史漏洞。由于个人认知水平有限，总是难免挂一漏万，但即便如此，文章的篇幅还是比预想中的超出了亿点点。从温故知新的角度看，挖掘这类逻辑漏洞最好的策略还是使用静态分析工具，搜集更多 Sink 模式并编写有效的规则去进行扫描，实在没有条件的话用 (rip)grep 也是可以的。

参考资料

• Galaxy Leapfrogging 盖乐世蛙跳 Pwning the Galaxy S8
• Chainspotting: Building Exploit Chains with Logic Bugs (如何用11个exp攻破三星S8)
• Huawei Mate 9 Pro Mobile Pwn2Own 2017
• Detect dangerous vulnerabilities in the TikTok Android app - Oversecured
• 魔形女漏洞白皮书 - 京东探索研究院信息安全实验室
• HACKING XIAOMI’S ANDROID APPS - Part1
• Automating Pwn2Own with Jandroid

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

但是本文不谈阿里，也不谈企业文化，只是借此为引申谈谈最近在代码审计过程中的一些额外感想。

点

许多新手安全研究员在代码审计的时候喜欢盯着一些单点去看问题，比如一些敏感函数的调用或者特定的代码模式。在 C/C++ 中是通过分析 system、execve、popen 等调用去查找命令注入，通过 gets、scanf、strcpy 等查找缓冲区溢出，通过 printf 查找格式化字符串漏洞等；在 PHP 中则是通过 eval、popen、passthru 等危险函数去寻找 RCE，……

这种代码审计方法可以归类于之前文章中所说的“自底向上”方法，简单但是有效，往往能很快找到一些 “Low Hanging Fruit”。但是缺点也很明显，这些单点漏洞很容易被静态分析工具检测出来，甚至一个简单的正则表达式都可以轻易匹配到，人工审计在其中的竞争力不大；另外从单点上看往往会忽略上下文信息，造成无效的审计。

线

如果说单点审计是 Sink，那么进一步就是将可控输入源与故障点结合起来的 Source+Sink 审计方法。两点连成一线，从外部输入到危险函数的过程连接中可以发现真正存在的漏洞。比如从 Web 请求参数、请求头到最终的命令注入或者 JNDI 注入、开放性反序列化。

在线性的审计过程中，审计者需要重点关注的是数据流和控制流。目前许多高级的静态分析工具可以借助编译器或者解释器去实现代码抽象语法树的数据化，在结构化代码节点和边的情况下去使用特定规则进行搜索和查询，从而辅助对调用流图的分析。当然这类工具也有一定的局限性，比如对于 OOP 多态调用和底层语言的指针操作会存在一些误报和漏报，对于过深的调用链路在搜索过程中也会出现路径爆炸的情况。因此通常还是需要在工具的基础上借助专家经验进行进一步的约束优化以及必要的人工审计验证。

面

从点到线，已经实现了漏洞挖掘能力的一大提升，但在很多人眼里却只是入门。究其原因是这种方法往往只能找到一些中小型软件或者冷门框架的简单漏洞，而对于当前的一些复杂的代码项目，往往在设计之初或者迭代过程中对一些危险函数进行了严格的评估，很难在这些项目中找到格式化字符串漏洞或者命令注入了。

在这种情况下，审计者其实需要退一步从更大的方面上考虑，这里的面也可以理解为 “攻击面”。漏洞之所以称之为漏洞，是因为系统接受了非预期的数据、产生了非预期的行为，从而造成系统稳定性、完整性甚至用户数据隐私泄露的影响。从最终影响去反推可能造成危害的因素，对特定系统进行威胁建模，一方面可以保证目标的审计覆盖度，另一方面也可以在全面分析的过程中发现一些意料之外的边界情况。

曾经栈溢出只是一个讨厌的 segment fault，直到 1996 年有人在 Phrack 杂志中发表了一篇著名的文章 Smashing The Stack For Fun And Profit，从此拉开了二进制漏洞利用的黄金时代，极客与黑客席卷全球。从这个角度看，攻击面并不是一成不变的，而第一个发现新攻击面的人通常也是安全领域的个中翘楚。发现新攻击面的门槛看似很高，但实际上我们可以聚焦在某个软件或者其中的某个子系统中去实现属于自己的微创新。

体

达到攻击面的覆盖其实已经是一个优秀的安全工程师了，但在目前代码审计的过程中其实是“缺心眼儿”的。为什么这么说，因为到目前为止代码审计也只是为了漏洞挖掘而进行，眼里的代码只是一个个类和方法、中间有无数的数据交换，我们的目的只是在其中发现一条不经意裂缝并将其扩大和摧毁(漏洞利用)。用一些活动家的话来说就是，没有做到 “视人为人”。

代码只是算法和数据结构的载体，忽略整体而关注部分的最终结果往往是一叶障目不见泰山。以笔者的审计经验为例，之前在分析 Linux 内核某个网络子系统漏洞的时候，在代码中往复来回跳了半天最终也没找到某个 socket 复制的调用来源，最终还是通过动态调试回溯才找到的调用路径。当时在复盘的时候其实也发现了，如果在分析代码的时候能退后一步考虑整体功能，就可以很容易想到正确的分析方向，因为 socket 的生命周期就是 TCP 握手的生命周期，发生复制的正是在握手成功 accept 系统调用返回的阶段，返回的文件句柄正对应了所创建的客户端套接字。(关于当时的分析记录感兴趣的可以参考 Linux内核代码审计之CVE-2018-9568(WrongZone))

总而言之，代码审计的同时也要跳出代码本身，从功能角度去思考代码开发者这样实现的目的，这样才能在作者的基础上用更高的视野去发现作者本身所忽略的关键要素。

局

如果说“体”表示一个子系统，那么“局”就是整个目标项目本身。软件项目的开发通常是瀑布流自顶向下的，先设计全局架构，然后再划分成不同的子模块，由不同的团队去进行开发和维护。为了各个团队的开发者能够更好地协作，不可避免地会存在一个或者多个架构师的角色，定义各模块的边界，定义整体的编码规范和各自的对接方法。在更多情况下，“安全” 是软件架构中的一个基本功能，因此也由架构师进行统筹规划。

审计大型软件项目时，可能会发现不同的子模块有不同的编码习惯，但是子模块之间又有一些共性，比如使用了相同的整数溢出检查方法。在完成若干个子模块的代码审计后，正是一个众观全局的绝佳时机，通过对比不同的子模块，可以知道哪些模块的开发者是偏执狂，在每个偏僻的角落都加上了防御性编程；可以知道哪些模块年久失修，是一个藏污纳垢的好地方，更有可能找出新的漏洞；也可以知道架构师做了哪些安全布局(但偏偏就是有人不听话)，从而找出潜在的遗漏点。

通览全局，从架构师的角度去审视代码，而不仅仅是站在开发者的角度，大概就是 “局” 所表达的含义了。

势

安全行业素有 “态势感知” 一说，用来表示发现未知攻击，以期防患未然，提前防御。而个人理解在代码审计中应该也有对应的境界。所谓 “势”，就是举一反三、一叶知秋，不仅仅是一个项目代码中的问题，而是在相关行业中普遍存在。

以 SSRF 漏洞为例，大家都知道是服务器对客户端指定 URL 校验不严格导致的请求伪造问题，一般只是分析校验的实现或者黑盒测试，漏洞报告总是 case by case。但某安全研究员就通过对 URI RFC 的深入研究和对不同 Parser 的分析，批量总结出了当今常用语言的 URL 解析所存在的漏洞，发现了行业性的问题。

出自 A New Era of SSRF - Exploiting URL Parser in Trending Programming Languages

大概就是这样吧，我编不下去了。

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

前言

对于许多安全研究人员而言，Fuzzing 是一个重要的漏洞挖掘方法，但每个方法都有其局限性。首先，为了有效地进行 Fuzz，需要准确找到攻击面并在此基础上进行自动化测试，寻找攻击面的过程离不开代码审计；其次，在自动化测试找到 crash 之后，分析和写报告的过程需要人工审计理解代码逻辑和漏洞的 root cause；最后，对于 Java 或者 Go 这类内存安全的语言而言，Fuzzing 的应用场景更是受限，只能通过代码审计去发现复杂的逻辑设计问题。

本文算是对代码审计的一个方法论式的总结，对具体代码的所属语言并无限制，可以是 C/C++，也可以是 Java、PHP。对于具体语言所独有的 Source、Sink 以及自动化分析辅助工具不在本文范围，感兴趣的朋友可以关注后续的代码安全审计之术篇。

谋定而后动

孙子兵法有云: 谋定而后动。在现代管理学中也有一句名言: “If you can’t measure it, you can’t manage it.”

可见凡事在开始之前，都需要先确定好自己的目标和计划，这样才能确保自己不会偏离方向或者误入歧途。 对于安全审计亦是如此。工作时经常会发现一些同事一头扎进某个项目的代码中，眨眼就是几个月，一问进展如何不知，还有多久不知，有何计划也不知，代码审计全凭感觉，有无收获全靠运气。……

为了避免这种情况，在开始前我们不妨先问一下自己的目标是什么。这乍看起来是个很简单的问题，但对于不同的场景可能有不同的回答。通常安全研究人员的目标是在最短的时间内找到最有价值的漏洞；对于商业安全顾问而言，其目标是在项目预算允许的范围内尽可能达到更高的审计覆盖率；另外对于开发者或者安全架构师而言，则会花费更长的时间周期进行内部安全评审。

对于商业环境中的代码安全审计，通常甲方更关心的是容易检测的安全问题，而不甚考虑其复杂性和技术难度。因为他们的目标是避免漏洞被公开或者利用造成负面舆情影响。如果此时你将时间都花在了某些复杂问题中而忽略了浅显的漏洞，那显然是拿不到甲方好评的。将时间花费在没有 “技术含量” 的简单漏洞中对于很多安全从业人员而言似乎有点羞耻，但却是一个合理的商业决定。

这并不是说我们应该忽略复杂的安全问题而只去看简单的漏洞，关键是要提前明确自己的审计目标。对于一项审计任务要分成两面看，一面是审计人员自己的时间投入成本，另一面是待审计应用的复杂度。二者结合起来才能有效评估此次审计的产出预期。

待审计应用根据访问权限划分一般有以下几种情况:

• 仅源码: 我们仅拥有目标的源代码，通常不包含完整的编译和测试环境，而且由于缺乏必须的关键依赖组件，往往无法构建出可运行的程序。这种情况一般只能使用静态分析的方式去进行审计；
• 仅二进制程序: 我们仅拥有目标应用的二进制文件，比如 APK、EXE、jar 包或者 IoT 的系统固件等。这种情况下通常通过动态分析以及逆向工程的方式进行审计；
• 有源码及二进制程序: 我们既能够访问目标应用的源代码，也拥有一个可运行的二进制程序，这给安全审计提供了最为有利的访问权限，通常目标是开源软件，包含了完整的构建环境和依赖。
• 完全黑盒: 我们既没有目标的源代码，也没有可运行的二进制程序，因此只能通过外部接口去进行盲测。这在 Web 应用中较为常见。

本文主要针对的是有源码情况下的代码安全审计，当然源码审计中使用的一些策略和方法同样适用于其他类型的应用。在能够访问源码的情况下，一个明显的计量标准是通过代码行数去评估工作量，尽管这个指标并不能完美代表应用的复杂度，毕竟 1000 行业务代码和 1000 行编译器代码的复杂性是不同的。

一个代码审计人员一个小时大概可以审计 100 行到 1000 行代码不等，取决于该审计人员的经验能力和对代码的理解程度。对于个人而言，评估审计效率的最好方式就是坚持记录自己对不同组件的审计时间，这既能更好的了解自己的节奏，也能为后续代码审计计划提供时间参考。

影响代码审计速度的原因有很多，比如:

• 代码语言: 对于 C/C++ 这种内存不安全的语言需要更多关注底层细节；而 Java、Python 等内存安全的语言则更多关注上层逻辑实现；
• 代码风格: 代码风格整洁、注释清晰的项目通常比其他项目花费更少时间去审计；

值得一提的是，虽然代码量和审计时间有正相关的关系，但随着对某个项目的审计代码量增加，审计的效率也会提高，因为此时已经对项目有了更加深入的理解，审计十万行代码的时间通常也不会是五万行代码的两倍。因此在制定审计计划和时间投入时，需要仔细考虑上述相关因素。

知止而有得

在一个完美的代码安全审计项目中，每个模块的每一行代码都会被尽可能彻底的评估，但这个目标在现实世界中几乎是不可行的。时间和预算的限制会迫使你忽略一些代码模块，或者对每个模块的审计深度和覆盖率做出取舍。因此我们需要通过不断练习来提高自身敏感度，在屡次的失败或成功中吸取教训，作为下一次取舍和抉择的养料和经验。

在下节中将会介绍一些具体的代码安全审计的策略和技巧。在实践中也许某些方法比另外一些方法要高效，但经验告诉我们最好还是使用多种审计策略，并周期性的切换审计方法，这有多种原因:

• 你只能在有限的时间内保持精神高度集中；
• 多样性能帮助你保持纪律和激情；
• 不同的漏洞类型在其他视角下可能更容易被发现；
• 不同的人拥有不同的思考方式；
• ……

从全局来看，代码安全审计的方法是一个简单的三步循环流程:

1. Plan: 审计规划，根据现有信息，确定这一阶段要使用的代码审计策略，以及审计的小目标，比如完成某个模块或者文件(目录)的审计、了解某个结构体的功能等；
2. Work: 执行审计，根据前面制定的审计策略去执行，重点是做好这一过程中的审计记录；
3. Reflect: 审计回顾，在完成该阶段审计后，反思一下自己在这一阶段是否有效利用时间，是否偏离了方向。然后根据前面审计学习到的经验去调整下一阶段的审计规划，比如重新划分结构、专注于安全相关的子模块等；

在实践中，每天大概会经历两到三次上述审计循环。在制定审计规划的时候，我们需要尽可能利用现有的信息，比如开发文档、接口文档等资料；在没有文档的情况下，就只能通过不断的审计循环去推断出代码设计结构。在审计初期也许会觉得狗啃泰山无从下口，一叶障目不见森林；但到了审计后期时走进代码就会像走进自己家一样，知道哪个模块的开发者刚刚学习了设计模式想要秀一秀技巧，知道哪些代码已经经过激烈的攻防对抗，做了许多防御性编程，也知道了哪些代码是上古屎山，为开发者避而远之。……

因此，往往我们在代码审计初期可以找到一些简单的安全问题，而在后期随着对应用的理解深入，可以发现更为复杂的逻辑漏洞，甚至设计上的缺陷。

万物皆有法

本节介绍一些具体的代码审计策略。如果说代码审计是一场战争，那么必然要讲究战略和战术。这也许只是前人的经验之谈，但确实是一种行之有效的方法论。

代码审计策略有多种，但是每每种策略都类似的属性，代表这种策略的特征。例如:

• 起点: 代码跟踪的起点；
• 终点: 该策略的目标，或者跟踪代码的终止点；
• 方法: 代码跟踪方法，跟踪数据流、控制流，跟踪方向是前向跟踪还是反向跟踪；
• 目标: 该审计策略所针对的是什么类型的漏洞；
• 难度: 表示该审计策略的执行难度，一般从 1 星到 5 星表示难度递增；
• 速度: 表示该审计策略的执行速度，也是从 1 星到 5 星表示从慢到快；
• 理解: 表示该审计策略所带来的代码理解。通常能带来更多理解的策略难度都会更大一些，但同时也能帮助研究人员发现更加复杂的漏洞；

还有对应优缺点等，下面是一些具体的审计策略。

策略一: 自顶向下

第一种代码审计策略就是通过直接分析代码去挖掘漏洞，这种方式通常要阅读代码并理解代码，需要更加集中注意力，但同时也带来对代码更加深入的理解。当然正面交锋也不是抡起膀子就干，可以进一步细分为以下执行策略。

数据分析

首先是数据流分析，通过跟踪用户的(恶意)输入数据去找到潜在的漏洞点。

数据分析可能是大部分人所认为的代码审计方法，其核心是从恶意输入为起点，在代码中通过控制流进行前向审计，通常辅以有限的数据流分析。在审计过程中通过记录一系列传播的数据并进行跟踪，并配合安全边界分析和常用的漏洞类型去定位漏洞。

该方法是分析代码的有效方法，但是需要一些额外的经验用于判断应该跟进哪些模块和函数，否则路径会在短时间内分支爆炸。而且在一段时间的审计很容易走神并错失一些重要分支，然后和漏洞擦肩而过。

在面对类似于 Java 或者 C++ 等语言的项目时候，数据分析方法往往更加困难，因为通常跟踪原始输入会经过多个中间类，导致你打开了十几个文件之后还没有到达真正处理数据的代码。在这种情况下最好有设计文档的帮助，用以构建相对完备的威胁模型，否则最好还是先采用其他策略去理解系统。

模块分析

模块分析的一个隐含假设是代码模块以文件进行划分，因此实际上分析一个模块就是分析对应的源文件。

模块分析的过程基本上就是从头到尾阅读一个源码文件，并且不跟踪其中调用到的外部函数，也不关心当前函数的引用情况，只将目前遇到的问题记录下来。也许你会觉得这个策略比较粗暴，但实际上许多资深的代码审计人员都很喜欢这种方法。比如前 NSA 的某安全顾问在审计新的代码仓库时都会先使用该策略，找到类似 util 的工具目录并逐行阅读其中的胶水代码，以对该项目的代码风格形成初步了解。

模块分析的优点是快速了解应用的的代码风格，对于高内聚的模块分析可以不走出文件，可以对模块内部实现有个初步理解。但缺点也很明显，这种分析方法比较费力，而且在长时间的持续分析后大脑很容易感到疲劳；另外在审计过程中记录所有的潜在问题也是个繁琐的工作，在若干小时的记录后很难有激情去继续坚持下去。因此，如果在执行此策略的过程中感到精神涣散的话，最好先休息一下，或者切换到其他不那么紧张的审计策略中。

引用分析

引用分析和模块分析类似，主要区别在于我们聚焦的是面向对象代码中的类或者结构体实现。

对于面向对象的语言来说，该审计策略比单纯的模块分析要更为高效，因为往往对象本身是高内聚的。同时该分析过程也更不容易导致审计过程中出现方向偏离。但是和模块分析的特点一样，在审计过程中我们同样需要保持注意力集中，不然也可能会出现漏看的情况。

算法分析

在对应用的系统设计和数据结构有了足够的理解后，我们就可以选择一些安全相关的算法并分析其实现。

这个审计策略的有效性依赖于我们所选算法的的相关性，因此需要在对审计目标有一定理解之后才能确定哪些是关键的算法和代码。这些关键算法通常涉及到应用安全模型的设计或者密码学实现，比如 Web 应用中的 sessionId 实现算法或者应用开发者自定义的加密校验算法等。

策略二: 自底向上

这一大类策略和上述的正面策略正好相反，主要从可能导致漏洞的底层代码着手。这类策略通常会使用一些自动化分析工具作为辅助，然后反向追踪去验证漏洞的触发路径。

敏感调用

指定一系列的敏感调用，反向分析这些调用是否构成可利用的漏洞。最简单的方式是通过正则表达式去指定敏感函数或者语句，通过文本搜索工具去查找潜在漏洞并进行验证。

这个策略的优点是针对已知的漏洞类型可以达到较高的覆盖率，比如格式化字符串、命令注入等；而且该审计方法不是非常掉 san，可以有效节省和恢复注意力，由于漏洞列表的存在也不容易走偏，也可以稳步推进审计工作。

漏扫工具

除了手动指定敏感调用，我们还可以通过自动化静态分析工具去获取潜在漏洞点，比如 Sonar、Fortify 等都有较为完善的漏洞分类列表。

该策略的分析和敏感调用分析过程类似，早期的静态分析工具只是简单的文本匹配，但当前已经有许多静态分析工具可以进行比较精确的数据流和上下文分析，有的需要依赖完整构建环境支持，比如 CodeQL，有的则可以在仅有源码的情况下进行分析，比如 weggli、semgrep 等。

这类静态分析工具的一大弊端是通常存在误报，如果在一千个扫描结果中只有几个是真正的漏洞，那么它们也往往很容易会被安全审计人员忽略。

接口分析

有时候漏洞并不单独产生在敏感的函数调用中，而是实现在某个类或者应用函数的代码中，比如一些命令执行中间函数或者 ORM 的数据库封装接口。

有部分自动化分析工具可以编写自定义规则去进行扫描，但更多情况下只需要一个简单的 grep/findstr 命令就可以实现漏洞点查找和过滤。该方法需要对待审计代码有一定程度的理解才能知道哪些是潜在的安全敏感函数，而且由于我们只是不断在一个浅层的上下文中进行搜索跳转，所以这种审计策略只能帮助我们验证漏洞路径，对代码的理解几乎没有更多帮助。

除了针对源码的分析，对于二进制应用的逆向分析我们也可以运用类似的策略，在汇编代码中定位潜在的漏洞模式。比如对于 x86 的程序可以通过 MOVSX 指令去搜索潜在的整数溢出漏洞等，当然这是题外话了。

策略三: 见微知著

在我们经过前两类策略的审计后，已经对代码本身有了一定程度的理解，这时候就可以后退一步，纵观全局去审计应用整体的设计和实现。这类策略主要关注关注上层的设计缺陷逻辑问题，因此往往可以找到隐藏较深的严重漏洞。

系统建模

一般开发的过程是先完成顶层设计和排期，然后再分模块去进行具体编码实现。但对于安全审计而言这个过程可以反过来，即完成具体实现的分析后再反向推断整体的的设计思路，然后根据这个推测的思路去找到一些未曾触及的组件实现。

如果想要对目标系统有更加深入的理解，那么该审计策略是一个极好的选择；但同时这也表示该方法的审计速度不会太快，因为基本上我们是从实现细节开始逆向还原出原始的设计架构。

值得一提的是，通常我们只需要对一些核心模块进行反向建模，比如应用的安全子系统、输入过滤模块或者其他广泛使用的核心组件等。在建模的过程中，我们实际上是把自己放在开发者或者架构师的位置去重新考虑模块的设计，因此这也是通过具体代码去挖掘逻辑漏洞的最佳策略。

在面对大型代码时，我们的大脑几乎不可能一次性把整个应用结构消化掉，因此就需要进行减枝。具体做法就是先对待审计代码做出一些猜测的假设，然后在实际测试中验证这些假设。不论假设是否正确，最终都能通过测试去加深自己对该系统的理解和认识。

安全边界

该审计策略的目标是从代码实现去还原开发者或者安全架构师预设的安全边界，从而对还原后安全边界进行进一步审计，构建实际攻击的威胁模型。

一个具体的方法是通过收集整理代码中的安全校验相关代码片段进行记录，然后对这些针对安全边界的检查进行分类整理，最后归纳出原始的安全层级划分。这些原始的安全验证是我们对应用安全边界建模的重要信息来源，该策略的优点是可以让我们专注于安全相关的代码区域，并且构建更为完整的设计架构。

设计验证

如果我们手中有目标应用的设计文档或者规范手册，那么一个直观的审计策略就是通过对比规范和实现代码来查找其中的未定义行为或者冲突之处。

虽然大部分时候我们并没有那么详细的文档，但同样可以使用该策略来发现一些设计实现中的漏洞。通过重点关注代码实现中的灰色地带，或者说一些条件分支的临界处理，我们也可以大致推断出哪些是文档中所未定义的行为。简单来说，我们的目标是先推测和还原目标模块的主要功能和正常行为，然后再针对其中的临界情况进行重点审计。

审计技巧

前面已经介绍了代码安全审计常见的一些策略，主要用于为代码审计提供大致的战略方向。本节主要介绍一些实际代码审计工作中用到的小技巧，作为上述代码审计策略的补充。

阅读顺序

在审计某个模块代码时，我们可以通过跟踪数据流或者跟踪控制流的方式去阅读，那么那种方法比较好呢？答案是既不关心数据流也不关心控制流，而是只关注本模块的实现。因为多年的经验告诉我们，精神力是影响代码审计效率的重要原因，而在不同模块中来回跳转往往形成了精神的消耗。比如在某些复杂的项目代码中，查找某个函数的实现会不断地打开新文件，从而不断地涌出需要解决的新问题，在不断追踪的过程中，往往会迷失在好奇的海洋中，从而忘记了原来的审计任务。

如果确实要打破砂锅问到底，那么也建议在审计记录上先做个标记，等完成当前模块的审计后再对其进行深入分析。

故地重游

叔本华曾经说过，重要的书都应该连着读两遍。因为第二遍读的时候，你已经知道结局了，这样才能真正理解开头。另一个原因是第二遍阅读时，你有不一样的心情，可能会从另一种角度看待问题。

代码审计亦是如此，通常对于一段代码我们通常需要阅读多次才能找到其中所有类型的漏洞。比如在第一遍审计中，可能主要关心整数溢出、内存管理或者格式化字符串相关的安全漏洞；而第二遍的审计则主要关心功能性的实现，比如返回值检查和一些容易理解错误的 API 调用(如 strncpy、strlcpy)；第三遍则主要关心线程间潜在的同步、竞争问题或者 TOCTOU 的资源访问管理，……诸如此类。

没有一个标准说对于某段代码应该审计阅读多少遍，具体情况需要根据代码具体的运行上下文进行判断，比如对于单线程代码就不需要关心线程同步问题了。但是无论如何，对于关键代码至少也要阅读两次，因为如果只看一次过的话很容易遗漏重要的代码路径。

审计笔记

在审计过程中是否要记录笔记其实因人而异，但是经验表明坚持记录大有裨益。

审计审计，审而不计则罔，计而不审则殆。结构化的笔记一方面可以帮助自己评估代码审计覆盖率，沉淀审计心得；另一方面也可以方便以后继续深入审计时可以快速回顾之前的工作。此外，不论作为打工人还是独立安全顾问，我们都需要对老板或甲方输出审计报告或者漏洞报告，这些资料就是重要的数据来源。

想法列表

我们可能在代码审计过程中会出现很多想法，比如在审计某个状态机时会想到可能引入一些异常的状态切换导致处理异常，或者某些用户可控的数据进入了其他模块的分支中可能导致对应模块校验出错等等。这些想法在审计过程中无法逐一去验证，否则就偏离了初始的审计规划。因此，我们还需要维护一个潜在漏洞列表，记录上述想法，表示系统中”可能“出现漏洞或者被攻击者利用的点。这个列表不需要非常详细，可能只是一个猜测或者灵感。将其记录下来之后可以等到后续有时间继续深入分析和验证，这样既能保证审计工作有序推进，也能保证自己的想法不被遗忘。

总结

代码安全审计的前期重点之一是评估自己的审计速度(知己)和代码量和复杂度(知彼)，这样才能让自己的审计工作可量化、可管理，从而稳步推进审计进度；在代码审计过程中，使用三步循环流程不断增加审计覆盖率以及提高自己对代码结构的理解，在每一阶段的审计后，要及时记录所得所想，让工作落到实处。同时在此过程中也需要适时切换审计策略，合理使用和回复自己有限的注意力和意志力。

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

这次选的漏洞是CVE-2018-5703，是syzcaller扫出来的，漏洞报告见： https://groups.google.com/forum/#!msg/syzkaller-bugs/0PBeVnSzfqQ/5eXAlM46BQAJ

已知信息

1. Linux master分支，crash的commit为 61233580f1f33c50e159c50e24d80ffd2ba2e06b
2. 漏洞出在tcp_v6_syn_recv_sock函数
3. 漏洞类型为slab out-of-bound write (实际上是类型混淆)
4. 和tls相关

分析

tcp_v6_syn_recv_sock这个函数是定义在虚函数表的syn_recv_sock:

static const struct inet_connection_sock_af_ops ipv6_specific = {
  .queue_xmit    = inet6_csk_xmit,
  .send_check    = tcp_v6_send_check,
  .rebuild_header    = inet6_sk_rebuild_header,
  .sk_rx_dst_set     = inet6_sk_rx_dst_set,
  .conn_request      = tcp_v6_conn_request,
  .syn_recv_sock     = tcp_v6_syn_recv_sock,
  .net_header_len    = sizeof(struct ipv6hdr),
  .net_frag_header_len = sizeof(struct frag_hdr),
  .setsockopt    = ipv6_setsockopt,
  .getsockopt    = ipv6_getsockopt,
  .addr2sockaddr     = inet6_csk_addr2sockaddr,
  .sockaddr_len      = sizeof(struct sockaddr_in6),

  .compat_setsockopt = compat_ipv6_setsockopt,
  .compat_getsockopt = compat_ipv6_getsockopt,

  .mtu_reduced       = tcp_v6_mtu_reduced,
};

类似的虚函数表在分析上一个漏洞的时候有见过，调用的链路如下:

► f 0 c025b1b8 sk_clone_lock
   f 1 c02b1278 inet_csk_clone_lock+16
   f 2 c02c561c tcp_create_openreq_child+24
   f 3 c02c2574 tcp_v4_syn_recv_sock+48
   f 4 c02c5c08 tcp_check_req+696
   f 5 c02c28a4 tcp_v4_do_rcv+360
   f 6 c02c28a4 tcp_v4_do_rcv+360
   f 7 c02c4d84 tcp_v4_rcv+1736
   f 8 c02a72ac ip_local_deliver_finish+284
   f 9 c0265c10 __netif_receive_skb+940
   f 10 c0265cd8 process_backlog+112

首先需要理解什么时候会调用到syn_recv_sock，那就需要了解ops虚函数表的作用，connection_sock_af_ops定义在include/net/inet_connection_sock.h:

 /*
   * Pointers to address related TCP functions
   * (i.e. things that depend on the address family)
   */
  struct inet_connection_sock_af_ops

如注释所说，包含地址（Address Family）相关的TCP函数，connection sock表示带连接的sock，定义如下：

/** inet_connection_sock - INET connection oriented sock
*
* @icsk_accept_queue:     FIFO of established children
* @icsk_bind_hash:    Bind node
* @icsk_timeout:      Timeout
* @icsk_retransmit_timer: Resend (no ack)
* @icsk_rto:          Retransmit timeout
* @icsk_pmtu_cookie       Last pmtu seen by socket
* @icsk_ca_ops        Pluggable congestion control hook
* @icsk_af_ops        Operations which are AF_INET{4,6} specific
* @icsk_ulp_ops       Pluggable ULP control hook
* @icsk_ulp_data      ULP private data
* @icsk_ca_state:     Congestion control state
* @icsk_retransmits:      Number of unrecovered [RTO] timeouts
* @icsk_pending:      Scheduled timer event
* @icsk_backoff:      Backoff
* @icsk_syn_retries:      Number of allowed SYN (or equivalent) retries
* @icsk_probes_out:       unanswered 0 window probes
* @icsk_ext_hdr_len:      Network protocol overhead (IP/IPv6 options)
* @icsk_ack:          Delayed ACK control data
* @icsk_mtup;         MTU probing control data
*/
struct inet_connection_sock;

例如，TCP sock就内联了connection sock作为第一个元素，所以tcp_sock指针可以转换成inet_connection_sock指针而没有任何副作用。

struct tcp_sock {
  /* inet_connection_sock has to be the first member of tcp_sock */
  struct inet_connection_sock inet_conn;
  u16 tcp_header_len; /* Bytes of tcp header to send      */
  // ...
}

tcp_v6_syn_recv_sock

既然漏洞出在这个函数，我们就需要先了解这个函数实现的功能。由于其是connection sock的函数，且字段为syn_recv_sock，因此有理由猜测这是TCP协议中接收SYN报文的回调函数。根据TCP协议的状态机，SYN报文会在两种状态下转换，分别是：

1. LISTEN状态，Passive Open，接收到SYN，返回SYN+ACK，状态转换成SYN-RECEIVED
2. SYN-SENT状态，Active Open，接收到SYN+ACK后，再次发送ACK，完成三次握手，进入ESTABLISHED状态

tcp_v6_syn_recv_sock顾名思义也就是IPv6的tcp链接接收到SYN的处理流程，调用堆栈如下：

►f 0 ffffffff847f4090 tcp_v6_syn_recv_sock
   f 1 ffffffff84655422 tcp_get_cookie_sock+258
   f 2 ffffffff84847bdd cookie_v6_check+6013
   f 3 ffffffff847f9d6d tcp_v6_do_rcv+3661
   f 4 ffffffff847f9d6d tcp_v6_do_rcv+3661
   f 5 ffffffff847fc73e tcp_v6_rcv+8942
   f 6 ffffffff8472c76f ip6_input_finish+879
   f 7 ffffffff8472dbe9 ip6_input+233
   f 8 ffffffff8472dbe9 ip6_input+233
   f 9 ffffffff8472be09 ip6_rcv_finish+425
   f 10 ffffffff8472be09 ip6_rcv_finish+425

虽然有实现的大致文档，但是关于函数细节的文档通常是没有的，所以，RTFSC！函数原型：

static struct sock *tcp_v6_syn_recv_sock(const struct sock *sk, struct sk_buff *skb,
                   struct request_sock *req,
                   struct dst_entry *dst,
                   struct request_sock *req_unhash,
                   bool *own_req)

request_sock包含了一次连接请求所需要的信息：

首先检查协议是不是IP协议，如果是的话表示当前地址是IPv4-to-IPv6的地址，转换成IPv4地址后按照IPv4处理：

  if (skb->protocol == htons(ETH_P_IP)) {
      /*
       *  v6 mapped
       */

      newsk = tcp_v4_syn_recv_sock(sk, skb, req, dst,
                       req_unhash, own_req);
      // ...
  }

如果是正常的IPv6协议，则走ipv6的处理流程:

newsk = tcp_create_openreq_child(sk, req, skb);

在分析WrongZone漏洞的时候也看到过类似的流程，TCP连接建立会创建新的sock对象newsk，所以用户空间accept在收到新连接时会返回对应newsk的文件描述符。

又类型混淆？

回忆一下WrongZone中的类型混淆漏洞，是由于在运行过程中ipv6 sk的sk_prot被修改了，而新建的sock所使用的slab依赖于sk->sk_prot->slab，从而导致克隆的实际上是修改过类型的sock，与原始sk类型不一致(sk->sk_prot_creator)，导致类型混淆。

那么这里是否也是同样的问题呢？其实在翻漏洞报告的时候不小心瞄到了一句话：

tls_init() changes sk->sk_prot from IPv6 to IPv4, which leads to this bug.

修改sk->sk_prot从IPv6改为IPv4，效果和IPV6_ADDRFORM一样！后者的实现：

if (sk->sk_protocol == IPPROTO_TCP) {
                  struct inet_connection_sock *icsk = inet_csk(sk);
                  local_bh_disable();
                  sock_prot_inuse_add(net, sk->sk_prot, -1);
                  sock_prot_inuse_add(net, &tcp_prot, 1);
                  local_bh_enable();
                  sk->sk_prot = &tcp_prot; // **BOOM**
                  icsk->icsk_af_ops = &ipv4_specific;
                  sk->sk_socket->ops = &inet_stream_ops;
                  sk->sk_family = PF_INET;
                  tcp_sync_mss(sk, icsk->icsk_pmtu_cookie);
              }

tls_init的实现：

// net/tls/tls_main.c

static inline void update_sk_prot(struct sock *sk, struct tls_context *ctx)
{
  sk->sk_prot = &tls_prots[ctx->tx_conf];
}

static int __init tls_register(void)
{
  build_protos(tls_prots, &tcp_prot);

  tcp_register_ulp(&tcp_tls_ulp_ops);

  return 0;
}

所以，newsk其实是从TCPv4 Slab中分配的，KASAN的告警触发在下面代码的memcpy处：

  newtcp6sk = (struct tcp6_sock *)newsk;
  inet_sk(newsk)->pinet6 = &newtcp6sk->inet6;

  newtp = tcp_sk(newsk);
  newinet = inet_sk(newsk);
  newnp = inet6_sk(newsk);

  memcpy(newnp, np, sizeof(struct ipv6_pinfo));

np为inet6_sk(sk)，newnp为inet6_sk(newsk)，inet6_sk定义如下：

static inline struct ipv6_pinfo *inet6_sk(const struct sock *__sk)
{
  return sk_fullsock(__sk) ? inet_sk(__sk)->pinet6 : NULL;
}

tcp6_sock结构：

struct tcp6_sock {
  struct tcp_sock   tcp;
  /* ipv6_pinfo has to be the last member of tcp6_sock, see inet6_sk_generic */
  struct ipv6_pinfo inet6;
};

发现问题了吗？newsk被强制转换成了tcp6_sock，后者的大小如下：

struct tcp6_sock {
        struct tcp_sock            tcp;                  /*     0  2528 */
        /* --- cacheline 39 boundary (2496 bytes) was 32 bytes ago --- */
        struct ipv6_pinfo          inet6;                /*  2528   160 */
        /* --- cacheline 42 boundary (2688 bytes) --- */

        /* size: 2688, cachelines: 42, members: 2 */
};

tcp_sock的slab object_size正好是2528，因此强制转换类型之后inet6部分就越界了。事实上KSAN的报错也是如此：

[   60.682681] The buggy address belongs to the object at ffff880066e4ea80
[   60.682681]  which belongs to the cache TCP of size 2528
[   60.685803] The buggy address is located 0 bytes to the right of
[   60.685803]  2528-byte region [ffff880066e4ea80, ffff880066e4f460)
[   60.689011] The buggy address belongs to the page:
[   60.690323] page:000000002b421986 count:1 mapcount:0 mapping:000000007a7e240e index:0xffff880066e4fffd compound_mapcount: 0
[   60.693179] flags: 0x1fffc0000008100(slab|head)
[   60.694336] raw: 01fffc0000008100 ffff880066e4e000 ffff880066e4fffd 0000000100000003
[   60.696251] raw: ffff88006a4b9348 ffffea0001ab0ca0 ffff8800690afdc0 0000000000000000
[   60.698152] page dumped because: kasan: bad access detected
[   60.699617]
[   60.700021] Memory state around the buggy address:
[   60.701230]  ffff880066e4f300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   60.703039]  ffff880066e4f380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   60.704813] >ffff880066e4f400: 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc
[   60.706484]                                                        ^
[   60.708036]  ffff880066e4f480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   60.709746]  ffff880066e4f500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   60.711449] ==================================================================

TLS

一个还没解释的问题是，内核如何进入到tls_init? 查看堆栈：

 ► f 0 ffffffff8468e1a0 tls_init
   f 1 ffffffff845724e9 tcp_set_ulp+345
   f 2 ffffffff844db4f6 do_tcp_setsockopt.isra+790
   f 3 ffffffff844dd3c0 tcp_setsockopt+176
   f 4 ffffffff842011b5 sock_common_setsockopt+149
   f 5 ffffffff841fc999 sys_setsockopt+393
   f 6 ffffffff841fc999 sys_setsockopt+393
   f 7 ffffffff8524bb11 entry_SYSCALL_64+113

可以看到是通过setsockopt，关于kernel对TLS的支持见文档 https://www.kernel.org/doc/html/latest/networking/tls.html 。简单来说，进入方法就是：

sock = socket(AF_INET, SOCK_STREAM, 0);
setsockopt(sock, SOL_TCP, TCP_ULP, "tls", sizeof("tls"));

patch

该漏洞的修复如下：

commit d91c3e17f75f218022140dee18cf515292184a8f
Author: Ilya Lesokhin <ilyal@mellanox.com>
Date:   Tue Jan 16 15:31:52 2018 +0200

    net/tls: Only attach to sockets in ESTABLISHED state

    Calling accept on a TCP socket with a TLS ulp attached results
    in two sockets that share the same ulp context.
    The ulp context is freed while a socket is destroyed, so
    after one of the sockets is released, the second second will
    trigger a use after free when it tries to access the ulp context
    attached to it.
    We restrict the TLS ulp to sockets in ESTABLISHED state
    to prevent the scenario above.

    Fixes: 3c4d7559159b ("tls: kernel TLS support")
    Reported-by: syzbot+904e7cd6c5c741609228@syzkaller.appspotmail.com
    Signed-off-by: Ilya Lesokhin <ilyal@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c
index e07ee3a..7b7a70e 100644
--- a/net/tls/tls_main.c
+++ b/net/tls/tls_main.c
@@ -454,6 +454,15 @@ static int tls_init(struct sock *sk)
        struct tls_context *ctx;
        int rc = 0;

+       /* The TLS ulp is currently supported only for TCP sockets
+        * in ESTABLISHED state.
+        * Supporting sockets in LISTEN state will require us
+        * to modify the accept implementation to clone rather then
+        * share the ulp context.
+        */
+       if (sk->sk_state != TCP_ESTABLISHED)
+               return -ENOTSUPP;
+
        /* allocate tls context */
        ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
        if (!ctx) {

在TLS ULP（upper level protocol）中做了进一步限制，明确指定不支持LISTEN状态的socket设置TLS，虽然是偷懒的做法，但是work。

以史为鉴

说起来这是第二次遇到因为sock的prot类型改变导致的漏洞了，这两个漏洞还是几乎相同时间报出来的。

会不会还存在其他类似的漏洞？简单地grep：

$ egrep "sk->sk_prot = " -nr net/
net/core/sock.c:1530:		sk->sk_prot = sk->sk_prot_creator = prot;
net/ipv6/ipv6_sockglue.c:218:				sk->sk_prot = &tcp_prot;
net/ipv6/ipv6_sockglue.c:232:				sk->sk_prot = prot;
net/tls/tls_main.c:58:	sk->sk_prot = &tls_prots[ctx->tx_conf];

第二行引起了WrongZone漏洞，第四行引起了本文的漏洞，第一行是创建的时候（sk_alloc），第三行呢？同样是在IPV6_ADDRFORM的处理分支中，与WrongZone漏洞并列，在UDP的分支中。

  if (sk->sk_protocol == IPPROTO_TCP) {
      struct inet_connection_sock *icsk = inet_csk(sk);
      local_bh_disable();
      sock_prot_inuse_add(net, sk->sk_prot, -1);
      sock_prot_inuse_add(net, &tcp_prot, 1);
      local_bh_enable();
      sk->sk_prot = &tcp_prot;
      icsk->icsk_af_ops = &ipv4_specific;
      sk->sk_socket->ops = &inet_stream_ops;
      sk->sk_family = PF_INET;
      tcp_sync_mss(sk, icsk->icsk_pmtu_cookie);
  } else {
      struct proto *prot = &udp_prot;

      if (sk->sk_protocol == IPPROTO_UDPLITE)
          prot = &udplite_prot;
      local_bh_disable();
      sock_prot_inuse_add(net, sk->sk_prot, -1);
      sock_prot_inuse_add(net, prot, 1);
      local_bh_enable();
      sk->sk_prot = prot;
      sk->sk_socket->ops = &inet_dgram_ops;
      sk->sk_family = PF_INET;
  }

也就是说TCPv6 UDP的socket也会在运行时变化类型（udpv6_prot <--> udp_prot/udplite_prot），这会导致类似的类型混淆问题吗？ 这需要跟踪UDP sock的整个生命周期，以及所有可能触达的分支。

当然，根据前面两个漏洞的pattern，范围还可以缩小一些。前面两个漏洞都是发生在sock复制的时候sk_prot_creator没变导致的类型混淆。对于TCP而言，克隆发生在inet_csk_clone_lock，csk表示这是针对connection sock的，内部调用的是sk_clone_lock，搜索所有调用处：

$ egrep "\<sk_clone_lock"  -rn --binary-files=without-match net/
net/ipv4/inet_connection_sock.c:781:	struct sock *newsk = sk_clone_lock(sk, priority);
net/ipv4/inet_connection_sock.c:852:	/* sk_clone_lock locked the socket and set refcnt to 2 */
net/core/sock.c:1638: *	sk_clone_lock - clone a socket, and lock its clone
net/core/sock.c:1644:struct sock *sk_clone_lock(const struct sock *sk, const gfp_t priority)
net/core/sock.c:1752:EXPORT_SYMBOL_GPL(sk_clone_lock);

只有inet_csk_clone_lock一处调用，所以可以认为UDP协议是不受同类漏洞影响的。

总结

如果不看报告内容的话，即便知道这是一个类型混淆，一开始是找不到这个漏洞点的，根本原因是不知道内核对于 socket 还支持 tls 的功能，而且 tls 还可以改变内核 sock 的 prot 类型。这个例子也可以看出代码审计并非万能(毕竟这是 syzcaller fuzz 出来的)，但通过审计形成的理解，我们可以通过简单的 grep 找到更多同类的漏洞，比如上面 UDP6 的潜在类型混淆。

虽然这次没有找到真正的漏洞，但要相信这不过是投入产出比的问题，漏洞只是理解系统的副产品，做之前想好自己真正想要的是什么就可以了。

PS:

前言

在很多会议或者文章中，经常能看到大佬分析他们找到的 0day，也有一些原理解释和综述的，但是漏洞挖掘过程，几乎很少有所展现。通常一篇议题的结构就是背景介绍、原理介绍，然后 BOOM 的一下，这里有个漏洞被我发现了，然后是漏洞利用和危害，最后可能秀个视频。对于资深研究人员来说，可以补全自己对某块知识的缺失，但是对于初学者而言，心里一直有个疑问: 没错，这里是漏洞点，但是是怎么想到的？心路历程如何？走了哪些弯路？简而言之，相比于结果，有人更关心的是过程。

漏洞“挖掘”

本文是笔者初学 Linux 内核漏洞时的一篇笔记，遵循(漫谈漏洞挖掘)中提到的学习方法:

1. 寻找历史漏洞通告等公开信息；
2. 根据漏洞标题自己去尝试审计对应子系统看能否找到漏洞；
3. 如果无法找到，再回头看漏洞的细节，思考自己为什么没有能够发现这个问题；
4. 不断重复，直到说服自己漏洞挖掘不过是时间问题，而不是能力问题。

这里选取的是 CVE-2018-9568，即 WrongZone 漏洞。当然这个漏洞的漏洞利用过程更为精妙，阿里的王勇、360、百度 XLab 都有详细的利用介绍，不过这不是本文的主题，我们只关注如何通过代码审计找出这个漏洞。

已知的信息如下:

1. 该漏洞和 socket 有关
2. 该漏洞是 TCP4 和 TCP6 socket 的类型混淆漏洞

根据这些信息尝试自己去找到具体的漏洞点。

入口

一开始真的很难，没有方向，不知道从哪里下手，甚至不知道应该看哪个文件。不过冷静想象就知道了，漏洞要触发还是从用户态进来，所以应该从系统调用开始看。

系统调用的定义为SYSCALL_DEFINEn(name, type, args...)，n是参数的个数，根据socket的定义：

int socket(int domain, int type, int protocol);

推测系统调用定义为：

SYSCALL_DEFINE3(socket, xxx....)

或者直接用正则表达式搜索：

$ egrep "SYSCALL_DEFINE[[:digit:]]" -n -r net/
net/socket.c:1325:SYSCALL_DEFINE3(socket, int, family, int, type, int, protocol)
net/socket.c:1366:SYSCALL_DEFINE4(socketpair, int, family, int, type, int, protocol,
net/socket.c:1447:SYSCALL_DEFINE3(bind, int, fd, struct sockaddr __user *, umyaddr, int, addrlen)
net/socket.c:1476:SYSCALL_DEFINE2(listen, int, fd, int, backlog)
net/socket.c:1509:SYSCALL_DEFINE4(accept4, int, fd, struct sockaddr __user *, upeer_sockaddr,
net/socket.c:1583:SYSCALL_DEFINE3(accept, int, fd, struct sockaddr __user *, upeer_sockaddr,
net/socket.c:1601:SYSCALL_DEFINE3(connect, int, fd, struct sockaddr __user *, uservaddr,
...

SYSCALL_DEFINEn(socket) 宏展开实际上是定义了一个名为sys_socket的函数。

为什么在 net 目录下搜索？因为 socket 和网络相关，显然是是在网络子系统中。还有其他常见的子系统如下：

• mm: 内存管理子系统
• kernel: 任务调度、进程管理、用户管理
• fs: 各种文件系统的实现
• arch: 处理器架构相关的代码，比如中断向量表，CPU和SOC的定义
• …

这个小技巧有助于快速定位某个子系统的入口。

socket子系统

严格来说socket不是一个子系统，网络才是一个子系统。但我这里还是这样称呼它，将其看作是围绕socket数据结构的一系列操作，比如创建、删除、修改，等等。

socket内核数据结构为：

/**
*  struct socket - general BSD socket
*  @state: socket state (%SS_CONNECTED, etc)
*  @type: socket type (%SOCK_STREAM, etc)
*  @flags: socket flags (%SOCK_ASYNC_NOSPACE, etc)
*  @ops: protocol specific socket operations
*  @file: File back pointer for gc
*  @sk: internal networking protocol agnostic socket representation
*  @wq: wait queue for several uses
*/
struct socket {
  socket_state        state;

  kmemcheck_bitfield_begin(type);
  short           type;
  kmemcheck_bitfield_end(type);

  unsigned long       flags;

  struct socket_wq __rcu  *wq;

  struct file     *file;
  struct sock     *sk;
  const struct proto_ops  *ops;
};

注释还比较清楚，值得注意的是这里说sk为内部网络协议的实现。

socket创建

socket创建流程为：

• sock_create
  • sock_alloc()
    • new_inode_pseudo
      • alloc_inode
  • pf->create(net, sock, protocol, kern)

没看到有创建socket结构体的地方，只看到初始化了inode，然后通过

sock = SOCKET_I(inode);

获得socket指针，alloc_inode实现为：

static struct inode *alloc_inode(struct super_block *sb)
{
  struct inode *inode;

  if (sb->s_op->alloc_inode)
      inode = sb->s_op->alloc_inode(sb);
  else
      inode = kmem_cache_alloc(inode_cachep, GFP_KERNEL);
// ...
}

有时候静态分析不太好确定走的是哪个分支，但根据SOCKET_I宏得知从inode获取sock是根据结构体偏移来的，所以显然inode的分配不单单是从inode_cachep从获取，而是走的上面一个分支，搜索.alloc_inode发现socket.c中果然定义了自己的分配函数sock_alloc_inode，内部通过sock_inode_cachepslub分配socket：

static struct inode *sock_alloc_inode(struct super_block *sb)
{
  struct socket_alloc *ei;
  struct socket_wq *wq;

  ei = kmem_cache_alloc(sock_inode_cachep, GFP_KERNEL);
  if (!ei)
      return NULL;
  wq = kmalloc(sizeof(*wq), GFP_KERNEL);
  if (!wq) {
      kmem_cache_free(sock_inode_cachep, ei);
      return NULL;
  }
  init_waitqueue_head(&wq->wait);
  wq->fasync_list = NULL;
  wq->flags = 0;
  RCU_INIT_POINTER(ei->socket.wq, wq);

  ei->socket.state = SS_UNCONNECTED;
  ei->socket.flags = 0;
  ei->socket.ops = NULL;
  ei->socket.sk = NULL;
  ei->socket.file = NULL;

  return &ei->vfs_inode;
}