iOS上のCoreGraphicsの重大なバグ

この記事では、iOSのCoreGraphicsの重大なバグを探します(そして特徴的に見つけます!)。 私はすぐに、このバグが本格的な脆弱性を引き付けるものではないことをすぐに言わなければなりません-その操作は、たとえば、任意のコードの実行につながりません。 ただし、このバグにより、WebKitを使用するアプリケーション(モバイルSafari、iOS向けGoogle Chrome、あらゆる種類のメールクライアントなど)をクラッシュさせることができます。 それでは、検索を始めましょう。



バグ検索



このサンドボックスを検索に使用します。





WebKitまたはWebKitが使用するシステムライブラリのバグを探します。 さらに苦労せずに、私たちはよく知られた道を進みます:



  1. 現在使用されていないが、WebKitでまだサポートされている古代のマルチメディア形式を見つけます。
  2. この形式のファザーを作成し、WebKitを使用する一部のアプリケーション(Mobile Safariなど)で実行して、お茶を飲みに出かけます。
  3. ...
  4. 利益?!..そうでない場合は、手順1に戻ります。


最初の段落から始めましょう。 ウィキペディアで大騒ぎし、WebKitがサポートする画像形式を調べた後、 XBMに注目します。 これは、巨大なたわごとと同じくらい古い白黒画像用のテキスト形式ですが、WebKitはそれをまだサポートしています。 XBMは長年にわたってWebの誰にも使用されていないため、WebKitの開発者は、エンジン内の対応するコードをテストして「なめる」ことを長い間忘れている可能性があります。 そのため、このコードで古い未解決のエラーを探すことができます。



さて、フォーマットを決定しました。 バグを見つけるための計画の2番目のポイントに進みましょう。 XBM形式の説明を読んでから、ネットワーク上で.xbm



ファイルを見つけ、WebKitまたはWebKitが使用するシステムライブラリでエラーを引き起こすように「台無し」にしようとします。 短い検索の後、私はこのファイルに出会いました:



  #define test_width 16
 #define test_height 16
 static unsigned char test_bits [] = {
      0xff、0xff、0x01、0x80、0xfd、0xbf、0x05、0xa0、0xf5、0xaf、0x15、0xa8、
      0xd5、0xab、0x55、0xaa、0x55、0xaa、0xd5、0xab、0x15、0xa8、0xf5、0xaf、
      0x05、0xa0、0xfd、0xbf、0x01、0x80、0xff、0xff};


このファイルをMobile Safariで開くと、同心の正方形の小さな画像(16 x 16ピクセル)が表示されます。





確かに、この目的のために特別に書かれたファザーでこのファイルを「台無しにする」方が良いのですが、ファザーは書くのが面倒なので、まずは手で古い方法でファイルを「台無しにする」ことを試みます。 test_width



test_height



test_width



みましょう-突然WebKitは画像をレンダリングするときにこれらの値をチェックせず、どこかでオーバーフローするものを取得できますか? test_width



test_height



にゼロまたは負の値をtest_width



とすると、残念ながら何もtest_height



ません。 ただし、すぐに大きな値でtest_width



Mobile Safariがクラッシュすることがわかります! たとえば、そのようなファイルを開こうとすると



  #define test_width 123456
 #define test_height 16
 static unsigned char test_bits [] = {
      0xff、0xff、0x01、0x80、0xfd、0xbf、0x05、0xa0、0xf5、0xaf、0x15、0xa8、
      0xd5、0xab、0x55、0xaa、0x55、0xaa、0xd5、0xab、0x15、0xa8、0xf5、0xaf、
      0x05、0xa0、0xfd、0xbf、0x01、0x80、0xff、0xff};


Mobile Safariは、メッセージなしで閉じます。 iOS向けGoogle Chromeも同じように動作します。 両方のブラウザがWebKitを使用していることを考えると、WebKit自体またはWebKitが画像のレンダリングに使用するシステムライブラリのいずれかでバグを見つけたようです。



バグ分析



それでは、バグは正確にどこに存在し、どのように配置されますか? アプリがクラッシュするのはなぜですか? デバッガーの下でMobile Safariで「破損した」ファイルを開き、バックトレースを確認します。





CoreGraphics



argb32_image_mark



関数を詳しく見てみましょう。バックトレースによって判断すると、アプリケーションがドロップするのはmemset



を呼び出すためです。 デバッガーでMobile Safariを再度起動し、ブラウザー.xbm



画像幅123456



.xbm



ファイルを.xbm



場合のargb32_image_mark



関数.xbm



ます。 そして、次のことが起こります(バグに関係のないコードはスキップされ、アドレスはASLRによるバックトレースのスクリーンショットのものとは異なることに注意してください):



  CoreGraphics`argb32_image_mark(0x2f96a970で):
 ...
 0x2f96a97a:mov r6、sp;  r6 = sp
 0x2f96a97c:mov r5、r0;  r5 =最初の引数argb32_image_mark
 ...
 0x2f96a9a0:ldr r0、[r5、#4];  r0 = [最初の引数+ 4] =画像の幅
 ...
 0x2f96a9b0:str r0、[r6、#100]; 画像の幅をローカル変数に保存する
 ...
 0x2f96a9d2:ldr r3、[r1、#12];  r3 = [2番目の引数+ 12]
 ...
 0x2f96a9ea:ldr r1、[r6、#100];  r1のローカル変数から画像の幅を取得します
 ...
 0x2f96a9f6:r0、r3、#6を追加。  r0 = r3 + 6
 0x2f96a9f8:ミュールr0、r1、r0;  r0 = r1 * r0
 0x2f96a9fa:add.w r2、r0、#96;  r2 = r0 + 96
 ...
 0x2f96aa04:r0、r2、#3を追加。  r0 = r2 + 3
 0x2f96aa06:bic r0、r0、#3;  r0 = r0&0xfffffff8
 0x2f96aa0a:sub.w r11、sp、r0;  r11 = sp-r0
 0x2f96aa0e:mov sp、r11;  sp = r11


これらの指示に従った後、新しいsp



値は



  sp = sp-(([2番目の引数+ 12] + 6)*画像の幅+ 99)&0xfffffff8


ただし、開いていない画像が何であれ、 [ + 12]



は常にゼロでした。 この事実を考えると、



  sp = sp-(6 *画像の幅+ 99)&0xfffffff8


argb32_image_mark



関数argb32_image_mark







パラメーターargb32_image_mark



うまく制御できません。幅が大きすぎる場合、 sp



は選択されたスタックの境界をはるかに超えて「残されます」。 次に、 memset



呼び出しがすぐに続き、スタックをはるかに超えるメモリをゼロにしようとすると、アプリケーションがクラッシュします。



  0x2f96aa10:mov r0、r11; 新しいsp値はmemsetのアドレスです
 0x2f96aa12:movs r1、#0; このアドレスから始まるゼロ化メモリ
 0x2f96aa14:blx 0x2fa339cc;  memsetを呼び出す
 ...


実際、これはCoreGraphicsの重大なバグであり、記事のタイトルで説明されています。



どこで機能しますか?



私のバグは、モバイルSafariおよびiOS用Google Chromeで再生されます





他のデバイス/ iOSのバージョンは試していません。 コメントとプライベートメッセージには、バグが再現されていることも書いています





iOSデバイスでSafariをクラッシュさせたい場合は、次のリンクをご覧ください。



codedigging.com/test.xbm



結論



バグはもちろん重大ですが、セキュリティの観点からは、ユーザーにとってそれほど怖いものではありません。 発生する最大値.xbm



を使用するこのアプリケーションは、 .xbm



画像を噛むことができず、 .xbm



ます。 不快だが致命的ではない。



Appleでは、次のiOSアップデートですべてが修正されることを願っています。



ハッピーデバッグ!



2014年6月20日更新:今日、Apple secチームからメールが届きました。 彼らは、エラーが考慮され、CVEが割り当てられ、次のiOSアップデートで修正されると書いています。 「半年は過ぎません...」(c)



2014年6月30日更新



  APPLE-SA-2014-06-30-3 iOS 7.1.2

 iOS 7.1.2が利用可能になり、以下に対処します。

 ...

 Coregraphics
対象:iPhone 4以降、
 iPod touch(第5世代)以降、iPad 2以降
影響:悪意を持って作成されたXBMファイルを表示すると、
予期しないアプリケーションの終了または任意のコードの実行
説明:制限のないスタック割り当ての問題が存在しました
 XBMファイルの処理。 この問題は改善された方法で対処されました
境界チェック。
 CVE-ID
 CVE-2014-1354:codedigging.comのDima Kovalenko 


うーん、OK、iOS 7.1.2で修正。 よくやった、cho :)



All Articles