シスコのセキュリティ研究者 細部 () 32 ビット ARMv7 プラットフォーム用に Glibc が提供する memcpy() 関数の実装。 この問題は、符号付き 32 ビット整数を操作するアセンブリ最適化の使用により、コピー領域のサイズを決定するパラメーターの負の値が正しく処理されないことが原因で発生します。 ARMv7 システムで負のサイズを指定して memcpy() を呼び出すと、値の比較が正しく行われず、指定されたバッファの境界外の領域に書き込みが行われます。
この脆弱性は、攻撃者がコピーされたデータのサイズを送信する変数の負の値の形成を組織できる状況 (たとえば、2 GB を超えるデータを転送すると負の値になる) でコードを実行するために悪用される可能性があります。ただし、攻撃中にバッファ制限を超えるには、少なくとも 4GB を転送する必要があります)。 memcpy() 関数はアプリケーションで広く使用されており、ARMv7 プロセッサは、Bluetooth、HD ラジオ/DAB、USB、CAN バス、 Wi-Fi Fi およびその他の外部データ ソース (たとえば、サイズ制限なしで入力データを受け入れるネットワーク経由でアクセスできるサービスやアプリケーションが攻撃される可能性があります)。
一例としては、自動車情報システムに組み込まれ、自動車 Wi-Fi ネットワーク経由でアクセスできる HTTP サーバーを攻撃するための実用的なエクスプロイトの作成が挙げられます。 外部の攻撃者は、非常に大規模な GET リクエストを送信することで、このサーバーの memcpy の脆弱性を悪用し、システムへの root アクセスを取得する可能性があります。
32 ビット x86 システムでは、このアーキテクチャの memcpy 実装はサイズ変数を size_t 型 (アセンブリ言語の) の符号なし整数値として正しく解釈するため、問題は発生しません。 ARMv7 の場合、size_t ではなく符号付き整数として扱われます。 この修正は現在次のように利用可能です 、これは 2.32 月の Glibc XNUMX アップデートに含まれる予定です。
この修正は、要約すると、符号付きオペランド (bge および blt) を操作するアセンブリ命令の使用を、符号なしのオペランド (blo および bhs) に置き換えることです。
問題はまだ解決されていません (Debian 8 では表示されません)、 , 、OpenEmbedded、Tizen (glibc によって使用)。 и 32 ビット ARMv7 システムはサポートされていないため、この問題は影響を受けません。 Android は独自の libc (Bionic) 実装を使用しているため、この脆弱性の影響を受けません。 で デフォルトでは、ほとんどのビルドは Musl を使用しますが、glibc もリポジトリで使用できます。
出所： オープンネット.ru