TCPサーバの接続情報と、サーバのファイル一式が与えられた。
与えられたファイルのうち app.c
を読むと、以下の処理をしていることが読み取れた。
malloc
で1024バイトの領域を確保する。./flag.txt
の内容を読み込む。Content-Length
または content-length
で始まるヘッダが送られてきたら、malloc
で指定された数値+1バイトの領域をレスポンス用に確保する。
malloc
で同じサイズの領域を確保すると、バッファが使いまわしされることが期待できる。
そこで、1024バイトの領域を確保させるヘッダを送り、ボディはそれより少ないデータを渡すことで、バッファに残ったflagが出力される可能性があると考えた。
これを実行するため、ami-03d5c68bab01f3496
) を使用して t2.micro のEC2インスタンスを立て、そこでサーバのプログラムを動かすことにした。
このとき、サーバにアクセスできるように、セキュリティグループの設定でソース 0.0.0.0/0
からTCPの7777番ポートへのアクセスを許可した。
Content-Length
で指定した長さより少ないデータしか送らずに接続を閉じると、エラーになってしまった。
そこで、Content-Length-Fake
ヘッダで領域を確保させ、データのサイズは(小文字のl
を使った) Content-length
ヘッダで指定することにした。
最終的に、以下のサーバプログラムを用いることで、flagが得られた。
hello, world
1個ではバッファに領域を開放した時に書き込まれるナル文字が残っているようでflagが得られなかったので、hello, world
を2個にした。
Information to connect to a TCP server and the files for the server were given.
Reading app.c
in the given files, I found it doing these process:
malloc
../flag.txt
to the allocated buffer.Content-Length
or content-length
.
When allocating same-sized buffers via malloc
, there is a high chance that the buffer is reused.
Threfore, I thought that the flag remaining in the buffer can be printed if a header to have it allocate a 1024-byte buffer is sent and the body is shorter than that.
To achieve this, I created a t2.micro EC2 instance with the AMI "Ubuntu Server 20.04 LTS (HVM), SSD Volume Type" (ami-03d5c68bab01f3496
) on
I configured the security group to accept accesses to TCP port 7777 from the source 0.0.0.0/0
to make the server available.
Closing the connection with sending less data than specified in the Content-Length
resulted in an error.
Therefore, I decided to have it allocate the buffer using a Content-Length-Fake
header and specify the data size using a Content-length
(with small l
) header.
In conclusion, I obtained the flag using this server program.
I put two hello, world
because using only one didn't reveal the flag and I thought that is because there are null characters written on freeing the buffer remaining in the buffer.