10 篇帖子已标记 “Security”

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

我们不认为这些 CVE 是出于善意提交的。 首先，声明是不正确的 - 该配置不启用远程代码执行。 其次，尽管拥有漏洞赏金计划，但这些 CVE 中点名的公司尚未收到通知。 最后，虽然我们确实认为禁用相关组件可以增强应用安全性，但我们不认为这些 CVE 是以正确的严重性级别提交的。 “严重”是为最高危险级别的问题保留的，而这里的情况肯定不是这样。

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

也就是说，我们理解仅 CVE 的存在以及可怕的 critical 严重性可能会导致最终用户感到困惑，因此作为一个项目，我们想提供指导和帮助来处理这个问题。

这可能对我有什么影响？​

在审查了这些 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 设置时，这同样会禁用沙盒。 这是可以理解的：如果您长期以来一直与我们在一起，您可能已经享受了在运行 HTML/CSS 的同一代码中抛出 require("child_process") 或 require("fs") 的强大功能。

在我们讨论如何迁移到沙盒之前，让我们首先讨论您为什么需要它。

沙盒在所有渲染器进程周围设置了一个硬性隔离区，确保无论内部发生什么，代码都在受限环境中执行。 作为一个概念，它比 Chromium 早得多，并且由所有主要的操作系统作为一项功能提供。 Electron 和 Chromium 的沙盒构建在这些系统功能之上。 即使您从不显示用户生成的内容，您也应该考虑您的渲染器可能受到攻击的可能性：供应链攻击等复杂的场景以及小错误等简单的场景都可能导致您的渲染器执行您并非完全打算让它执行的操作。

沙盒使这种情况变得不那么可怕：内部进程可以自由使用 CPU 周期和内存 - 仅此而已。 进程无法写入磁盘或显示自己的窗口。 在我们的 libwep 错误的情况下，沙盒确保攻击者无法安装或运行恶意软件。 事实上，在最初的 Pegasus 攻击员工 iPhone 的案例中，攻击专门针对非沙盒图像进程以获取对手机的访问权限，首先突破了通常沙盒化的 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. 由于启用沙盒会禁用 preload 脚本中的 Node.js 集成，因此您无法再使用 require("../my-script")。 换句话说，您的 preload 脚本需要是单个文件。

   有多种方法可以做到这一点：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 中的漏洞，请发送电子邮件至 security@electronjs.org。

在 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 beta 版本跟踪 Chromium 73，因此已经过修补

• 5.0.0-beta.5

更多信息​

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

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

如果您想报告 Electron 中的漏洞，请发送电子邮件至 security@electronjs.org。

发现了一个代码漏洞，该漏洞允许在子窗口中重新启用 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 版本，您可以禁用所有子 Web 内容来缓解此问题

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

更多信息​

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

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

如果您想报告 Electron 中的漏洞，请发送电子邮件至 security@electronjs.org。

一个远程代码执行漏洞，“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 中的漏洞，请发送电子邮件至 security@electronjs.org。

一个远程代码执行漏洞已被发现，该漏洞会影响在 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 事件进行 blanket-calling 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 of Contrast Security 发现并负责任地报告给了 Electron 项目。

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

如果您想报告 Electron 中的漏洞，请发送电子邮件至 security@electronjs.org。

发现了一个漏洞，该漏洞允许在某些禁用 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 中的漏洞，请发送电子邮件至 security@electronjs.org。

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

发现了一个远程代码执行漏洞，该漏洞会影响使用自定义协议处理程序的 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 中的漏洞，请发送电子邮件至 security@electronjs.org。

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

我们发布了 electron 的两个新版本 1.7.8 和 1.6.14，这两个版本都包含了针对此漏洞的修复程序。我们强烈建议所有 Electron 开发者立即将其应用程序更新到最新的稳定版本。

npm i electron@latest --save-dev

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

如果您想报告 Electron 中的漏洞，请联系 security@electronjs.org。