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.