Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (20)
Similar to Jurczyk windows metafile_pacsec_jp3
Similar to Jurczyk windows metafile_pacsec_jp3 (20)
More from PacSecJP
Jurczyk windows metafile_pacsec_jp3
- 2. PS> whoami • GoogleのProject Zero 所属 • 脆弱性の研究とソフトウェアエクスプロイトに興味がある低レイヤー のセキュリティ研究者 • hAp://j00ru.vexillium.org/ • @j00ru
- 3. アジェンダ • Windows メタファイル入門、GDIデザイン、攻撃ベクタ • ハック対象: • Internet Explorer (GDI) • Windows Kernel (ATMFD.DLL) • MicrosoV Office (GDI+) • VMware virtualiza[on (プリントスプール) • 結論
- 4. Windows GDI & メタファイル入門
- 5. Windows GDI • GDI はGraphics Device Interface（グラフィックス・デバイス・インターフェイス）の略 • ユーザーモードアプリケーションで、グラフィックや整形されたテキストをビデオ ディスプレイやプリンターへの出力を可能にする • システムAPIの大半を占める (約 300 のドキュメント化された機能) • 初期のOSの頃から存在 (1985年にリリースされたWindows 1.0 から) • 最も古いサブシステムの1つで、31年経った今でも大半は元のコードのまま稼働している • 偶然にも（？）もっともバグが多い構成要素の1つである
- 6. どのように描画するか 1. デバイスコンテキスト へのハンドル(HDC)をつかむ • 様々なグラフィカル設定（ペン、ブラシ、パレットなど）の永続的なコンテナを 認識する • スクリーン（もっとも典型的）、プリンター、メタファイルへの描画で使用可能 • 最も簡単な例: HDC hdc = GetDC(NULL); (画面全体のために HDCを取得)
- 8. Windows GDI – 簡易化したアーキテクチャ app1.exe app3.exe app4.exe app2.exe GDI+ (gdiplus.dll) User-mode GDI (gdi32.dll) Kernel-mode GDI (win32k.sys) NT OS Kernel Printer Drivers Font Drivers Display Drivers ring-3 ring-0
- 9. ユーザーモードとカーネルAPIマッピング 大半のユーザーモードGDI関数は直接対応するカーネルAPIを持って いる: GDI32.DLL win32k.sys AbortDoc NtGdiAbortDoc AbortPath NtGdiAbortPath AddFontMemResourceEx NtGdiAddFontMemResourceEx AddFontResourceW NtGdiAddFontResourceW AlphaBlend NtGdiAlphaBlend ... ...
- 11. Windows メタファイル • 長所: • GDI関数が与えられたパラメータで呼び出された時だけ、ラスタライズ処理の計算は ほとんど必要とされない • GDIが再現可能な画像を操作するための公式な方法を提供 • ベクター形式、ラスター形式また両方の形式として動作する • 短所: • サポートされているグラフィックのGDI操作が外部に完全に実装されていない場合 は、Windows上でのみ動作する
- 12. First version: WMF • 最初のメタファイル (WMF = Windows MetaFiles). • 1990年のWindows 3.0 で導入された • GDIそれ自体のほどではないが、同じくらい古典的 • はじめてドキュメント化されたのは Windows 3.1 SDK (1994年, volume 4) • 改訂され、より完全な仕様は2006年にリリース、それ以来メンテされ続けている • 全てのレコードや構造はMS-WMFドキュメントに記載されている
- 13. WMF files – サポートされている60のAPI関数 AnimatePaletteArc BitBlt Chord CreateBrushIndirect CreateDIBPatternBrush CreateFontIndirect CreatePalette CreatePatternBrush CreatePenIndirect DeleteObject Ellipse Escape ExcludeClipRect ExtFloodFill ExtTextOut FillRgn FloodFill FrameRgn IntersectClipRect InvertRgn LineToMoveToEx OffsetClipRgn OffsetViewportOrgEx OffsetWindowOrgEx PaintRgn PatBlt Pie Polygon Polyline PolyPolygon RealizePalette Rectangle ResizePalette RestoreDC RoundRect SaveDC ScaleViewportExtEx ScaleWindowExtEx SelectClipRgn SelectObject SelectPaletteSetBkColor SetBkMode SetDIBitsToDevice SetMapMode SetMapperFlags SetPaletteEntries SetPixel SetPolyFillMode SetROP2 SetStretchBltMode SetTextAlign SetTextCharacterExtra SetTextColor SetTextJustification SetViewportOrgEx SetWindowExtEx SetWindowOrgEx StretchBlt StretchDIBits TextOut
- 15. WMF: まだまだある! • このフォーマットは、GDI関数では直接の対応をしていない多くのレ コードをサポートしている. • ヘッダ情報を持つｍｅｔａｄａｔａ • 埋め込み EMF • プリンタードライバー/出力デバイスを直接扱うレコード • ファイル終端マーク • ...
- 17. Windows Metafile – 例 ... R0003: [017] META_SETMAPMODE (s=12) {iMode(8=MM_ANISOTROPIC)} R0004: [011] META_SETVIEWPORTEXTEX (s=16) {szlExtent(1920,1200)} R0005: [009] META_SETWINDOWEXTEX (s=16) {szlExtent(1920,1200)} R0006: [010] META_SETWINDOWORGEX (s=16) {ptlOrigin(-3972,4230)} R0007: [009] META_SETWINDOWEXTEX (s=16) {szlExtent(7921,-8462)} R0008: [049] META_CREATEPALETTE (s=960) {ihPal(1) LOGPAL[ver:768, entries:236]} R0009: [048] META_SELECTPALETTE (s=12) {ihPal(Table object: 1)} R0010: [052] META_REALIZEPALETTE (s=8) R0011: [039] META_CREATEBRUSHINDIRECT (s=24) {ihBrush(2), style(0=BS_SOLID, color:0x00FFFFFF)} R0012: [037] META_SELECTOBJECT (s=12) {Table object: 2=OBJ_BRUSH.(BS_SOLID)} R0013: [037] META_SELECTOBJECT (s=12) {Stock object: 8=OBJ_PEN.(PS_NULL)} R0014: [019] META_SETPOLYFILLMODE (s=12) {iMode(1=ALTERNATE)} R0015: [086] META_POLYGON16 (s=320) {rclBounds(89,443,237,548), nbPoints:73, P1(-2993,398) - Pn(-2993,398)} R0016: [038] META_CREATEPEN (s=28) {ihPen(3), style(0=PS_SOLID | COSMETIC), width(0), color(0x00000000)} ...
- 18. WMF: 今なおとても時代遅れなまま • それ自体がすでに複雑であるが、そのフォーマットは現代的な使用 法に対して考え抜かれたものになることはなかった • GDIにサポートされているが故に、いくつかのクライアントの一部に使 用されている(例： MicrosoV Office、ペイント、いくつかのWindows標 準アプリケーションなど) • ここ10年かそれ以上、実世界でのユースケースを忘れ去られていた
- 20. 次に来たもの: EMF (Enhanced MetaFiles： 拡張メタファイル) • すでに1993年に、マイクロソフトはEMFと呼ばれる改良版のイメージフォー マットをリリース • 公式のMS-EMF仕様としてドキュメント化されている • 多くの方法でWMFを上回る: • 16ビットではなく、32ビットのデータ/オフセット長を使用 • デバイスに依存しない • 古いレコードとの下位互換性を維持しながら、いくつかの新しいGDIコールをサポート
- 25. EMF: 現在のサポート • WMFのわずかに3年新しいものではあるが、EMFは今日まで使用さ れている • メインストリームの画像フォーマットではないが、有効な攻撃ベクタ • さまざまな攻撃ベクタ: • Win32 GDI クライアント – 代表は Internet Explorer • GDI+ クライアント – 代表は MicrosoV Office • プリンタードライバー、仮想化技術で使われるものも含む
- 26. ツールセット – 検査 (EMFexplorer)
- 27. ツールセット – 検査 (MetafileExplorer)
- 28. ツールセット – リーディング & ライティング (pyemf) #!/usr/bin/env python import os import pyemf import sys def main(argv): if len(argv) != 2: print "Usage: %s /path/to/poc.emf" % argv[0] sys.exit(1) emf = pyemf.EMF(width = 100, height = 100, density = 1) emf.CreateSolidBrush(0x00ff00) emf.SelectObject(1) emf.Polygon([(0, 0), (0, 100), (100, 100), (100, 0)]) emf.save(argv[1]) if __name__ == "__main__": main(sys.argv)
- 29. 最新: EMF+ • GDIはすべて基本的な機能を備えているが、多くの複雑な機能に欠ける (アンチエイリアシング、浮動小数点座標、JPG/PNGのサポートなど) • WIndows XPは2001年にGDI+と呼ばれる高度なライブラリーを導入 • 大部分はGDI（gdi32.ｄｌｌ）の上に、ユーザーモードgdiplus.dll ライブラリが作られた • C++ や.NET 向けに高レベルのインターフェースを提供するため、容易に使用可能 • GDI+はそれ自体C++で書かれているため、典型的なメモリー破損バグが未だに存在
- 30. 最新: EMF+ • 新しいインターフェースがあるため、新しい画像フォーマットとそのシリアライズさ れた呼び出しが必要とある • EMF+にあいさつ! • 基本的にはEMFと同じだが、GDI+の呼び出しを表す • 2種類ある: EMF+ Only と EMF+ Dual • „Only”は専用のGDI+レコードが含まれ、そしてGDI+でのみ表示することができる • „Dual”はGDI/GDI+クライアント両方と互換性があり、2つのレコードセットが保存されている
- 32. Windowsでのフォーマットと実装 • 考慮すべきは3つのフォーマット: WMF, EMF, EMF+ • 3つのライブラリ: GDI, GDI+ , MF3216 • vMF3216.DLL は1つの重要な機能を提供するシステムライブラリ: ConvertEmfToWmf • Windowsのクリップボード内のWMF/ EMFフォーマット間の自動変換する際に使用 • „Synthesized” formats CF_METAFILEPICT と CF_ENHMETAFILE • ここにはバグは無かった. L
- 33. Windowsでのフォーマットと実装 Library Supported formats GDI WMF, EMF GDI+ WMF, EMF, EMF+ MF3216 EMF 今回の話では、最も（興味深い）問題が見つかったEMFに対する 監査とエクスプロイトにフォーカスする
- 34. 攻撃シナリオ • 全ての場合において、メタファイルは対応するDLLでレンダラープロセスのユーザモードコンテキスト として処理される • GDI, GDI+,MF3216は全てのレコード入力に対し繰り返しGDI/GDI+の呼び出しに変換する • メモリ破損のバグは、そのコンテキストで任意のコード実行につながる • 重要: メタファイルはレンダラーのGDIコンテキストを直接操作する • プロセスの代わりとして、作成、削除、変更や、さまざまなGDIオブジェクトを使用することができる • 理論的には、自身のオブジェクトにのみアクセスすべきであり、自己完結である必要がある • しかし、実装のバグはプログラムによって使用される外部グラフィックスオブジェクトへのアクセスを可能にする • „権限昇格”の特異なケース
- 35. 攻撃シナリオ: GDI による権限昇格 renderer.exe GDI objects EMF #2 GDI objects EMF #3 GDI objects EMF #1 file EMF #1 GDI objects GDI プロセス EMF #2 file EMF #3 file セキュリティ境界
- 36. 攻撃シナリオ: GDI による権限昇格 renderer.exe GDI objects EMF #2 GDI objects EMF #3 GDI objects EMF #1 file EMF #1 GDI objects GDI プロセス セキュリティ境界
- 37. メタファイルのバグのタイプ 1. メモリ破損のバグ • バッファオーバーフローなど特定レコードの誤った取り扱いによるもの • レンダリングのいずれかのタイプのエクスプロイトの可能性 • 影響: 典型的なリモートからのコード実行(RCE) 2. メモリ漏えいのバグ • 初期化されていないレンダリング、境界外のヒープメモリーをイメージとして扱う • 画像のみを表示するコンテキストでは裏を読むことができる (Webブラウザ、リモートレンダラー) • 影響: 情報漏えい (秘密情報を盗む、ASLRの突破など) 3. OSとGDIオブジェクトの誤った管理による不正な相互作用 • 影響、悪用可能性 = ???、バグの種類による
- 38. 始めよう！ • 今年の初めから、利用可能なEMFの実装について監査を始めた • 結果として、MicrosoVから 10のCVE、VMWareから3つのCVEを見つ けた (実際の数十のバグをカバーする) • 根本原因と、最も面白いエクスプロイトについてもう少し深く見よう • レイトして32-bit Windows 7に基づいて示しているが、ほとんどの調査内容は Windows10までの両方のビットバージョンにも適用できる
- 39. GDIの監査
- 41. SetAbortProc WMF バグ (CVE-2005-4560) • 2005/12/27に見つかり、 2006/1/5に修正された • 致命的なバグであり、GDIを使ったエクスプロイトを動かすと100%確実に RCEが出来た (例えば Internet Explorer上) • „Windows メタファイルの 脆弱性”と呼ばれ Pwnie Award 2007を受賞 • メモリー破損は関係無く、WMFの文書化された機能を使用 • なにがバグだった？
- 43. ... そして WMF 側では
- 47. EMF バグとは? • „emf vulnerability”の検索でより多彩な結果が見つかる • 最新のもの: Hossein LoViによる„Yet Another Windows GDI Story” • MS15-035の一部として2015年4月に修正、CVE-2015-1645が割り当てられた • レコードの1つ(SETDIBITSTODEVICE) の入力である „size”の未検証による、 ヒープベースのバッファオーバーフロー • EMFセキュリティを見るには大部分はインスピレーション（が必要）
- 48. 学んだこと • EMFレコードを再生するためのメインファンクション gdi32! PlayEnhMetaFileRecord • 各レコードタイプはそれぞれ2つの独自のクラスをもっている: • ::bCheckRecord() – レコードの内部整合性と正確さをチェック • ::bPlay() – レコード内に示されたアクションを実行
- 51. ここからが出発点
- 52. Impact: File Existence Informa[on Disclosure Record: EMR_CREATECOLORSPACE, EMR_CREATECOLORSPACEW Exploitable in: Internet Explorer CVE: CVE-2016-0168 google-security-research entry: 722 Fixed: MS16-055, 10 May 2016 CVE-2016-0168
- 53. マイナーバグ #1 in EMR_CREATECOLORSPACEW • 小さいけど明らかなバグを見ることでコードの品質がすぐに認識できた • MRCREATECOLORSPACEW::bCheckRecord() レコードのサイズが 0x50バイ ト以上であるこをとチェック: .text:7DB01AEF mov eax, [esi+4] .text:7DB01AF2 cmp eax, 50h .text:7DB01AF5 jb short loc_7DB01B1E • その後すぐに、オフセット0x25Cの.cbData フィールドを読み込む: .text:7DB01AF7 mov ecx, [esi+25Ch] • その結果: 0x20Cバイトの範囲外を読み込む
- 54. マイナーバグ #2 in EMR_CREATECOLORSPACEW • その後、無効オフセット0x25Cの.cbDataはレコード長のチェックに使われ る: .text:7DB01AF7 mov ecx, [esi+25Ch] .text:7DB01AFD add ecx, 263h .text:7DB01B03 and ecx, 0FFFFFFFCh .text:7DB01B06 cmp eax, ecx .text:7DB01B08 ja short loc_7DB01B1E • 上記は以下の様に変換できる: if (... && record.length <= ((record->cbData + 0x263) & ~3) && ...) { // Record valid. }
- 55. マイナーバグ #2 in EMR_CREATECOLORSPACEW • 2つの問題がここに: 1. 明らかな整数オーバーフローにより、大きな.cbDataがチェックを通過 する 2. なぜレコード長は、宣言されたデータよりも小さいのだろうか？それ は大きくあるべきだ！ • データはそれ以降の処理で使用されていないので、幸いそんなに大 きな問題にはなっていない
- 56. マイナーバグ #3 in EMR_CREATECOLORSPACEW • ユーザ定義 LOGCOLORSPACEW 構造体の .lcsFilename バッ ファーはヌル終端のチェックをしていない • 文字列のアクセス中に範囲外を読みだされる可能性がある • あきらかなように、多くの未チェックの前提データが多く実装されてお り、これまではマイナーという扱いであった • これらはより深刻ななにかにつながるという予測
- 58. CreateColorSpaceWの内側 • この関数はカラープロファイルパスを組み立てるのに内部で使用される gdi32!BuildIcmProfilePath • 提供されるファイル名が相対的である場合、システムのディレクトリ・パスに追加される • それ以外の場合は、絶対パスがそのまま残されている • 全てのパスは"/"または""の2文字で始まるものを除き認められている: if ((pszSrc[0] == '' || pszSrc[0] == '/') && (pszSrc[1] == '' || pszSrc[1] == '/')) { // Path denied }
- 59. CreateColorSpaceWの内側 • これは多分“”プレフィックスで始まるパスは例えば 192.168.1.13C Userstestprofile.icc のようにリモートUNCのパス指定を想定している • しかし, James Forshawはこのチェックが有効でないことを書き示している, “??”のようなプレフィックスでも表記ができるため • チェックは容易に回避できた: ??192.168.1.13CUserstestprofile.icc
- 61. 結果 • その結果, CreateFileW() の呼び出しは任意のパスにすることが できる • 成功すれば、カラースペースオブジェクトが作成され、関数が成功を返す • 失敗した場合は、GDIオブジェクトが作成されず、ハンドラーが失敗を返す • 情報公開の可能性に聞こえる • 例えば Internet Explorerでのエクスプロイトにはどのようにアプローチをすれ ばいい?
- 62. 直感的な方法: 戻り値をリーク • CreateFileW()の戻り値がレコード処理の成功を決定することから、 少しリークできるのではないか？ • 最初のアイデア: 描画操作に続いて EMR_CREATECOLORSPACEを最初のレ コードとして使用 • ( <canvas> タグで決定することができる)描画が行わなければ, 呼び出しは 失敗
- 63. 直感的な方法: 戻り値をリーク • 残念ながら不可能 • 関数 (PlayEnhMetaFile 自身によって呼び出される) gdi32! _bInternalPlayEMF は1つのレコードが失敗した時にレコード処理は中 断しない • „success” のフラグが FALSEにセットされ, 機能が次のプロセスに進む • 全てのレコードが常に実行され、戻り値は少なくともプロセス中の1つのレ コードの失敗したかどうかのフラグを示している
- 64. 最終的な戻り値をリークすることはできない？ • あまりできない • PlayEnhMetaFile の戻り値は Internet Explorer の mshtml! CImgTaskEmf::Decode:によって破棄される .text:64162B49 call ds:__imp__PlayEnhMetaFile@12 .text:64162B4F or dword ptr [ebx+7Ch], 0FFFFFFFFh .text:64162B53 lea eax, [esp+4C8h+var_49C]
- 66. GDI オブジェクト使用時の制限 • Windowsの全てのプロセスは、標準で GDIオブジェクトが最大 10,000に制限されている • 数はレジストリで変更できる、しかしIEのためのものではない • 10,000のファイルパス付きEMR_CREATECOLORSPACEWレコードを確認したいときには: • ファイルが存在するとき、10,000のカラースペースオブジェクトはプロセスの限界に達する • ファイルが存在しないときは、カラースペースを全く持たない • 限界に達しているかどうかという時、（もうひとつ）ブラシを作成しペイントをすると: • ファイルが存在するとき、ブラシの作成は失敗し標準のブラシが使用される • ファイルが存在しないとき、ブラシは作成されペイントに使用される
- 68. デモ
- 69. 脆弱性のインパクト • 任意のファイル存在情報が漏えいし、多くの目的で利用可能: • 標的型の攻撃の際に、特定のソフトウェア（およびバージョン）がインストー ルされていることを特定できる • （既知のファイルに基づいてプロファイルを作成することで）ユーザを追跡 • オフラインドキュメントのオープンした時間を追跡（例としてMicrosoVOfficeで 開く度にSMB経由でリモートサーバにpingを送るなど） • ユーザが利用可能なネットワーク共有を探し出す
- 70. Impact: Memory disclosure Record: Mul[ple records (10) Exploitable in: Internet Explorer CVE: CVE-2016-3216 google-security-research entry: 757 Fixed: MS16-074, 14 June 2016 CVE-2016-3216
- 71. デバイス独立ビットマップ (DIBs) Windows GDIでは、ラスタビットマップは メモリ上でDIB形式で格納されている: • オプションパレットに続いてイメージの基 本的なメタデータを含むショートヘッダが ある • 画像データそのもの BITMAPINFO BITMAPINFOHEADER RGBQUAD bmiColors[...]; Bitmap data 11142211142211142 21114221114221114 22111422111422111 42211142211142211 14221114221114221 11422111422101321 10132110132110132 11013211013211013 211013210F12200F1 2200F12200F12200F 12200F12200F12200
- 74. そんなに簡単な操作なのか？ • biSize はサニタイズする必要がある (ほんの1-2個の有効な値になれるだけ) • biWidth, biHeight, biPlanes, biBitCount は整数オーバーフローを起こす可能性 がある (お互いに掛け合わすので) • biHeight はボトムアップビットマップを示すために負の値を指定できる • biPlanes は1でなければならない • biBitCount は {1, 2, 4, 8, 16, 24, 32}のうちの1つでなければならない • biBitCount < 16の場合,カラーパレットを使用できる • カラーパレットのサイズはbiClrUsedに影響する
- 75. その扱いは本当に些細なのか？ • biCompression は BI_RGB, BI_RLE8, BI_RLE4, BI_BITFIELDS, ...とすることができ る • 各圧縮方式は正しく処理されなければならない • biSizeImage は実際のイメージサイズに対応している必要がある • パレットは全てのエントリーを格納できる充分な大きさが必要 • ピクセルデータバッファは全てのピクセルを情報を入れる充分な大きさが必要 • エンコードされたピクセルはヘッダの値に対応している必要がある (例えばバレットのサ イズを超えないなど)
- 76. 多くの潜在的な問題 1. ヘッダにもとづいてDIBを正しく処理をする決定木（decision tree)は 非常に複雑 2. 多くのやっかいなケースとしては保護とバグを避ける実装をする必 要がある 3. コードの様々な部分では一貫性のある取り扱いが必要
- 79. データサニタイズの責任 • 全ての場合において、ヘッダとデータが正しく適切であることをチェックする のはAPI呼び出し元の責任である • アプリケーションコードが „クローン” GDIによる DIB ハンドリングができるよ うに、完全にユーザが制御可能な入力データを渡すことは問題がある • 何だと思う？EMFは組み込みDIBを含む複数のレコードをサポートしている
- 80. DIBを含むEMFレコード • EMR_ALPHABLEND • EMR_BITBLT • EMR_MASKBLT • EMR_PLGBLT • EMR_STRETCHBLT • EMR_TRANSPARENTBLT • EMR_SETDIBITSTODEVICE • EMR_STRETCHDIBITS • EMR_CREATEMONOBRUSH • EMR_EXTCREATEPEN
- 82. EMFレコードハンドラで必要なチェック • DIBを扱う各ハンドラでは, 必須な整合性チェックが4つある: 1. cbBmiSrc はヘッダ内に収まるように充分に大きい事 2. (offBmiSrc, offBmiSrc + cbBmiSrc) は完全にレコード内に存在する事 3. cbBitsSrc はビットマップデータ内におさまるように充分に大きい 4. (offBitsSrc, offBitsSrc + cbBitsSrc) は完全にレコード内に存在する事
- 83. チェックは多くの組み合わせで欠落 Record handlers Missing checks MRALPHABLEND::bPlay MRBITBLT::bPlay MRMASKBLT::bPlay MRPLGBLT::bPlay MRSTRETCHBLT::bPlay MRTRANSPARENTBLT::bPlay #1, #2 MRSETDIBITSTODEVICE::bPlay #3 MRSTRETCHDIBITS::bPlay #1, #3 MRSTRETCHDIBITS::bPlay MRCREATEMONOBRUSH::bPlay MREXTCREATEPEN::bPlay #1, #2, #3, #4 * これはざっと見た状態; MicrosoVはもっと修正をしている可能性がある
- 84. 結果 • 欠落のチェックのために、イメージ説明の一部は、他のパーツプロセ スのアドレス空間からロードできる (例 隣接するヒープの割り当て): • DIB ヘッダ • カラーパレット • ピクセルデータ • 初期化されていないか、境界外のヒープメモリはパレットやピクセル データにより読み出される
- 85. Proof of concept • ファイルを越えたパレットエントリーの8-bpp DIB を含む EMR_STRETCHBLTレコードを使用したPoC をハックした • 結果: 集められたバイトはイメージとして表示される • 同じ画像がIEの１行に3回表示されている: • データはHTML5を使用して漏えいしたモジュールアドレスや他の機密情報などを読むことができる
- 86. デモ
- 88. GDI+ の監査
- 89. GDI+ は充分なターゲット • GDI+ はEMF と EMF+の両方をサポートする • 多くの実装は独立しているが, フォーマットのいくつかのパーツはGDIのコー ドから来ている • したがっていくつかのGDIバグはGDI+のクライアントに影響を与える • 最も主要な GDI+クライアントはMicrosoV Office 製品 • もう1度EMFレコードハンドラの全体を手動で監査してみよう
- 93. Impact: Write-what-where Record: All records opera[ng on DIBs Exploitable in: MicrosoV Office CVE: CVE-2016-3301 google-security-research entry: 824 Fixed: MS16-097, 9 August 2016 CVE-2016-3301
- 94. EMF中におけるRLE圧縮されたビットマップ • 前述のように、複数の EMF レコードはDIBを含む • DIBは4から8ビットのRLEなどの簡単な方式で圧縮ができる • ヘッダの biCompression フィールドに示される • いくつかのハンドラのコードを読むことで、8-ビット RLEはGDI+でサ ポートされていることを見つけた • RLE展開は歴史的にバグが多く見つかっている
- 96. DecodeCompressedRLEBitmap()の内部 • 2つの値は計算される: columns = abs(biHeight) bytes_per_row = abs(biWidth * (((biPlanes * biBitCount + 31) & 0xFFFFFFE0) / 8)) • 出力バッファはサイズからヒープが割り当てられる columns * bytes_per_row • バッファ長を高度にコントロール • RLE „プログラム”の解釈と実行が始まる
- 98. „最終行” 命令コード • GDI+では, 以下の様に実装: out_ptr += bytes_per_row; if (out_ptr > output_buffer_end) { // Bail out } • 境界チェックはあらゆる種類の範囲外のアクセスを防ぐために実装されている • 64ビットプラットフォーム上で正しく動作するように行われるが, 状態は本当に充 分なのか?
- 100. トリッキーなポインタ演算 • 非常に広いビットマップの場合、現在の出力ポインタからアドレス空間の終 わりまでの距離を走査線の幅よりも小さくすることができる • 式: out_ptr += bytes_per_row; その後のチェックが効果がなく, オーバーフローを引き起こす • その結果, 出力ポインタを多くの制御可能なアドレスに設定することができる
- 101. 例 • biWidth = 0x05900000 • biHeight = 0x00000017 • biPlanes = 0x0001 • biBitCount = 0x0008 • その結果、columns = 0x17 と bytes_per_row = 0x590000 • 合計バッファ サイズ = 0x7FF00000 (およそ 2 GB) • 配置アドレスの例: 0x7FFFF0020、最終位置: 0xFFEF0020
- 103. メモリアドレス空間レイアウト (EOL #1) 0x00000000 0xFFFFFFFF 0x858F0020
- 104. メモリアドレス空間レイアウト (EOL #2) 0x00000000 0xFFFFFFFF 0x8B1F0020
- 105. メモリアドレス空間レイアウト (EOL #3-22) 0x00000000 0xFFFFFFFF …
- 106. メモリアドレス空間レイアウト (EOL #23) 0x00000000 0xFFFFFFFF 0xFFEF0020
- 107. メモリアドレス空間レイアウト (EOL #24) 0x00000000 0xFFFFFFFF 0x057F0020
- 109. サマリー • 要件: PAEが有効な32-ビットプロセス • 4 GBアドレス空間全部をプログラムに使用可能にする必要がある • 結果: どこに何を書くという条件は、„どこ”以上に高度なコントロールが必要 • 特定の値を達成させるだけでなく、上書きされた領域は元の出力バッファ以下の必要あり • エクスプロイトの確実さはイメージがロードされた時のアドレス空間の状態に強く 依存する
- 110. Impact: Heap-based buffer overflow Record: EMR_EXTTEXTOUTA, EMR_POLYTEXTOUTA Exploitable in: MicrosoV Office CVE: CVE-2016-3304 google-security-research entry: 828 Fixed: MS16-097, 9 August 2016 CVE-2016-3304
- 112. EMF レコード内のDx 配列
- 114. 関数の些細なバグ • コードはDx配列が4バイトを保持するかをチェック • 4 × N バイトを保持することができれば本当に検証をすべき • 典型的なヒューマンエラーの整合性チェック • だから何? 入力値検証の問題で外の境界を読み出すだけでは？ • はい、エクストラのロジックのためにコードを呼び出さなければ
- 115. 拡張機能ロジック • MultiByteToWideChar()を使用して、stringをwide-charへ変換 • コードページは最後に選択したフォントで指定される • 全ての文字列が変換されたとき, 通常 CEmfPlusEnumState::PlayExtTextOut() が呼び出される • しかしそうでない場合は…
- 116. DBCS (ダブルバイト文字セットの)扱い • 1バイト以上で構成する文字もサポート • 以下の様に取り扱いが実装されている: • EMF レコードの正確なコピーが (同じサイズに)配置される • Dx配列の項目はオリジナルのレコードから新しいものに書き換えられる, „先 行バイト” (IsDBCSLeadByteEx() がTRUEを返す)のエントリを省略 • 新しいレコードが以降通常として処理される
- 117. コードパスに到達 • DBCSをサポートするコードページのフォントが最初に選択されなければならない • 典型的なものは CJK (中国語,日本語, 韓国語) のコードページ, 例として SHIFTJIS_CHARSET • その後,少なくとも1つの„lead byte”が含まれる影響を受けたレコードの1つは使用されなけ ればならない • その結果、境界を越えて他の配置から読み出す典型的なヒープベースのオー バーフローになる • heap massagingにより,制御した上書きを可能にする
- 121. Impact: Heap memory disclosure Record: All records handling DIBs Exploitable in: MicrosoV Office Online CVE: ? google-security-research entry: 825, 829 Fixed: MS16-???, 11 October 2016 (?) GDI+ の情報漏えいバグ
- 122. GDI+ vs DIB • GDIとは異なり, GDI+ はビットマップの取り扱いに起因する情報漏えいバ グを避けなかった • 具体的に: 1. „ビットマップの終わり”のマーカーで始まる、RLE圧縮されたビットマップのデータ ストリームでは , 画像の出力バッファ全体が初期化されていない (ジャンクヒープ データが含まれる) 2. ビットマップパレットが完全にEMFレコードに収まるようになっているかはチェックさ れない
- 124. リモートからの悪用可能性？ • ピクセルが何かに戻せるのでもないので、ヒープメモリを表示することはそんな にシリアスな状況ではない。 • インタラクティブに出来ないため、バグの唯一のターゲットはOfficeプログラム • MicrosoVに報告し、深刻度の評価と、攻撃につながる可能性についての評価を 待った • MSRC はこの事象を „vNext”としてクローズした (毎月のパッチでは修正せず, 次 期バージョンなどのタイミングで修正)
- 125. 深刻度の評価 • これは私自身が考えていた露呈問題の理解と一致しており, 決定に同意 した • P0 バグの #825 と #829 はそれぞれ7/26と8/9に解決とした • 8月の始めに, Ivan Fratric がチャットで GDI+/EMFのバグはOffice Online に おいてリモートから攻撃につながる可能性があることを伝えてきた • 私はこのプログラムの存在を知らなかった • 攻撃可能ではなかったが,特にGDI+のメモリー漏えいのバグは興味深い • EMF イメージはドキュメント内に挿入できないが, .docxには埋め込みEMFとして可能
- 127. Office オンライン • EMFイメージは毎回異なったレンダリングがされる • MicrosoVのサーバのレンダリングプロセスからリモートのメモリを読み出 せる • MSRCに再考を求めるために新しい情報を提供 • 彼らはOffice Online のシナリオは以前には考慮されていなかった, それは 修正に値するバグとされた • 10月の定例パッチまでに修正される必要があった
- 129. プリントスプールのEMF • EMF ファイルはプリントスプールに頻繁に使われる • これはプリンタドライバ (およびその他関連ソフトウェア)の形式で, フォーマットに起因する攻撃ベクタとして使用される • 1つのターゲットとしてVMware Worksta[onを選定
- 130. 仮想プリンタ • これは仮想マシンからホストを通してドキュメントの印刷を可能にする昨日 (基本的には プリンタの共有) • 実現可能なVM回避の攻撃ベクタ • T私の知る限りでは, 2015年まではデフォルトで有効であったが, 現在は有効ではない (Kostya Kortchinskyが報告したバグが役立った) • いまだ頻繁に使用するオプション
- 132. 構造 • 攻撃プロセスは vprintproxy.exe が稼働するホスト • ゲストシステムで非特権プロセスによって送信され、ほぼそのままのデータ を受信します • 通信のチャンネル • データは EMFSPOOL ファイルの形式で送られる • EMFと同様に, 追加オプションを指定して、様々な形式のフォントを埋め込む ことができる
- 133. TPView • 特に, 最も興味深いEMF処理は TPview.dllで行われる • その他プリンタに関するライブラリは, すべてサードパーティのThinPrintで開 発がされていると思われる • いくつかのレコードタイプの特殊処理は, GDIに処理が戻る • 全ては簡単なバグではあったが, Kostya は（ほぼ）全てを見つけた! • 他を見ていたら, ダブル・フリーと out-of-bounds memset()を見つけた, それ らは (問題 #848 と #849)に含まれる
- 134. JPEG2000 デコード • 完全に未調査であった最後のカスタムEMFレコード • ID = 0x8000 • デバッグ文字列に基づいて,それらは JPEG2000のデコードに関してのもので ある • JPEG2Kの専門家でもないので, コードは手動検査にとっては便利で はないように見えた • ファジングしてみる？
- 135. ファジングによるアプローチ • ベストなファジング: Linux上で, スケールで, AddressSani[zerを使用してカバレッ ジフィードバックを待つ • いくつかの調査後, JPEG2000デコーダーは別のベンダーのLuraTechによって開 発されていることが分かった • 商用ライセンス, 自由に利用できないソースコード • そのため, 我々はVMware Worksta[onでラップされた TPview.dll で止まった? • 継続可能だが, より複雑で, 遅くて, 先進的でない
- 136. さらなる調査 • さらなる調査で, 同じベンダーがフリーウェアとして人気のIrfanViewプログ ラムの用にJPEG2000のデコードプラグインを提供して居ることを見つけた • JPEG2000.DLL. • 大まかな分析により同じか非常に近いコードをベースとしていることが分かった • プラグインインターフェースを使用することは非常に簡単で, 次の定義に 似ている
- 138. それにより... • これのおかげで, 我々はVMWareを起動することなく, Windows上の 単一プロセスの実装に対しファジングテストを簡単に実施できた • DLLをロードするラッパープログラムと関連する関数の呼び出しは <50 LOC long • しかし, 私はこれらがLinuxに実装されていることを好むだろうか...
- 139. Linux上でのファジングＤＬＬ • なぜない, 本当に? • 望ましいベースアドレスは 0x10000000, アドレス空間で利用可能 • 再配置は必要ではない; セクションはそれぞれのアクセス権限があるところにマップされるべき • その他のアクション: • 必要なインポートを解決 • エクスポートされた関数のアドレスを取得 • デコードを実行するためにそれを呼び出す • 動作するはず!
- 140. インポートの解決 • インポートテーブルは面倒なポイントでもある • WinAPI 関数はLinux上では提供されていない • DLL インポート元は ADVAPI32, KERNEL32, MSVCRT, SHELL32 と USER32 • Ｃランタイムのインポートは直接libcにリダイレクトされる • 他の全てのものは書き換えられるか少なくともスタブアウトしなければならな い
- 144. ファジングの実行 • 内部的に利用可能なJPEG2000の入力ファイルコーバスを使用 • ミューテーションストラテジのレートは成功/失敗が50/50になるように 調整 • 数日間ファジングを実行させて, そして... • ... 186 のクラッシュとユニークなスタックトレースが見つかった
- 145. クラッシュの再現 • クラッシュはプラグインDLL上のものであって、まだVMware Worksta[onの ものではない点に注意 • vprintproxy.exe はとても便利に使える: 名前付きパイプを作成しCOM1に 書かれているデータを正確に読み出すことができる • もう1度、我々は実際のVMを起動せずにテストケースをチェックすることができる • ページヒープはよりよいバグの検出と重複の排除を可能にする
- 146. 最終結果 InstrucRon Reason add [eax+edx*4], edi Heap buffer overflow cmp [eax+0x440], ebx Heap out-of-bounds read cmp [eax+0x8], esi Heap out-of-bounds read cmp [edi+0x70], ebx Heap out-of-bounds read cmp [edi], edx Heap out-of-bounds read cmp dword [eax+ebx*4], 0x0 Heap out-of-bounds read cmp dword [esi+eax*4], 0x0 Heap out-of-bounds read div dword [ebp-0x24] Division by zero div dword [ebp-0x28] Division by zero fld dword [edi] NULL pointer dereference idiv ebx Division by zero idiv edi Division by zero imul ebx, [edx+eax+0x468] Heap out-of-bounds read mov [eax-0x4], edx Heap buffer overflow mov [ebx+edx*8], eax Heap buffer overflow mov [ecx+edx], eax Heap buffer overflow mov al, [esi] Heap out-of-bounds read mov bx, [eax] NULL pointer dereference mov eax, [ecx] NULL pointer dereference mov eax, [edi+ecx+0x7c] Heap out-of-bounds read InstrucRon Reason mov eax, [edx+0x7c] Heap out-of-bounds read movdqa [edi], xmm0 Heap buffer overflow movq mm0, [eax] NULL pointer dereference movq mm1, [ebx] NULL pointer dereference movq mm2, [edx] NULL pointer dereference movzx eax, byte [ecx-0x1] Heap out-of-bounds read movzx eax, byte [edx-0x1] Heap out-of-bounds read movzx ebx, byte [eax+ecx] Heap out-of-bounds read movzx ecx, byte [esi+0x1] Heap out-of-bounds read movzx ecx, byte [esi] Heap out-of-bounds read movzx edi, word [ecx] NULL pointer dereference movzx esi, word [edx] NULL pointer dereference push dword [ebp-0x8] Stack overflow (deep / infinite recursion) push ebp Stack overflow (deep / infinite recursion) push ebx Stack overflow (deep / infinite recursion) push ecx Stack overflow (deep / infinite recursion) push edi Stack overflow (deep / infinite recursion) push esi Stack overflow (deep / infinite recursion) rep movsd Heap buffer overflow, Heap out-of-bounds read
- 147. 最終結果 • 39のユニークなインストラクションでクラッシュが発生 • 多くのものはそんなに正確なメトリックのところでなく memcpy()のような一般 的の機能の様々なポイントで発生 • 簡単に分類: 18 の低深刻度, 15 中深刻度, 6 高深刻度 • 6月15日にVmwareに報告された • 9月 13日 (90 日以内)にVMSA-2016-0014 として修正された
- 148. 結論
- 149. 結論 • メタファイルは複雑で興味深いファイルで、研究の価値があるもの • 様々な攻撃ベクタが有効 • システムAPIについていろいろと教えてくれる (i.e. NamedEscapeインター フェース) • いつものことだが, 古くて曖昧なフォーマット/実装 – バグハンター向け • 以前の成果からのインスピレーションにももっと目を向けよう • 適材適所 – 手動のコード監査 vs ファジング