带有“安全”标签的 10 篇文章

今天早些时候，Electron 团队收到通知，最近针对几个著名的 Electron 应用程序提交了几个公开的 CVE。这些 CVE 与 Electron 的两个 熔断器 - runAsNode 和 enableNodeCliInspectArguments - 相关，并错误地声称，如果这些组件没有被主动禁用，远程攻击者可以通过这些组件执行任意代码。

我们认为这些 CVE 不是出于善意提交的。首先，该说法不正确 - 配置 *不会* 启用远程代码执行。其次，尽管这些 CVE 中提到的公司拥有漏洞赏金计划，但却没有收到通知。最后，虽然我们确实认为禁用上述组件可以增强应用程序安全性，但我们不认为这些 CVE 已按正确严重程度提交。“严重”专用于最危险的问题，而这里的情况肯定不是这样。

任何人都可以请求 CVE。虽然这对于软件行业的整体健康发展是有益的，但“农场 CVE”来提升单个安全研究人员的声誉并没有帮助。

也就是说，我们理解，仅仅存在一个具有可怕的“严重”级别的 CVE 可能会导致最终用户混淆，因此作为项目，我们希望提供处理此问题的指导和帮助。

这可能对我有何影响？​

在审查了 CVE 后，Electron 团队认为这些 CVE 并不严重。

攻击者需要能够在机器上执行任意命令，方法是物理访问硬件或获得完全远程代码执行。需要重复说明：所描述的漏洞 *需要攻击者已经访问了被攻击的系统*。

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

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

CVE 中描述的漏洞允许攻击者随后使用受影响的应用程序作为具有继承的 TCC 权限的通用 Node.js 进程。因此，例如，如果应用程序已被授予访问地址簿的权限，则攻击者可以以 Node.js 的身份运行应用程序并执行任意代码，这些代码将继承该地址簿访问权限。这通常称为“利用现有资源发动攻击”。攻击者通常使用 PowerShell、Bash 或类似工具来运行任意代码。

我受到影响了吗？​

默认情况下，所有已发布的 Electron 版本都启用了 runAsNode 和 enableNodeCliInspectArguments 功能。如果您没有按照 Electron 熔断器文档 中的说明将其关闭，则您的应用程序同样容易受到用作“利用现有资源发动攻击”的攻击。再次强调，攻击者需要 *已经* 能够在受害者机器上执行代码和程序。

缓解措施​

缓解此问题的最简单方法是在 Electron 应用程序中禁用 runAsNode 熔断器。runAsNode 熔断器切换 ELECTRON_RUN_AS_NODE 环境变量是否被尊重。请参阅 Electron 熔断器文档，了解有关如何切换这些熔断器的信息。

请注意，如果禁用此熔断器，则主进程中的 process.fork 将无法按预期工作，因为它依赖此环境变量来工作。相反，我们建议您使用 实用程序进程，它们适用于您需要独立 Node.js 进程的许多用例（例如 Sqlite 服务器进程或类似场景）。

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

自从 CVE-2023-4863：WebP 中的堆缓冲区溢出 公开发布已经超过一周了，导致渲染 webp 图像的软件发布了大量新版本：macOS、iOS、Chrome、Firefox 和各种 Linux 发行版都收到了更新。这紧随公民实验室的调查，他们发现一个“华盛顿特区民权组织”使用的 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 的沙箱构建在这些系统功能之上。即使您从未显示用户生成的內容，您也应该考虑您的渲染器可能被入侵的可能性：从供应链攻击到简单的微小错误，各种情况都可能导致您的渲染器执行您没有完全预期它要执行的操作。

沙箱使这种情况不那么可怕：内部进程可以自由使用 CPU 周期和内存——仅此而已。进程无法写入磁盘或显示自己的窗口。就我们的 libwebp 错误而言，沙箱确保攻击者无法安装或运行恶意软件。事实上，在最初针对员工 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 巨大能量的苦思冥想，因为我决定借此机会用许多其他方式重构我的代码。

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

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

请注意，据报道 Chrome 中存在此漏洞被利用的事件，因此强烈建议您尽快升级 Electron。

范围​

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

缓解措施​

受影响的应用程序应升级到已修补版本的 Electron。

我们发布了包含此漏洞修复的新版本的 Electron

• 6.1.4

Electron 7.0.1 在公告发布之前就自动包含了来自上游的修复程序。Electron 8 类似地不受影响。Electron 5 中不存在该漏洞，因此该版本也不受影响。

更多信息​

此漏洞由 Kaspersky Labs 的 Anton Ivanov 和 Alexey Kulaev 发现，并报告给 Chrome 团队。可以在 此处 找到 Chrome 博客文章。

要了解有关保持 Electron 应用程序安全的最佳实践的更多信息，请参阅我们的 安全教程。

如果您想报告 Electron 中的漏洞，请发送电子邮件至 [email protected]。

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

此漏洞已分配了 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 中的漏洞，请发送电子邮件至 [email protected]。

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

使用 sandbox: true 或 nativeWindowOpen: true 和 nodeIntegration: false 打开一个 BrowserView 会导致 window.open 可以被调用的 webContents，并且新打开的子窗口将具有启用的 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 中的漏洞，请发送电子邮件至 [email protected]。

发现了一个远程代码执行漏洞“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 中的漏洞，请发送电子邮件至 [email protected]。

发现了一个远程代码执行漏洞，该漏洞影响能够在 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 手动应用于所有子窗口，并无限深度地向下传递。

更多信息​

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

要了解有关保持 Electron 应用程序安全的最佳实践的更多信息，请参阅我们的 安全教程。

如果您想报告 Electron 中的漏洞，请发送电子邮件至 [email protected]。

发现了一个漏洞，该漏洞允许在一些禁用 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 事件并使用提供的 options 标签手动覆盖 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 中的漏洞，请发送电子邮件至 [email protected]。

请加入我们的 电子邮件列表 以接收有关版本和安全更新的通知。

已发现影响使用自定义协议处理程序的 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 中的漏洞，请发送电子邮件至 [email protected]。

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

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

npm i electron@latest --save-dev

要了解有关保持 Electron 应用程序安全的最佳实践的更多信息，请参阅我们的 安全教程。

如果您想报告 Electron 中的漏洞，请联系 [email protected]。