
バグ検索
このサンドボックスを検索に使用します。
- iPhone 4
- evasi0n脱獄付きiOS 7.0.4
- LLDB +デバッガーとしてのdebugserverバンドル
WebKitまたはWebKitが使用するシステムライブラリのバグを探します。 さらに苦労せずに、私たちはよく知られた道を進みます:
- 現在使用されていないが、WebKitでまだサポートされている古代のマルチメディア形式を見つけます。
- この形式のファザーを作成し、WebKitを使用する一部のアプリケーション(Mobile Safariなど)で実行して、お茶を飲みに出かけます。
- ...
- 利益?!..そうでない場合は、手順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 7.0.4を搭載したiPhone 4
- iOS 7.0.6を搭載したiPhone 5(このデバイスとiOSバージョンのバグはYekverによっても確認されています。以下のリストを参照してください)
他のデバイス/ iOSのバージョンは試していません。 コメントとプライベートメッセージには、バグが再現されていることも書いています
- iOS 6.1.5(10b400)を搭載したiPod Touch 4g-テストに感謝します。
- iOS 7.0.6を搭載したApple iPad mini-テストを行ったPavel Akhrameevに感謝
- iOS 7.0.4を搭載したiPad mini Retina-テストに感謝します
- iOS 7.0.6を搭載したiPad mini Retina-テストのmaxruに感謝
- iOS 7.0.4を搭載したiPad Air-テストをありがとうryad0m
- iOS 7.0.6を搭載したiPad Air-テストをありがとうryad0m
- iOS 5搭載のiPhone 5-テストにシルバンスキーに感謝
- iOS 7.0.6を搭載したiPhone 5-テストを提供してくれたYekverに感謝
- 最新のiOS 7.1を搭載したiPhone 5s-テストに対してAnakrosに感謝
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 :)