スマホ関連の海外ニュースです。
ペガサス iOS のカーネルの脆弱性 CVE-2016年-4656 先週からこのブログの記事のパート 1 で読むことができます私たちの分析の後がずっとあるカーネルの脆弱性について新しい発見の問題: OSUnserializeBinary() は、報告されたアラスカの脆弱性を修正するアップルが今年の 5 月に一度すでにパッチされているが発見されています。そのパッチは終了報告されていた脆弱性 CVE-2016年-1828 年に発行された 2016 年 1 月 11 日にアップルにブランドン アザドで。この脆弱性に関する詳細な書き込みはこちらです。述べる UAF トリガーは 9 と OS X 10.11 iOS の前に周りはコードであることが発見されました。ペガサスが伝えられる以前の iOS バージョンと互換性があるのでアップルもそれはそれにそうする以前の OS X のバージョンをパッチを述べる UAF トリガーはペガサスの本当の脅威を使用して 1 つです。両方のこれらの詳細を通知され、我々 の分析は、この情報を組み込むには少し更新を書き込みしました。 お知らせ戻って一歩を踏み出すし、iOS 9.0 の前に OSUnserializeBinary() と OS X 10.11 のコード見てください。上記のコードから見ることができる: 前に iOS 9.0 と OS 10.11 ディクショナリ キーの日 OSSymbol オブジェクトと OSString コード パスが追加されていなかった、まだ。これは、我々 の分析で説明した UAF トリガーだろうこの古いバージョンのコードで動作しない事を意味します。さらにこのコードをより慎重に見て我々 の分析の詳細に比較すると古いバージョンのコードで setObject() への呼び出しが 3 の代りに 2 つのパラメーターを持っていたことがわかります。上記のコードは、CVE-2016年-1828年のセキュリティ修正を行う前に、はためにです。私たち今の詳細については、上記のコードを見て、どのようなコードパス UAF 状態が発生することができますを見つける: このコードで UAF 条件をトリガーする最初の方法は CVE-2016年-1828 年として知られているもの: ライン 398 が辞書のキーの k1 に設定オブジェクト o1 が広がります o1 の参照カウンター、ライン 399 オブジェクト o1 の (2) に 1 つによって k1 が解放される参照の 1 行にカウンターを減少させる400 オブジェクト k1 1 はこの時点ですべてがうまくまだ参照を辞書次のオブジェクト o2 は逆シリアル化し、ディクショナリに挿入するときに両方のオブジェクトを保持するために参照カウンターを減少させる (sym) をリリースしても、同じキー k1 を再利用しながら並んで 398 setObject() メソッドは辞書の o2 と o1 を置き換えられます。交換中 o1 の参照カウンターが 0 に 1 つ減少します。彼のポイントの o1 ではメモリから解放されます。デシリアライザーは、このオブジェクトへの参照を作成する場合再度それは、アラスカであります。このコードで UAF 条件をトリガーする 2 番目の方法はペガサス (CVE-2016年-4656) によって使用される実際のトリガーは、: 行 398 はしません setObject() 我々 は挿入しようとしているオブジェクト o は dict 自体 setObject() がない場合への参照を実行 o の参照カウンターと sym がされていること場合増加線 399 呼び出しが o より大きいまたは 1 に等しい値の参照カウンターを減少 (のでそれ辞書への参照をあった) ライン 400 は (シンボルだった場合など奇妙なランダムな文字列) OSSymbol オブジェクト sym が破棄されるこの時点でほとんど 0 に sym の参照カウンターに減少が後にこの点は、UAF オブジェクト シンボルへの参照を作成しようとします。IOS 9 の前にコードを見ることができる OS X 10.11 すでに 2 つの独立したが、非常に関連 UAF トリガーした上でそれと。つまり、一緒にそこにこのブログの記事の第 1 部に記載されている 3 番目のコードパスはのみ 20 行のコードで 3 つの UAF トリガーした上をされています。 5 月にアップルが CVE-2016年-1828 年の修正プログラムをリリースするときコードに加え彼ら唯一の変更は、真の setObject() メソッドの呼び出しの 3 番目のパラメーターを追加するでした。これは、1 つは設定済み辞書のキーを上書きしようとした場合にするにうちコード エラーが保証されます。したがってもうブランドン アザド報告 UAF 状況をトリガーできません。残念ながらこれはアップルに十分でした、彼らはこの時点で OSUnserializeBinary() の安全なコード レビューを実行しなかった。それ以外の場合 release() も早く objsArray からオブジェクトを解放し、したがって UAF はトリガーされる可能性がありますコード内への直接呼び出しの数があった熟練コード監査役を実現しているでしょう。これがあります啓示につながる追加するだけ本当 setObject に 3 番目のパラメーターは、不完全な修正されました。しかしアップルは、セキュリティ更新プログラムのセキュリティ レビューを実行しなかったまたは他の release() 呼び出し関数を見ていない誰でもはそれを帯びていた。したがって、それらの 20 行のコードで他の 2 つの UAF のトリガーされる可能性がありますまだカーネルを悪用し、システムを充分に浸透させます。今ペガサスは、アップルがパッチを失効しているために、そのそれら 20 行ものコードを修正する上より多くのエネルギーを過ごすよう発見された後彼らは CVE-2016年-1828年の行なったし、代わりにもはや release() 途中で (を除いて後エラー、一時的な変数のクリーンアップ) 関数への呼び出しを持つように関数を再構築します。代わりに objsArray からすべてのオブジェクトは、結果を返す直前に関数の最後の最後で解放を得る。そのように参照カウンターは、逆シリアル化中に 0 にドロップことできます。逆コンパイルされたパッチをここで適用と OSSerializeBinary.cpp のソース コードを検索できます。差分を見てすることができますか:/* ****************************************** */場合 (idx > = v ##Capacity) {-uint32_t ncap = v ##Capacity + 64; -typeof(v##Array) nbuf = (typeof(v##Array)) kalloc_container (ncap * sizeof(o)); 場合 – (! nbuf) ok = false; 場合 – (##Array v) -{-bcopy (##Capacity v、nbuf v ##Array * sizeof(o)); -kfree (##Array v、##Capacity v * sizeof(o)); -} -v ##Array = nbuf; -v ##Capacity ncap; = + if (v ##Capacity < 最大) { + uint32_t ncap = v ##Capacity + 64; + typeof(v##Array) nbuf = (typeof(v##Array)) kalloc_container (ncap * sizeof (o)); + if (! nbuf) ok = false; + if (##Array v) + { + bcopy (##Capacity v、nbuf v ##Array * sizeof(o)); + kfree (##Array v、##Capacity v * sizeof(o)); +} + v ##Array = nbuf; + v ##Capacity = ncap; +} 他 ok = false;} 場合 ([ok]) v ##Array [idx] = o;ケース kOSSerializeObject: 場合 (len > = objsIdx) を破るo = objsArray [レン];isRef = 真;破る;ケース kOSSerializeNumber: bufferPos + = sizeof (長い)。値 = 次 [1]。値 < = 32;値 | 次へ [0] =ケース kOSSerializeSymbol: bufferPos + = (wordLen * sizeof(uint32_t));場合 (0! = ((const char *)next)[len-1]) ブレーク;o = (OSObject *) OSSymbol::withCString ((const char *) 次);次の + = wordLen;場合 (! isRef) {objsIdx + +;}{場合 (sym) {+ OSSymbol * sym2 = OSDynamicCast (OSSymbol、sym); + if (! sym2 && (str = OSDynamicCast (OSString、sym))) + {+ sym2 = (OSSymbol *) OSSymbol::withString(str); + [ok] = (sym2! = 0); + if (! sym2) を破る +} + + 場合 (o! dict を =) ok = setObject (sym2, o);-> dict + 場合 (sym2 && sym2! = sym) {+ release();-> sym2 +}} 他 {}} 他の場合 (配列) {ok = setObject(o);-> 配列} 他の場合 (セット) {ok = setObject(o);-> セット + +} + 他の場合 (結果) + {+ ok = false;} 他 {場合 (! 終わり) {stackIdx + +; 場合 (! ok) 破る;}DEBG (“+ + スタック [%d] %p”、stackIdx、親);}}}{結果 = 0;}+ if (objsCapacity) {+ uint32_t; + (私 = (結果ですか? 1:0); 私 < objsIndx; i++) {+ release();-> objsArray [i] +} + kfree (objsArray、objsCapacity * sizeof(*objsArray)); +} + if (stackCapacity) kfree (stackArray、stackCapacity * sizeof(*stackArray)); + リターン (結果);} 最後の 2 週間で多くのセキュリティ専門家は、野生で積極的に悪用されているペガサスの脅威を高速反応雷の Apple を賞賛しています。当事者の独立した第 3 からのサンプルを保持パーティー研究者と一般にカーネルの脆弱性関与に関する詳細な情報を明らかにしなかったので、このような賞賛が与えられました。この情報がなければ公開だけでペガサス監視マルウェアは、買収の iOS デバイスに完全に新しいカーネルの脆弱性を使用していた、2016年 8 月半ば初めてこれらの問題について聞いた、アップルと仮定。残念ながらペガサス監視マルウェアによって使用されたどのようなカーネルの脆弱性を持つ逆後完全に異なる画像が現れる: 質問アップルは、コードのセキュリティ レビューを行わず 2016 年 5 月に CVE-2016年-1828年をパッチするため CVE-2016年-4656 にあったコードにのみまだとして知られているカーネルの脆弱性。のみ 20 行のコードで 3 つした上は、UAF をできる存在していた。アップルは、他の release() メソッドが明らかにそれ隣のコードにこれらのパスの 1 つだけ固定。さらにペガサスの今のパッチはコードの少しのデザインと、アップルは同時にすべての 3 つの問題を解決することを示しています。これは、UAF 後実現しなかった巨大な監督は、1 月にブランドン アザドによって報告されていた考えています。アップルは、別の方法で CVE-2016年-1828年を固定していた場合 CVE-2016年-4656 ろう abusable 野生の。残念なことに、これはアップルがセキュリティ修正プログラムをしくじったの初めてではありません。SektionEins は、2 年間何度も繰り返しアップルをやり損ったセキュリティ パッチのこの厄介な問題を強調しています。当然この QA のアップル社のセキュリティ パッチの欠如を強調私たちアップルでない友達ができているし、代わりに iOS AppStore から SysSecInfo セキュリティ アプリケーションの終了に 。ここで全文を読むことができます。最終的な思考の: ブランドン アザド CVE-2016年-1828 年にペガサスの CVE-2016年-4656 ペガサスで使用されるカーネルのバグは困難と考えて見たことを参照 (検索) とブランドン アザドによって見つかったバグよりも攻略が困難。ペガサスで使用される悪用 CVE-2016年-1828 年の修正プログラムが既にリリースされたそうでなければバグを利用しやすくなると思います発見されて、選ばれたので前に書き込まれていないことを信じさせます。つまり、いずれかの CVE-2016年-1828年がペガサスの前の化身に使われていたことや誰かが逆に CVE-2016年-1828 年と修正が完了したことを発見しました。しかし、これらは単なる推測であり、私たちの仮定は完全に間違っている可能性が。
続きを読む…
PEGASUS iOS Kernel Vulnerability Explained – Part 2
After our analysis of the PEGASUS iOS kernel vulnerability CVE-2016-4656 from last week that you can read in part one of this blog post there have been new discoveries about the kernel vulnerability in question: It has been discovered that OSUnserializeBinary() has already been patched once in May of this year by Apple to fix a reported UAF vulnerability. That patch was issued to close the vulnerability CVE-2016-1828 that had been reported by Brandon Azad to Apple on 11th January 2016. A detailed write up about this vulnerability is available here.
Read more…
