10 篇标记为“Security”的文章

今天早些时候，Electron 团队收到了关于最近提交给一些知名 Electron 应用的多个公开 CVE 的通知。这些 CVE 与 Electron 的两个 fuses 相关——runAsNode 和 enableNodeCliInspectArguments——并且错误地声称，如果远程攻击者未主动禁用这些组件，就可以通过它们执行任意代码。

我们不认为这些 CVE 是善意提交的。首先，该声明是不正确的——该配置**不**允许远程代码执行。其次，尽管 CVE 中提到的公司设有漏洞赏金计划，但它们并未收到通知。最后，虽然我们确实认为禁用相关组件可以提高应用程序的安全性，但我们不认为这些 CVE 是以正确的严重性级别提交的。“关键”是为最高危险的漏洞保留的，而这里的情况绝非如此。

任何人都可以请求 CVE。虽然这有助于整个软件行业的健康发展，但为了提升某个安全研究员的声誉而“刷 CVE”则无益。

尽管如此，我们理解带有令人担忧的critical严重性的 CVE 的存在可能会导致最终用户混淆，因此作为项目方，我们希望就如何处理此问题提供指导和帮助。

这可能如何影响我？​

经过对 CVE 的审查，Electron 团队认为这些 CVE 并非关键性问题。

攻击者需要能够在其计算机上执行任意命令，这要么是通过物理访问硬件，要么是通过已成功实现远程代码执行。这一点需要重申：所描述的漏洞**要求攻击者已经能够访问被攻击的系统**。

例如，Chrome 在其威胁模型中不考虑物理本地攻击。

我们认为这些攻击超出了 Chrome 的威胁模型，因为 Chrome（或任何应用程序）无法防御设法以您的身份登录您的设备或能够以您的操作系统用户帐户特权运行软件的恶意用户。这样的攻击者可以修改可执行文件和 DLL、更改环境变量（如 PATH）、修改配置文件、读取您用户帐户拥有的任何数据并将其通过电子邮件发送给自己等等。这样的攻击者对您的设备拥有完全的控制权，Chrome 无法提供任何严肃的防御保证。这个问题并非 Chrome 特有——所有应用程序都必须信任物理本地用户。

CVE 中描述的利用允许攻击者将受影响的应用程序用作具有继承的 TCC 权限的通用 Node.js 进程。因此，如果该应用程序，例如，已被授予访问地址簿的权限，攻击者就可以将该应用程序作为 Node.js 运行并执行任意代码，而这些代码将继承该地址簿访问权限。这通常被称为“利用系统自带工具进行攻击”（living off the land）攻击。攻击者通常使用 PowerShell、Bash 或类似工具来运行任意代码。

我受到影响吗？​

默认情况下，所有已发布的 Electron 版本都启用了 runAsNode 和 enableNodeCliInspectArguments 功能。如果您没有按照 Electron Fuses 文档中的说明将其关闭，您的应用程序同样容易受到被用作“利用系统自带工具进行攻击”的攻击。再次强调，我们需要指出，攻击者需要**已经**能够在受害者的计算机上执行代码和程序。

缓解措施​

缓解此问题的最简单方法是禁用 Electron 应用程序中的 runAsNode fuse。runAsNode fuse 控制是否尊重 ELECTRON_RUN_AS_NODE 环境变量。请参阅 Electron Fuses 文档，了解如何切换这些 fuses。

请注意，如果此 fuse 被禁用，那么主进程中的 process.fork 将无法按预期工作，因为它依赖于此环境变量才能正常运行。相反，我们建议您使用 Utility Processes，它适用于许多需要独立 Node.js 进程的用例（例如 Sqlite 服务器进程或类似场景）。

您可以在我们的 安全清单 中找到更多关于我们为 Electron 应用程序推荐的安全最佳实践信息。

自 CVE-2023-4863：WebP 中的堆缓冲区溢出 公开以来已过去一周多，这促使渲染 webp 图像的软件纷纷发布新版本：macOS、iOS、Chrome、Firefox 和各种 Linux 发行版都收到了更新。此前，Citizen Lab 的调查发现，一个“位于华盛顿特区的公民社会组织”使用的 iPhone 正在遭受 iMessage 中的零点击漏洞攻击。

Electron 也迅速行动起来，并在当天发布了新版本：如果您的应用程序渲染任何用户提供的​​内容，则应更新您的 Electron 版本 - v27.0.0-beta.2、v26.2.1、v25.8.1、v24.8.3 和 v22.3.24 都包含已修复的 libwebp 版本，这是负责渲染 webp 图像的库。

现在我们都清楚，“渲染图像”这样看似无害的操作也可能带来危险，我们想借此机会提醒大家，Electron 提供了一个进程沙盒，可以限制下一次重大攻击（无论是什么）的波及范围。

沙盒自 Electron v1 版本起就已存在，并在 v20 版本中默认启用。但我们知道，许多应用程序（尤其是那些已存在一段时间的应用程序）可能在其代码中的某个地方设置了 sandbox: false，或者设置了 nodeIntegration: true，当没有明确的 sandbox 设置时，后者同样会禁用沙盒。这是可以理解的：如果您与我们同行已久，您可能享受过将 require("child_process") 或 require("fs") 放入运行 HTML/CSS 的同一代码中的强大功能。

在我们讨论如何迁移到沙箱之前，让我们先讨论一下你为什么需要它。

沙盒为所有渲染器进程提供了严格的限制，确保无论内部发生什么，代码都在受限的环境中执行。作为一个概念，它比 Chromium 早得多，并且是所有主流操作系统提供的功能。Electron 和 Chromium 的沙盒都建立在这些系统功能之上。即使您从不显示用户生成的内容，也应考虑您的渲染器可能被破坏的可能性：像供应链攻击这样复杂的场景，以及像小 bug 这样简单的错误，都可能导致您的渲染器执行您并未完全打算让它执行的操作。

沙盒使这种情况不那么可怕：内部进程可以自由使用 CPU 周期和内存——仅此而已。进程无法写入磁盘或显示自己的窗口。在我们的 libwep 漏洞案例中，沙盒确保攻击者无法安装或运行恶意软件。事实上，在最初针对该员工 iPhone 的 Pegasus 攻击案例中，攻击者专门针对一个非沙盒化的图像进程来获取手机的访问权限，首先突破了通常被沙盒化的 iMessage 的边界。当出现像本例中的 CVE 时，您仍然需要将您的 Electron 应用程序升级到安全版本——但在此期间，攻击者造成的损害将大大减少。

将一个标准的 Electron 应用程序从 sandbox: false 迁移到 sandbox: true 是一项艰巨的任务。我知道，因为尽管我个人撰写了 Electron 安全指南 的初稿，但我自己还没有成功地迁移我的一个应用程序来使用它。本周末情况发生了变化，我建议您也这样做。

你需要解决两个问题

1. 如果您在 preload 脚本或实际的 WebContents 中使用 Node.js 代码，您需要将所有 Node.js 交互移至主进程（或，如果您喜欢，迁移到一个辅助进程）。考虑到渲染器已变得多么强大，您的绝大多数代码可能实际上不需要重构。

   请参阅我们关于 进程间通信 的文档。就我个人而言，我迁移了大量代码，并使用 ipcRenderer.invoke() 和 ipcMain.handle() 进行包装，但这个过程很简单，而且很快就完成了。在这里，要注意您的 API——如果您构建了一个名为 executeCodeAsRoot(code) 的 API，沙盒将无法很好地保护您的用户。

2. 由于启用沙箱会禁用预加载脚本中的 Node.js 集成，因此你无法再使用 require("../my-script")。换句话说，你的预加载脚本需要是单个文件。

   有多种方法可以做到这一点：Webpack、esbuild、parcel 和 rollup 都可以完成这项工作。我使用了 Electron Forge 出色的 Webpack 插件，同样流行的 electron-builder 用户可以使用 electron-webpack。

总而言之，整个过程花费了我大约四天时间——这还包括了我为了用各种方式重构我的代码而对如何驾驭 Webpack 的强大功能感到困惑的时间。

Chromium 中发现了一个高危漏洞，该漏洞影响包括 Electron 在内的所有基于 Chromium 的软件。

此漏洞已被分配 CVE-2019-13720。您可以在 Chrome 博客文章中阅读更多相关信息。

请注意，Chrome 报告称此漏洞已在野外被利用，因此强烈建议您尽快升级 Electron。

范围​

这会影响任何可能运行第三方或不受信任的 JavaScript 的 Electron 应用程序。

缓解措施​

受影响的应用应升级到已修复的 Electron 版本。

我们已发布新版本的 Electron，其中包含此漏洞的修复程序。

• 6.1.4

Electron 7.0.1 在公告发布前已自动包含来自上游的修复。Electron 8 同样不受影响。该漏洞在 Electron 5 中不存在，因此该版本也不受影响。

进一步信息​

此漏洞由卡巴斯基实验室的 Anton Ivanov 和 Alexey Kulaev 发现，并报告给 Chrome 团队。Chrome 博客文章可在此处找到：此处。

要了解有关保护您的 Electron 应用安全的最佳实践，请参阅我们的安全教程。

如果您希望报告 Electron 中的漏洞，请提交 GitHub 安全咨询。

Chromium 中发现了一个高危漏洞，该漏洞影响包括 Electron 在内的所有基于 Chromium 的软件。

此漏洞已被分配 CVE-2019-5786。您可以在 Chrome 博客文章中了解更多信息。

请注意，Chrome 已收到此漏洞在野外被利用的报告，因此强烈建议您尽快升级 Electron。

范围​

这会影响任何可能运行第三方或不受信任的 JavaScript 的 Electron 应用程序。

缓解措施​

受影响的应用应升级到已修复的 Electron 版本。

我们已发布新版本的 Electron，其中包含此漏洞的修复程序。

• 4.0.8
• 3.1.6
• 3.0.16
• 2.0.18

Electron 5 的最新测试版已跟随 Chromium 73，因此已得到修复。

• 5.0.0-beta.5

进一步信息​

此漏洞由 Google 威胁分析小组的 Clement Lecigne 发现并报告给 Chrome 团队。Chrome 博客文章可以在 此处找到。

要了解有关保护您的 Electron 应用安全的最佳实践，请参阅我们的安全教程。

如果您希望报告 Electron 中的漏洞，请提交 GitHub 安全咨询。

发现了一个代码漏洞，允许在子窗口中重新启用 Node。

使用 sandbox: true 或 nativeWindowOpen: true 以及 nodeIntegration: false 打开 BrowserView 会导致一个 webContents，其中 window.open 方法可以被调用，并且新打开的子窗口将启用 nodeIntegration。此漏洞影响所有受支持的 Electron 版本。

缓解措施​

我们已发布包含此漏洞修复的新版本 Electron：2.0.17、3.0.15、3.1.3、4.0.4 和 5.0.0-beta.2。我们鼓励所有 Electron 开发者立即将他们的应用程序更新到最新的稳定版本。

如果出于某种原因无法升级 Electron 版本，可以通过禁用所有子 webContents 来缓解此问题。

view.webContents.on('-add-new-contents', (e) => e.preventDefault());

进一步信息​

此漏洞由 PalmerAL 发现并负责任地报告给 Electron 项目。

要了解有关保护您的 Electron 应用安全的最佳实践，请参阅我们的安全教程。

如果您希望报告 Electron 中的漏洞，请提交 GitHub 安全咨询。

一种名为“Magellan”的远程代码执行漏洞已被发现，该漏洞影响基于 SQLite 或 Chromium 的软件，包括所有版本的 Electron。

范围​

使用 Web SQL 的 Electron 应用程序受到影响。

缓解措施​

受影响的应用程序应停止使用 Web SQL 或升级到已修补的 Electron 版本。

我们已发布新版本的 Electron，其中包含此漏洞的修复程序。

• 4.0.0-beta.11
• 3.1.0-beta.4
• 3.0.13
• 2.0.16

目前尚无野外报告；但是，强烈建议受影响的应用程序进行缓解。

进一步信息​

该漏洞由腾讯 Blade 团队发现，该团队已发布一篇讨论该漏洞的博客文章。

要了解有关保护您的 Electron 应用安全的最佳实践，请参阅我们的安全教程。

如果您希望报告 Electron 中的漏洞，请提交 GitHub 安全咨询。

已发现一个远程代码执行漏洞，影响使用 Electron 版本 (3.0.0-beta.6, 2.0.7, 1.8.7 和 1.7.15) 打开嵌套子窗口的应用。该漏洞已分配 CVE 标识符 CVE-2018-15685。

受影响的平台​

如果您满足以下条件，则会受到影响：

1. 您嵌入了任何远程用户内容，即使是在沙盒环境中
2. 您接受任何带有 XSS 漏洞的用户输入

详细信息

如果您允许任何用户代码在 iframe 中运行 / 能够创建 iframe，则会受到影响。鉴于存在 XSS 漏洞的可能性，可以假定大多数应用程序都容易受到这种情况的影响。

如果您使用 nativeWindowOpen: true 或 sandbox: true 选项打开任何窗口，您也将受到影响。尽管此漏洞还要求您的应用存在 XSS 漏洞，但如果您使用任一选项，仍应应用以下缓解措施之一。

缓解措施​

我们已发布包含此漏洞修复的新版 Electron：3.0.0-beta.7、2.0.8、1.8.8 和 1.7.16。我们敦促所有 Electron 开发者立即将其应用更新至最新稳定版本。

如果您因任何原因无法升级您的 Electron 版本，可以通过在所有 webContents 的 new-window 事件上全局调用 event.preventDefault() 来保护您的应用。如果您根本不使用 window.open 或任何子窗口，这也是一种有效的缓解措施。

mainWindow.webContents.on('new-window', (e) => e.preventDefault());

如果您依赖子窗口创建孙窗口的能力，那么第三种缓解策略是使用以下代码处理您的顶级窗口：

const enforceInheritance = (topWebContents) => {
  const handle = (webContents) => {
    webContents.on(
      'new-window',
      (event, url, frameName, disposition, options) => {
        if (!options.webPreferences) {
          options.webPreferences = {};
        }
        Object.assign(
          options.webPreferences,
          topWebContents.getLastWebPreferences(),
        );
        if (options.webContents) {
          handle(options.webContents);
        }
      },
    );
  };
  handle(topWebContents);
};

enforceInheritance(mainWindow.webContents);

此代码将手动强制将顶级窗口的 webPreferences 应用于所有深度嵌套的子窗口。

进一步信息​

此漏洞由 Contrast Security 的 Matt Austin 发现并负责任地报告给 Electron 项目。

要了解有关保护您的 Electron 应用安全的最佳实践，请参阅我们的安全教程。

如果您希望报告 Electron 中的漏洞，请提交 GitHub 安全咨询。

已发现一个漏洞，该漏洞允许在某些禁用 Node.js 集成的 Electron 应用程序中重新启用 Node.js 集成。该漏洞已被分配 CVE 标识符 CVE-2018-1000136。

受影响的应用程序​

如果满足以下所有条件，则应用程序受影响：

1. 运行 Electron 1.7、1.8 或 2.0.0-beta 版本
2. 允许执行任意远程代码
3. 禁用 Node.js 集成
4. 未在其 webPreferences 中显式声明 webviewTag: false
5. 未启用 nativeWindowOption 选项
6. 未拦截 new-window 事件并手动覆盖 event.newGuest，而未使用提供的选项标签

尽管这似乎只影响少数 Electron 应用程序，但我们仍鼓励所有应用程序作为预防措施进行升级。

缓解措施​

此漏洞已在今日发布的 1.7.13、1.8.4 和 2.0.0-beta.5 版本中得到修复。

无法升级应用程序 Electron 版本的开发者可以通过以下代码缓解此漏洞：

app.on('web-contents-created', (event, win) => {
  win.on(
    'new-window',
    (event, newURL, frameName, disposition, options, additionalFeatures) => {
      if (!options.webPreferences) options.webPreferences = {};
      options.webPreferences.nodeIntegration = false;
      options.webPreferences.nodeIntegrationInWorker = false;
      options.webPreferences.webviewTag = false;
      delete options.webPreferences.preload;
    },
  );
});

// and *IF* you don't use WebViews at all,
// you might also want
app.on('web-contents-created', (event, win) => {
  win.on('will-attach-webview', (event, webPreferences, params) => {
    event.preventDefault();
  });
});

进一步信息​

此漏洞由 Trustwave SpiderLabs 的 Brendan Scarvell 发现并负责任地报告给 Electron 项目。

要了解有关保护您的 Electron 应用安全的最佳实践，请参阅我们的安全教程。

如果您希望报告 Electron 中的漏洞，请提交 GitHub 安全咨询。

请加入我们的 邮件列表，以接收有关发布和安全更新的通知。

我们发现了一个远程代码执行漏洞，它会影响使用自定义协议处理程序的 Electron 应用。此漏洞已被分配 CVE 标识符 CVE-2018-1000006。

受影响的平台​

在 Windows 上运行并注册为协议（例如 myapp://）的默认处理程序的 Electron 应用程序存在漏洞。

此类应用可能会受到影响，无论协议是如何注册的，例如使用原生代码、Windows 注册表，还是 Electron 的 app.setAsDefaultProtocolClient API。

macOS 和 Linux **不受**此问题影响。

缓解措施​

我们已经发布了包含此漏洞修复的 Electron 新版本：1.8.2-beta.5、1.7.12 和 1.6.17。我们敦促所有 Electron 开发者立即将其应用更新到最新的稳定版本。

如果由于某种原因您无法升级 Electron 版本，您可以在调用 app.setAsDefaultProtocolClient 时将 -- 作为最后一个参数附加，这会阻止 Chromium 解析更多选项。双破折号 -- 表示命令选项的结束，之后只接受位置参数。

app.setAsDefaultProtocolClient(protocol, process.execPath, [
  '--your-switches-here',
  '--',
]);

有关更多详细信息，请参阅 app.setAsDefaultProtocolClient API。

要了解有关保护您的 Electron 应用安全的最佳实践，请参阅我们的安全教程。

如果您希望报告 Electron 中的漏洞，请提交 GitHub 安全咨询。

在 Google Chromium 中发现了一个远程代码执行漏洞，该漏洞会影响所有最新版本的 Electron。任何访问远程内容的 Electron 应用都容易受到此漏洞的攻击，无论 沙箱选项 是否已启用。

我们发布了两个新版本的 Electron：1.7.8 和 1.6.14，它们都包含对此漏洞的修复。我们敦促所有 Electron 开发人员立即将其应用程序更新到最新的稳定版本。

npm i electron@latest --save-dev

要了解有关保护您的 Electron 应用安全的最佳实践，请参阅我们的安全教程。

如果您希望报告 Electron 中的漏洞，请提交 GitHub 安全咨询。