今週のダイジェストでは、以下をご紹介します。
- OpenSSL バージョン 3.0.0 のセキュリティアドバイザリです。
- Sqlite の配列境界のオーバーフローの脆弱性。
- GitHubのレポジャックアタック。
Openssl セキュリティアドバイザリ
OpenSSL3.0.0は、最近2つの脆弱性に対応しました。CVE-2022-3602とCVE-2022-3786の2つの脆弱性に対応しました。
CVE-2022-3602 は、Critical (9.8/10) と評価されており、4 バイトのスタックバッファオーバーフローがあり、 DoS または Code Execution につながる可能性があります。この問題を解決するには、ターゲットが悪意のある証明書のX509検証、特に名前の制約チェックを実行する必要があります。攻撃者は、悪意のある電子メールアドレスを細工して、スタック上の攻撃者が制御する4バイトをオーバーフローさせることができます。この攻撃は、最新のオペレーティングシステムで一般的に有効なスタックオーバーフロー保護機能によって阻止される可能性があるとのことです。この脆弱性は、当初OpenSSLによって「クリティカル（Critical）」とされましたが、さらなる分析により、深刻度は「ハイ（High）」にダウングレードされました。本稿執筆時点では、基本スコアは9.8（重大）です。
CVE-2022-3786 は、高評価 (7.5/10) で、悪意のある TLS 証明書によって引き起こされる、もう一つのバッファオーバーフローです。前述の脆弱性と同様に、この攻撃は、攻撃者が悪意のある電子メールアドレスを持つ証明書を細工することを伴います。この脆弱性の違いは、オーバーフローを引き起こすために使用できる文字にあり、「...」文字（10進数46）に限定され、サービスクラッシュまたはサービス拒否につながります。
OpenSSL 3.0 を利用しているユーザーは、できるだけ早く最新バージョンにアップグレードすることを推奨します。このブログ記事は、ユーザの環境で脆弱性のあるバージョンのライブラリが使用されているかどうかを判断するのに役立つ可能性があります。
Sqlite の Array-bounds Overflow 脆弱性
TrailofBitsは、最近パッチが適用された一般的なDBMSライブラリSqliteに存在する深刻度の高い脆弱性を公開しました。この脆弱性に割り当てられたCVEは、CVE-2022-35737で、評価は7.5/10です。
この脆弱性はSQLite 1.0.12から3.39.2以前の3.39.xにおける配列のオーバーフローであり、SQLiteライブラリを使用するアプリケーションに影響を及ぼします。 API.悪用可能かどうかはSQLiteのコンパイル方法に依存し、スタック・カナリアが有効になっていないプログラムがコンパイルされた場合、コードが実行される可能性があります。この脆弱性は2000年10月17日にリリースされたv1.0.12で導入されました。
ソースによると、"脆弱なシステムにおいて、CVE-2022-35737 は、大きな文字列入力が SQLite の実装である printf 関数に渡され、フォーマット文字列に %Q、%q、%w のフォーマット置換型が含まれる場合に悪用されます。" とのことです。これにより、攻撃対象が減り、アプリケーションが実際にこの脆弱性を悪用される可能性が低くなりますが、ユーザーは、コンポーネントの使用状況に応じてリスクを評価することを強く推奨します。
パッチが適用された SQLite バージョン v3.39.2 は、ユーザーが自分のアプリケーションでアップグレードできるようになっています。脆弱性のある SQLite ライブラリを使用するツールに依存しているユーザーは、コードのメンテナからパッチがリリースされるのを待つ必要があります。Trailofbitsは、GitHubで公開されているエクスプロイトのPOCも公開しています。
Githubレポジャッキング
Checkmarxは、github.comでホストされているコードリポジトリを標的としたサプライチェーンへの新たな攻撃方法を公開しました。この攻撃は、レポジャッキングと呼ばれ、この種の攻撃のためにマイクロソフトが設定した既存のセキュリティ制御をバイパスして、リポジトリを乗っ取ることが含まれます。この制御は「popular-repository-namespace-retirement」と呼ばれ、基本的にGitHubユーザーは、ユーザー名変更までの1週間以内にリポジトリのクローンが100個以上あった場合、同じユーザー名で無効化したユーザーが以前使用していたものと同じ名前のリポジトリを作成できないようにするものである。2021年にcheckmarxが同様の脆弱性を公開していたことを受け、GitHubが緩和策として実装したもの。
今回の攻撃は、リポジトリ転送と呼ばれるgithubの機能を利用することで、この緩和策を回避しています。以下は、その攻撃の進め方です。
- "victim/repo" は、"popular repository namespace retirement" の保護下で引退したGitHubの人気レポジトリです。
- 「helper_account "は "repo "リポジトリを作成します。
- "helper_account" は "repo" リポジトリの所有権を "attacker_account" に移譲する。
- "attacker_account "のユーザー名を "victim "に変更する。
- 新しい「被害者」アカウント（以前は「攻撃者アカウント」）は所有権の移転を受け入れ、実質的にターゲットリポジトリを引き継ぎます。
この脆弱性に対する修正が適用されました。Checkmarxは、どのようなgolangの直接の依存関係がこの種の攻撃に対して脆弱であるかをチェックするツールもリリースしています。
コメント