Aurora モバイル オペレーティング システム (Open Mobile Platform 会社が開発した Sailfish OS のフォーク) の開発者は、モバイル オペレーティング システムの削除に関する暴露話を共有しました。 () Glibc では、ARMv7 プラットフォームでのみ表示されます。 この脆弱性に関する情報は XNUMX 月に公開されましたが、脆弱性が存在するという事実にもかかわらず、最近まで修正は利用できませんでした。 これは危険レベルが高く、memcpy() および memmove() 関数で特定の方法でフォーマットされたデータを処理するときにコードの実行を組織化できるエクスプロイトの実用的なプロトタイプが存在します。 パッケージの修正 и はまだリリースされておらず、この脆弱性は公開の瞬間からほぼ XNUMX か月間、Glibc 開発者に通知された瞬間から XNUMX か月間修正されないままです。
この脆弱性は、ARMv7 のアセンブリ言語での memcpy() および memmove() の実装に現れ、コピー領域のサイズを決定するパラメータの負の値の誤った処理が原因で発生しました。 パッチ開発の問題は、企業が и は、自社のプラットフォームは 32 ビット ARMv7 システム向けにビルドされていないため、この問題の影響を受けないと発表し、修正プログラムの作成には参加していません。 多くの組み込みディストリビューションの開発者は Glibc チームに依存しているようで、修正の準備にも積極的に関与していません。
オプション この問題を阻止するために、ファーウェイはほぼ即座に、符号付きオペランド (bge および blt) で動作するアセンブリ命令を符号なしの類似物 (blo および bhs) に置き換えることを提案しました。 Glibc のメンテナーはさまざまなエラー状態をチェックする一連のテストを開発しましたが、その後、Huawei のパッチが適切ではなく、入力データの考えられるすべての組み合わせを処理していないことが判明しました。
Aurora OS は ARM 用の 32 ビット ビルドであるため、その開発者は独自に脆弱性を解決し、コミュニティにソリューションを提供することを決定しました。 難しかったのは、関数の効率的なアセンブリ言語実装を作成し、入力引数のさまざまなオプションを考慮する必要があることでした。 実装は、署名のない命令を使用して書き直されました。 結果的には小さいことが判明しましたが、主な問題は、入力値のすべての組み合わせとの互換性を維持しながら、実行速度を維持し、memcpy 関数と memmove 関数のパフォーマンス低下を回避することでした。
3 月初めに、Glibc メンテナーのテスト フレームワークと Aurora の内部テスト スイートに合格した XNUMX つのバージョンの修正が準備されました。 XNUMX 月 XNUMX 日、選択肢の XNUMX つが選択され、 Glibc メーリング リストに送信してください。 一週間後
それでした 同様のアプローチの別のパッチは、ファーウェイが以前に修正しようとしていたマルチアーチ実装の問題を修正しました。 テストにはXNUMXか月かかりましたが、 パッチの重要性のため。
8月XNUMX日の訂正 今後の glibc 2.32 リリースのメイン ブランチに追加します。 実装にはXNUMXつのパッチが含まれています- ARMv7 の memcpy のマルチアーキテクチャ実装用、および ARM 用の memcpy() および memmove() の一般的なアセンブリ言語実装用。
この問題は、Linux を実行している数百万台の ARMv7 デバイスに影響しており、適切なアップデートがなければ、デバイスをネットワークに接続するときに所有者が危険にさらされます (サイズ制限なしで入力データを受け入れるネットワーク アクセス可能なサービスやアプリケーションが攻撃される可能性があります)。 たとえば、この脆弱性を特定した研究者が作成したエクスプロイトでは、非常に大規模な GET リクエストを送信して自動車情報システムに組み込まれた HTTP サーバーを攻撃し、システムへの root アクセスを取得する方法が示されています。
出所： オープンネット.ru