Open VSXの脆弱性により悪意のある拡張機能が公開される

Open VSX拡張機能マーケットプレイスで最近明かされた脆弱性により、新たに導入された公開前スキャンパイプラインに重大な脆弱性が露出し、悪意のある拡張機能がセキュリティチェックを回避して「PASSED」として公開されることが可能になっていました。

「Open Sesame」と非公式に呼ばれるこの問題は、2月8日に責任を持って報告され、3日以内に修正されました。これはバグの重大性とOpen VSXの対応性チームの両方を強調しています。

このシステムは、拡張機能をマルウェア、埋め込まれたシークレット、疑わしいバイナリ、および名前の乗っ取り試行についてスキャンし、公開前にチェックするよう設計されていました。

パイプラインは構造化されたフローに従っていました。アップロード後、拡張機能は非アクティブのままで、2つのスキャンフェーズを経過していました。迅速な同期チェックの後、非同期バックグラウンドスキャンが行われていました。

すべてのスキャナーが合格した後、拡張機能はダウンロード用にアクティブ化されていました。スキャナーが問題にフラグを立てた場合、拡張機能はレビューのために隔離されていました。

この設計は、すべてのセキュリティチェックに合格することなくユーザーに拡張機能が到達しないことを保証することを目的としていました。しかし、微妙なロジック脆弱性がこの保証を損なっていました。

この脆弱性の核は、スキャンロジックで使用されるブール値の戻り値でした。この値は2つの非常に異なる条件を表していました。

両方のシナリオが同じ値を返していたため、システムはそれらを区別できませんでした。スキャナージョブが失敗した場合(特に高負荷時)、システムはこれを「スキャンするものはない」と解釈し、自動的に拡張機能を承認していました。

バグはExtensionScanService.javaが結果をどのように報告するか、およびその呼び出し元がそれをどのように解釈するかに存在しています。そしてこれがPublishExtensionVersionHandler.javaの呼び出し元です。

その結果、拡張機能は「PASSED」とマークされ、アクティブ化され、実際のセキュリティチェックを経ることなく公開ダウンロード可能にされていました。

この問題はさらに、失敗したスキャンを再試行することを目的とした復旧サービスの類似したロジックによって悪化していました。つまり、フォールバック機構も問題を検出して修正できませんでした。

この脆弱性を悪用するには、特別な権限は必要ありませんでした。無料の発行者アカウントを持つすべてのユーザーがこれを試みることができました。

攻撃者は、複数の悪意のある拡張機能をパッケージングして標準.vsixファイルとして配布し、公開APIに大量に送信することができました。

各アップロードがスキャンジョブの作成とキューを発生させ、これは共有データベース接続に依存していました。高負荷下では、システムのジョブスケジューラはリソースの枯渇によりスキャンタスクをキューに登録できませんでした。

これらの失敗は静かにキャッチされて無視され、ゼロのスキャナージョブが登録されることになりました。システムは曖昧な「false」値を返し、呼び出し元はそれを成功したスキャン条件と解釈していました。

結果:悪意のある拡張機能が公開され、検証済みとしてラベル付けされていました。

テストにより、この失敗オープン条件は制御された負荷条件下で確実にトリガーできることが確認されました。本番環境では、タイミングはより厳しくなりますが、攻撃者はコストやレート制限なしにプロセスを繰り返し試行できます。

主なリスクは、悪意のある拡張機能がユーザーに合法的に見える可能性があったため、UIにスキャンがスキップされたという表示がなかったことです。これは開発者エコシステム内で重大なサプライチェーンリスクを生じさせていました。

OpenVSXチームはこの脆弱性を閉じるのに素晴らしい仕事をしました。直ちに対応し、3日で修正しました。

Open VSXは2月11日に曖昧なブール値ロジックを削除し、失敗状態が明確に処理されるようにしてこの問題に対処しました。修正により、スキャナーの失敗がもはや自動承認につながらないことが保証されます。

このインシデントは、セキュリティシステムの一般的だが危険な設計脆弱性を強調しています。曖昧なエラーハンドリングによって引き起こされるフェイルオープン動作です。

「何もする必要がない」と「アクションが失敗した」が同じ結果を共有すると、セキュリティ制御がストレス下で崩壊する可能性があります。

同様のパイプラインを構築する開発者は、失敗状態が明確に区別され、保守的に処理されることを確認する必要があります。セキュリティに敏感なワークフローでは、失敗は承認ではなく拒否がデフォルトであるべきです。

翻訳元: https://cyberpress.org/open-vsx-vulnerability/

ソース: cyberpress.org