AuroraOSモバイルオペレーティングシステムの開発者 （Open Mobile Platform社によって開発されたSailfishオペレーティングシステムのフォーク） 脆弱性の修正を共有しました 彼らがmemcpyで検出したこと。 重大な脆弱性の排除（CVE-2020-6096) Glibcで、ARMv7プラットフォームでのみ表示されます。
脆弱性に関する情報はXNUMX月に明らかになりました、しかし最後の日まで、脆弱性に高レベルの危険性が割り当てられていたにもかかわらず、修正は利用できませんでした エクスプロイトの実用的なプロトタイプがあります これにより、コードの実行を整理できます。
準備されたエクスプロイト memcpy（）およびmemmove（）関数での処理中に機能します 特定のフォーマットされたデータの場合。
Glibcの重要性は、このライブラリがほとんどすべてのプログラムで使用されることに加えて、システムコールやその他の基本的な関数を定義することです。
問題について
脆弱性が顕在化 memcpy（）とmemmove（）の実装で ARMv7のアセンブリ言語で そしてそれは、領域のサイズを決定するパラメータの負の値の誤った処理によって引き起こされました。
パッチ開発の問題が始まりました SUSEとRedHatがプラットフォームに影響がないと発表したとき 問題が原因で、7ビットARMv32システム用にコンパイルされず、パッチの作成に参加しなかったためです。
多くの組み込みディストリビューションの開発者は明らかにGlibcチームを信頼しており、パッチの準備にも積極的に参加していませんでした。
ソリューション
Huaweiはオプションを提供しました パッチ用 問題をほぼ即座にブロックするには、 これは、符号付きオペランド（bgeおよびblt）で動作するアセンブラ命令を符号なしアナログ（bloおよびbhs）に置き換えようとしました。
Glibcメンテナはテストスイートを開発しました エラーの発生についてさまざまな条件をテストするには、 Huaweiのパッチが適合しないことが判明しました また、入力データのすべての可能な組み合わせを処理するわけではありません。
ことを考えると AuroraOSにはARM用の32ビットビルドがあります、その 開発者は自分で脆弱性を閉じることにしました コミュニティに解決策を提案します。
難しさは、効果的な実装を書く必要があるということでした 関数のアセンブラであり、入力引数のいくつかのオプションを検討します。
実装は、符号なしの命令を使用して書き直されました。 パッチは小さいことが判明しましたが、主な問題は、入力値のすべての組み合わせとの互換性を維持しながら、実行速度を維持し、memcpyおよびmemmove関数からパフォーマンスの低下を取り除くことでした。
XNUMX月の初めに、XNUMXつのソリューションが準備されました。 GlibcのメンテナンステストフレームワークとAuroraの内部テストスイートに合格しています。 3月XNUMX日に、オプションのXNUMXつが選択され、送信されました Glibcメーリングリストに。
XNUMX週間後、Huaweiが以前に修正を試みたマルチアーチ実装の問題を修正する別の同様のアプローチが提案されました。 パッチの重要性を考慮して、テストと合法化にXNUMXか月かかりました。
8月XNUMX日、メインブランチで修正が受け入れられました 今後のglibc2.32リリースの アプリケーションにはXNUMXつのパッチが含まれています。
- ARMv7用のメモリ確立Multiarchアプリケーションの最初のもの
- XNUMXつ目は、ARM用のmemcpy（）とmemmove（）の一般的なアセンブラー実装です。
この問題は、何百万ものARMv7Linuxデバイスに影響を及ぼします また、適切な更新がないと、所有者はネットワークに接続するリスクがあります（サイズ制限なしで入力を受け入れるネットワーク上で利用可能なサービスやアプリケーションが攻撃される可能性があります）。
たとえば、準備されたエクスプロイト 研究者によって 脆弱性を発見し、httpサーバーを攻撃する方法を示しています 非常に大きなGET要求を送信し、システムへのルートアクセスを取得することにより、自動車情報システムに統合されます。
DebianとUbuntuのパッケージソリューションはまだリリースされていません y 脆弱性は修正されないままです 公開されてからほぼXNUMXか月間、Glibc開発者に通知されてからXNUMXか月間。