标签为“安全”的 10 篇文章

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

我们不认为这些 CVE 是出于善意提交的。首先，声明是错误的 —— 该配置并**不**启用远程代码执行。其次，尽管有漏洞赏金计划，但这些 CVE 中提到的公司并未收到通知。最后，虽然我们确实认为禁用相关组件会增强应用程序的安全性，但我们不认为这些 CVE 被赋予了正确的严重性。“关键”级别保留给最高危险的问题，这里显然不是这种情况。

任何人都可以申请 CVE。虽然这对软件行业的整体健康有益，但“刷 CVE”来抬高某个安全研究员声誉的做法是不可取的。

尽管如此，我们理解带有吓人的 critical 严重性级别的 CVE 的存在可能会导致最终用户困惑，因此作为一个项目，我们希望提供处理此问题的指导和帮助。

这会如何影响我？​

在审查了这些 CVE 后，Electron 团队认为它们并非关键漏洞。

攻击者需要已经能够在机器上执行任意命令，无论是通过物理访问硬件还是已经实现完全的远程代码执行。这一点值得重申：所描述的漏洞*要求攻击者已经拥有对被攻击系统的访问权限*。

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

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

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

我是否受到影响？​

默认情况下，所有已发布的 Electron 版本都启用了 runAsNode 和 enableNodeCliInspectArguments 功能。如果您尚未按照 Electron Fuses 文档中的说明将其关闭，您的应用程序同样容易被用作“living off the land”攻击的载体。再次强调，我们需要着重指出，攻击者需要*已经*能够在受害者的机器上执行代码和程序。

缓解措施​

缓解此问题的最简单方法是在您的 Electron 应用程序中禁用 runAsNode fuse。runAsNode fuse 控制是否遵守 ELECTRON_RUN_AS_NODE 环境变量。有关如何切换这些 fuse 的信息，请参阅 Electron 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 设置时同样会禁用沙盒。这是可以理解的：如果您与我们在一起很久了，您可能享受过在运行 HTML/CSS 的同一代码中加入 require("child_process") 或 require("fs") 的强大功能。

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

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

沙盒让这种情况不那么可怕：内部进程可以自由使用 CPU 周期和内存——仅此而已。进程不能写入磁盘或显示自己的窗口。在我们遇到的 libwep 漏洞情况下，沙盒确保攻击者无法安装或运行恶意软件。实际上，在针对员工 iPhone 的原始 Pegasus 攻击中，攻击者专门针对未沙盒化的图像处理进程来获取手机访问权，首先突破了通常沙盒化的 iMessage 的边界。当宣布像本例中这样的 CVE 时，您仍然必须将您的 Electron 应用程序升级到安全版本 — 但在此期间，攻击者能造成的损害程度将大大受限。

将一个普通的 Electron 应用程序从 sandbox: false 迁移到 sandbox: true 是一项工作。我知道，因为即使我自己亲手写了 Electron 安全指南的初稿，我也未能将自己的一个应用程序迁移到使用沙盒。这个周末我做到了，我也建议您这样做。

你需要解决两件事

1. 如果您在 preload 脚本或实际的 WebContents 中使用了 Node.js 代码，您需要将所有这些 Node.js 交互移至主进程（或者，如果您想要更高级，可以使用一个 utility process）。考虑到渲染器已经变得多么强大，您的绝大多数代码很可能实际上不需要重构。

   查阅我们关于进程间通信的文档。就我而言，我移动了很多代码，并将其封装在 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 威胁分析小组 (Threat Analysis Group) 的 Clement Lecigne 发现并报告给 Chrome 团队。Chrome 博客文章可在此处找到。

要了解有关如何保证 Electron 应用程序安全性的最佳实践，请参阅我们的安全教程。

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

发现了一个代码漏洞，允许在子窗口中重新启用 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 版本，您可以通过禁用所有子 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

目前没有报告此漏洞已被用于实际攻击；但是，建议受影响的应用程序采取缓解措施。

更多信息​

此漏洞由腾讯玄武实验室 (Tencent Blade team) 发现，他们发布了一篇讨论此漏洞的博客文章。

要了解有关如何保证 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 事件上普遍调用 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 中的漏洞，请发送电子邮件至 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 事件并手动覆盖 event.newGuest 而不使用提供的 options 标签

尽管这看起来只影响少数 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。