Fuse | Electron 安全

0x01 简介

大家好，今天和大家讨论的是 fuse ， fuse 直译过来是保险丝，官方文档中翻译为包特性切换

Electron 开发的应用有很多特性，能够为一些场景提供帮助，但并不是所有的场景都会用到这些特性，因此对于普通开发者来说，你默认给我开发的程序带了一堆特性，我可能还用不到，甚至可能还不太安全，我是不是应该有禁用的选项，例如，99%的应用都没有使用ELECTRON_RUN_AS_NODE，开发者希望能够提供无法使用该功能的二进制文件。

这就是 Fuse

公众号开启了留言功能，欢迎大家留言讨论～

这篇文章也提供了 PDF 版本及 Github ，见文末

• 0x01 简介

• 0x02 当前可用的 fuse

• 0x03 如何查看程序的 fuse

• 0x04 特性可能带来的危害

• 1. runAsNode

• 2. nodeCliInspect

• 3. nodeOptions

• 4. grantFileProtocolExtraPrivileges

• 5. CVE-2024-23743

• 0x05 修改程序的 fuse

• 0x06 总结

• 0x07 PDF 版 & Github

• 往期文章

0x02 当前可用的 fuse

fuse 还在随着版本不断增加，这篇文章只讨论目前(2024-05-10)的情况

但是经过我的实际测试，发现 Electron Forge ，也就是官方推荐的打包工具默认的 Fuse 配置如下

forge.config.js

const { FusesPlugin } = require('@electron-forge/plugin-fuses');
const { FuseV1Options, FuseVersion } = require('@electron/fuses');

module.exports = {
  packagerConfig: {
    asar: true,
  },
  rebuildConfig: {},
  makers: [
    {
      name: '@electron-forge/maker-squirrel',
      config: {},
    },
    {
      name: '@electron-forge/maker-zip',
      platforms: ['darwin'],
    },
    {
      name: '@electron-forge/maker-deb',
      config: {},
    },
    {
      name: '@electron-forge/maker-rpm',
      config: {},
    },
  ],
  plugins: [
    {
      name: '@electron-forge/plugin-auto-unpack-natives',
      config: {},
    },
    // Fuses are used to enable/disable various Electron functionality
    // at package time, before code signing the application
    new FusesPlugin({
      version: FuseVersion.V1,
      [FuseV1Options.RunAsNode]: false,
      [FuseV1Options.EnableCookieEncryption]: true,
      [FuseV1Options.EnableNodeOptionsEnvironmentVariable]: false,
      [FuseV1Options.EnableNodeCliInspectArguments]: false,
      [FuseV1Options.EnableEmbeddedAsarIntegrityValidation]: true,
      [FuseV1Options.OnlyLoadAppFromAsar]: true,
    }),
  ],
};

可以看到，除了 loadBrowserProcessSpecificV8Snapshot 和 grantFileProtocolExtraPrivileges 其他的与官网标记的默认值完全相反，我们看一下实际打包出来的程序

和上面的配置一致

所以你说官方设置默认值不太符合默认即安全吧，它打包工具里给你自动重新设置了值，你说他默认即安全吧，还没有把安全的值设置为默认，奇奇怪怪

0x03 如何查看程序的 fuse

检查一个应用程序的 fuse 设置

https://www.electronjs.org/zh/docs/latest/tutorial/fuses#how-do-i-flip-the-fuses

需要安装 @electron/fuses 依赖包

npm i @electron/fuses

检查应用程序的 fuse

npx @electron/fuses read --app /Applications/Foo.app

0x04 特性可能带来的危害

现在的情况是官方比较幽默，fuse 的默认值设置的像是安全在为功能让步，但打包工具又反转过来，当然我们作为安全研究人员更希望向默认即安全的建设方向去走

我们接下来就看一下这些特性可能带来的危害

1. runAsNode

runAsNode 特性的含义是程序当作普通的 Node.js 进程启动，如果是普通的 Node.js ，那么可以给该程序传递很多启动参数，官方的文档说是否考虑 ELECTRON_RUN_AS_NODE 环境变量

ELECTRON_RUN_AS_NODE 参考如下文档

https://www.electronjs.org/zh/docs/latest/api/environment-variables#electron_run_as_node

文档中说默认情况下，除了以下标志，标准的 cli 选项传递给程序都会生效

• --openssl-config
• --use-bundled-ca
• --use-openssl-ca
• --force-fips
• --enable-fips

这些标志无效是因为 Electron 在构建 Node.js 的 crypto 模块时使用 BoringSSL 而不是 OpenSSL

cli 选项可以参考

https://nodejs.org/api/cli.html

现在我编译一个 runAsNode 为 Enabled 的程序

尝试通过设置环境变量  ELECTRON_RUN_AS_NODE=1 并传递 -i 参数

成功实现本地命令执行

Windows 和 MacOS 也成功执行系统命令

2. nodeCliInspect

这个 fuse 就是之前的 远程调试的利用 文章了，这个fuse 决定是否可以进行远程调试

如果设置允许远程调试，情况如下

如果设置不允许远程调试，则情况如下

远程调试无法启动

当 runAsNode 被设置为 Enable ，但是远程调试被设置为 Disabled 时会怎么样呢？

在 Windows 平台上并不会开启远程调试，但在 Deepin Linux 上则不同

在 Deepin Linux 上，当 runAsNode 或 nodeCliInspect 其中一个被设置为 Enabled ，就可以进行远程调试

在 MacOS 上表现如何呢

当 runAsNode 为 Enable ，远程调试设置为 Disabled 时

当 runAsNode 和远程调试都设置为 Disabled 时

无法执行远程调试

当 runAsNode 为 Disabled ，远程调试设置为 Enabled 时

可以远程调试

所以 nodeCliInspect 这个 fuse 的效果设置在 MacOS 和 Deepin Linux 上表现一致，即当 runAsNode 或 nodeCliInspect 其中一个被设置为 Enabled ，就可以进行远程调试

在 Windows 11 上则只有当 nodeCliInspect 被设置为 Enabled 时才可以进行远程调试，与 runAsNode 无关

不过 Electron 还在发展，在未来可能还会有变化

3. nodeOptions

这个 fuse 是决定程序是否要使用两个环境变量 NODE_OPTIONS 和 NODE_EXTRA_CA_CERTS

https://nodejs.org/api/cli.html#node_optionsoptions

https://github.com/nodejs/node/blob/main/doc/api/cli.md#node_extra_ca_certsfile

这个 fuse 只在 runAsNode 被设置为 Enabled 时有效，其实就是给 Node.js 传递的那些参数被写进了这个环境变量里

关闭 runAsNode 后

就无法运行 Node.js 代码并执行系统命令了

4. grantFileProtocolExtraPrivileges

这个 fuse 是关于 file:// 协议的，在 Electron 中 file:// 协议比 web 浏览器中的 file:// 协议具备更强大的功能，包括但不限于

• file:// 协议加载的页面可以通过 fetch 加载其他file:// 协议的资源
• file:// 协议加载的页面能够使用 service workers
• file:// 协议加载的页面能够访问子 frames
• file:// 无视沙盒限制

官方推荐，加载本地文件尽可能使用自定义协议，而不是开启这个 fuse ，对于旧版本 Electron ，这是核心功能，所以默认开启；在 Electron Forge 中也没有对其进行额外设置，这是合理的，毕竟不是所有开发者都会去自定义协议

我们尝试直接使用 fiddle 进行测试第一项

确实可以获取到数据，而且之前就测试过，file 协议之间没有同源策略限制

现在我们将程序用 Electron Forge 进行打包

不仅使用 fetch 请求 file:// 协议资源不可用了，通过 file:// 创建主窗口都不行了，可能需要对路径进行配置，但明确的是使用 fetch 请求 file:// 协议资源这种特权没有了

5. CVE-2024-23743

这个 CVE 就是上面提到的 runAsNode 和 nodeCliInspect 开启的效果，有一些安全研究员直接给提交 CVE 了，我看了一下，好像还提交了不少，为此官方在博客中专门谈了一下这个问题

官方的态度首先是认为描述不准确，提交者认为这是一个远程代码执行，并且认定是严重 critical，其实是强调和 Chrome 的漏洞模型保持一致，不考虑本地物理攻击

其实这些 fuse 的问题是因为在一场安全大会上，有位安全研究员提出来的，并且还制作了一个检测工具，具体官方声明以及检测工具查看下方链接

https://www.electronjs.org/zh/blog/statement-run-as-node-cves

https://github.com/r3ggi/electroniz3r

0x05 修改程序的 fuse

程序的 fuse 是可以手动修改的，由于 fuse 是在签名前打包时候设置的，所以在签名后修改 fuse 应该会导致签名失效

有两种方式，一种是使用官方的工具 @electron/fuses ，另一种方式是直接修改二进制文件，官方提供了一些格式信息，但显然，官方的工具是更简单的

可以看到，当前程序的 RunAsNode 是 Disabled 的，也就是无法当作 Node.js 执行

现在我们尝试翻转 RunAsNode

现在 RunAsNode 变成 Enabled 了，尝试执行 Node.js

接下来我们测试一下，将 vscode 的 fuse 翻转后，它的签名是否依旧有效

"C:UsersjoinAppDataLocalProgramsMicrosoft VS CodeCode.exe"

读取 VSCode 的 fuse

npx @electron/fuses read --app "C:UsersjoinAppDataLocalProgramsMicrosoft VS CodeCode.exe"

备份好原文件后，尝试将 RunAsNode 设置为 Disabled

成功翻转 RunAsNode 的设置，我们看一下签名情况

果然，签名失效

是否可以正常执行呢？

功能依旧正常，我们尝试再翻转一次，看看能不能让签名再次生效

签名又恢复了正常，这有点意思

0x06 总结

Electron 开发的程序默认会带有一些特性，然而这些特性并不总是能用到，甚至很多特性大部分开发者都用不到，所以官方给了一个总开关，可以在打包等过程中，显式的关闭或启用这些特性

目前来看，这些特性能够引起的主要是本地命令执行、文件读取，主要涉及的特性如下

• runAsNode
• nodeCliInspect
• nodeOptions
• grantFileProtocolExtraPrivileges

应用程序的 fuse 是可以翻转的，官方也提供了工具，由于特性的启用与关闭是在打包过程中完成的，所以翻转已经签名的程序的fuse 会导致签名失效，但将已经翻转的fuse 再翻转一次，保持和原本的程序一致，签名就会重新生效

0x07 PDF 版 & Github

PDF 版

https://pan.baidu.com/s/1-wCXxWhJdH8ff3RfoRaYPw?pwd=t5hi

Github

https://github.com/Just-Hack-For-Fun/Electron-Security

往期文章

• Electron 安全与你我息息相关
  

• 跳转与导航 | Electron 安全
  

• 新窗口创建问题 | Electron 安全

• Web 嵌入 | Electron 安全