"Security"タグ付きの投稿10件

本日早朝、Electronチームは、いくつかの注目すべきElectronアプリに対して最近公開された複数のCVEについて警告を受けました。これらのCVEは、ElectronのヒューズであるrunAsNodeとenableNodeCliInspectArgumentsの2つに関連しており、これらのコンポーネントが積極的に無効化されていない場合、リモート攻撃者がこれらのコンポーネントを介して任意のコードを実行できると誤って主張しています。

これらのCVEは善意で報告されたとは考えていません。まず、その記述は正しくありません。この設定はリモートコード実行を有効化しません。第二に、これらのCVEで指摘された企業は、バグバウンティプログラムを持っているにもかかわらず、通知を受けていません。最後に、問題のコンポーネントを無効にすることはアプリのセキュリティを強化すると考えていますが、CVEの深刻度は正しくないと考えています。「クリティカル」は、最も危険性の高い問題に予約されており、ここでは明らかにそうではありません。

誰でもCVEをリクエストできます。これはソフトウェア業界全体の健全性にとって良いことですが、単一のセキュリティ研究者の評判を高めるためにCVEを「集める」ことは役立ちません。

とは言っても、「クリティカル」という恐ろしい深刻度を持つCVEが存在するだけで、エンドユーザーの混乱につながる可能性があることを理解しています。そのため、プロジェクトとして、この問題に対処するためのガイダンスと支援を提供したいと思います。

どのような影響があるか​

CVEをレビューした結果、ElectronチームはこれらのCVEはクリティカルではないと考えています。

攻撃者は、ハードウェアへの物理的なアクセスがあるか、完全なリモートコード実行を達成しているかのいずれかで、既にマシン上で任意のコマンドを実行できる必要があります。繰り返しますが、説明されている脆弱性は、攻撃者が既に攻撃対象のシステムにアクセスしている必要があります。

たとえば、Chromeは物理的なローカル攻撃を脅威モデルに含めていません

Chrome（または他のアプリケーション）では、ユーザーとしてデバイスにログインできた、またはオペレーティングシステムのユーザーアカウントの権限でソフトウェアを実行できる悪意のあるユーザーに対して防御する方法がないため、これらの攻撃をChromeの脅威モデルの外部と見なしています。そのような攻撃者は、実行可能ファイルやDLLを変更し、PATHなどの環境変数を変更し、設定ファイルを変更し、ユーザーアカウントが所有するデータを読み取り、自身にメールを送信するなど、さまざまなことができます。そのような攻撃者はデバイスを完全に制御しており、Chromeが実行できることは何も、防御の確実な保証を提供することはできません。この問題はChrome特有のものではありません。すべてのアプリケーションは、物理的にローカルにいるユーザーを信頼する必要があります。

CVEで説明されているエクスプロイトにより、攻撃者は影響を受けたアプリを、継承されたTCC権限を持つ一般的なNode.jsプロセスとして使用できるようになります。たとえば、アプリがアドレス帳へのアクセス権限が付与されている場合、攻撃者はアプリをNode.jsとして実行し、そのアドレス帳へのアクセス権限を継承する任意のコードを実行できます。これは一般的に「Living off the land（LOTL）攻撃」として知られています。攻撃者は通常、PowerShell、Bash、または同様のツールを使用して任意のコードを実行します。

影響を受けますか？​

デフォルトでは、リリースされているすべてのバージョンのElectronでrunAsNodeとenableNodeCliInspectArguments機能が有効になっています。Electronヒューズのドキュメントで説明されているようにオフにしていない場合、アプリは「Living off the land」攻撃に使用されるのと同じように脆弱です。繰り返しますが、攻撃者は犠牲者のマシンでコードとプログラムを既に実行できる必要があることを強調する必要があります。

軽減策​

この問題を軽減する最も簡単な方法は、Electronアプリ内でrunAsNodeヒューズを無効にすることです。runAsNodeヒューズは、ELECTRON_RUN_AS_NODE環境変数が尊重されるかどうかを切り替えます。Electronヒューズのドキュメントを参照して、これらのヒューズの切り替え方法を確認してください。

このヒューズを無効にすると、メインプロセスでのprocess.forkは、機能するためにこの環境変数に依存しているため、期待通りに機能しなくなります。代わりに、スタンドアロンのNode.jsプロセス（Sqliteサーバープロセスなどのシナリオ）が必要な多くのユースケースで機能するユーティリティプロセスの使用をお勧めします。

Electronアプリに関して推奨するセキュリティベストプラクティスに関する詳細は、当社のセキュリティチェックリストをご覧ください。

CVE-2023-4863: WebPのヒープバッファオーバーフローが公表されてから1週間以上が経過し、webp画像をレンダリングするソフトウェアの新しいリリースが相次いでいます。macOS、iOS、Chrome、Firefox、そして様々なLinuxディストリビューションがアップデートを受けました。これは、Citizen Labによる調査に端を発し、「ワシントンD.C.を拠点とする市民団体」が使用していたiPhoneが、iMessage内のゼロクリック攻撃を受けていたことが判明したことに伴うものです。

Electronも同様に迅速に対応し、同日に新しいバージョンをリリースしました。アプリでユーザー提供のコンテンツをレンダリングしている場合は、Electronのバージョンをアップデートする必要があります。v27.0.0-beta.2、v26.2.1、v25.8.1、v24.8.3、v22.3.24には、webp画像のレンダリングを担当するライブラリlibwebpの修正版が含まれています。

「画像のレンダリング」という無害な操作にも潜在的な危険性があることを改めて認識した今、Electronには次の大規模な攻撃（それが何であれ）の影響範囲を制限するプロセスサンドボックスが備わっていることを皆さんにお知らせしたいと思います。

サンドボックスはElectron v1から利用可能であり、v20でデフォルトで有効になりましたが、多くのアプリ（特に長期間運用されているアプリ）では、コードのどこかにsandbox: false、あるいは明示的なsandbox設定がない場合にサンドボックスを無効にするnodeIntegration: trueがあることは承知しています。これは理解できます。長年Electronをご利用いただいている方は、HTML/CSSを実行するコードにrequire("child_process")やrequire("fs")を自由に使用できる強力さを享受してきたでしょう。

サンドボックスへの移行方法について説明する前に、まずなぜサンドボックスが必要なのかについて説明します。

サンドボックスはすべてのレンダラプロセスを厳格に保護し、内部で何が起こっても、コードは制限された環境内で実行されるようにします。これはChromiumよりも古い概念であり、主要なオペレーティングシステムすべてで機能として提供されています。ElectronとChromiumのサンドボックスは、これらのシステム機能の上に構築されています。ユーザー生成のコンテンツを表示しない場合でも、レンダラが侵害される可能性を考慮する必要があります。サプライチェーン攻撃のような高度なシナリオから、小さなバグのような単純なシナリオまで、意図しない動作をレンダラが行う可能性があります。

サンドボックスによって、そのようなシナリオのリスクは大幅に軽減されます。内部のプロセスは、CPUサイクルとメモリを自由に使用できます。それだけです。プロセスはディスクに書き込んだり、独自のウィンドウを表示したりすることはできません。libwepのバグの場合、サンドボックスは攻撃者がマルウェアをインストールまたは実行できないようにします。実際、従業員のiPhoneに対する最初のPegasus攻撃では、攻撃はサンドボックス化されていない画像プロセスを特に標的にし、通常はサンドボックス化されているiMessageの境界を最初に突破して、電話へのアクセス権を取得しました。この例のようなCVEが発表された場合でも、安全なバージョンにElectronアプリをアップグレードする必要がありますが、その一方で、攻撃者が行える被害の量は劇的に制限されます。

sandbox: falseからsandbox: trueへの標準的なElectronアプリケーションの移行は、簡単な作業ではありません。Electronセキュリティガイドラインの最初のドラフトを書いた私自身ですが、自分のアプリの1つを移行して使用することはできていませんでした。それがこの週末に変わりました。皆さんにも変更することをお勧めします。

対処すべき点が2つあります。

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を使用できます。

全体として、このプロセス全体に約4日間かかりました。これには、Webpackの巨大な能力をどのように処理するかを頭を悩ませた時間も含まれています。他の多くの方法でコードをリファクタリングする機会を利用したためです。

Electronを含むChromiumベースのすべてのソフトウェアに影響を与える高深刻度の脆弱性がChromeで発見されました。

この脆弱性には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までメールでお知らせください。

Electronを含むChromiumベースのすべてのソフトウェアに影響を与える高深刻度の脆弱性がChromeで発見されました。

この脆弱性には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のThreat Analysis GroupのClement Lecigne氏によって発見され、Chromeチームに報告されました。Chromeのブログ記事はこちらにあります。

Electronアプリの安全性を確保するためのベストプラクティスについて詳しくは、当社のセキュリティチュートリアルをご覧ください。

Electronの脆弱性を報告する場合は、security@electronjs.orgまでメールでお知らせください。

子ウィンドウでNode.jsを再度有効にすることができるコードの脆弱性が発見されました。

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の脆弱性を報告する場合は、security@electronjs.orgまでメールでお知らせください。

すべてのバージョンのElectronを含む、SQLiteまたはChromiumベースのソフトウェアに影響を与えるリモートコード実行の脆弱性「Magellan」が発見されました。

影響範囲​

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チームによって発見され、脆弱性について説明するブログ記事を公開しています。

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());

子ウィンドウが孫ウィンドウを作成する機能に依存している場合は、3つ目の軽減策として、最上位ウィンドウで次のコードを使用します。

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の脆弱性を報告する場合は、security@electronjs.orgまでメールでお知らせください。

Node.jsの統合を無効にしている一部のElectronアプリケーションで、それを再度有効にできる脆弱性が発見されました。この脆弱性には、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までメールでお知らせください。

最新のすべてのElectronバージョンに影響を与えるGoogle Chromiumでリモートコード実行の脆弱性が発見されました。sandboxオプションが有効になっているかどうかに関係なく、リモートコンテンツにアクセスするElectronアプリはすべて、このエクスプロイトの影響を受けます。

この脆弱性を修正したelectronの新しいバージョン1.7.8と1.6.14を2つ公開しました。すべてのElectron開発者は、直ちに最新の安定版にアプリを更新することを強くお勧めします。

npm i electron@latest --save-dev

Electronアプリの安全性を確保するためのベストプラクティスについて詳しくは、当社のセキュリティチュートリアルをご覧ください。

Electronの脆弱性を報告する場合は、security@electronjs.orgまでご連絡ください。