12/05/2016, 11:59PM
CTF-3 is specifically designed
to run on the department machines. You are expected to do
all the development on that particular environment,
which is also what we will be using for grading. Do not run
CTF-3 on your personal desktop, laptop, VM, or
any other non-standard setting -- you are free to do so, if
you insist, or know what you are doing, but we are not going
to provide any support in such cases. If you are connecting
remotely, use ssh(1)
and follow the
instructions
provided by tstaff.
Copy ctf-3.tar.gz
to your home directory and
extract it; you should get ctf-3/
, which, in
turn, should contain the following files:
Makefile
, README
,
exp4.c
, exp5.c
, vcat4
,
and vcat5
. Make sure that no one else has access
to ctf-3/
(e.g.,
chmod go-rx ctf-3), type cd ctf-3, and
start hacking!
Yes, it's vcat.
Again :-).
vcat4
is a vulnerable program that reads
from stdin(3)
(standard input) and writes to
stdout(3)
(standard output) -- it is roughly
equivalent to executing cat -. Note that you are
not given the source code of vcat4
.
Similarly to CTF-1 and CTF-2, you may
run vcat4
by typing make vcat4_run.
This make(1)
directive wraps the execution of
vcat4
with setarch i686 -3, which
emulates a 32-bit x86 environment (i686
),
with support for address space layout randomization,
and with a proper 3GB user space
(-3
). Recall that the department machines are
64-bit; hence, do not invoke vcat4
directly, like
./vcat4, because you will end up solving a different
assignment :-). Similarly, if you need to execute
vcat4
under gdb(1)
, type
make vcat4_dbg. To aid the exploitation process, we
provide exp4
(exp4.c
). This binary
dumps in stdout(3)
the contents of a particular
payload (i.e., variable
unsigned char payload[]
in exp4.c
).
By running make vcat4_exp, make(1)
will
effectively execute ./exp4 | ./vcat4, under
setarch i686 -3, thereby allowing you to feed
vcat4
with the exact contents of
unsigned char payload[]
. Lastly, if you wish to
execute ./exp4 | ./vcat4 under gdb(1)
,
and attach the debugger to vcat4
, run
make vcat4_dbg and commence execution as follows:
r < <(./exp4).
vcat4
contains a stack-based buffer overflow, but
it is hardened against both code injection and code
reuse (i.e., ret2libc-style attacks), by
using executable space protection
and address space layout randomization.
exp4
contains a template payload
(unsigned char payload[]
in exp4.c
)
that smashes the stack of vcat4
and invokes
exit(EXIT_SUCCESS)
(i.e., the
exit(3)
routine of libc), using the
return-to-plt technique,
gracefully terminating the execution of vcat4
.
mgk1
,
mgk2
, rnd1
, and
rnd2
.0x0defaced
(4 bytes) to
mgk1
; and (b) invokes
raise(SIGUSR1)
, instead of
exit(EXIT_SUCCESS)
, using the
return-to-plt
(ret2plt) technique. What should
be the value of payload (i.e.,
variable unsigned char payload[]
in exp4.c
) for getting the
flag?rnd1
and rnd2
(4
bytes each); (b) adds them; (c)
stores the result tomgk2
;
and (d) invokes
raise(SIGUSR2)
, instead of
exit(EXIT_SUCCESS)
, using the
return-to-plt
(ret2plt) technique. What should
be the value of payload (i.e.,
variable unsigned char payload[]
in exp4.c
) for getting the
flag?vcat4
.
(Note that someone else may have already
uploaded the binary; do not upload it
multiple times.)
Similarly to vcat4
, vcat5
is a
vulnerable program that reads from
stdin(3)
and writes to stdout(3)
.
Again, you are not given the source code of
vcat5
.
You may run vcat5
by typing
make vcat5_run. Also, if you need to execute
vcat5
under gdb(1)
, type
make vcat5_dbg. To aid the exploitation process, we
provide exp5
(exp5.c
), which: (a)
dumps in stdout(3)
the value of macro
FMT_STR
and the contents of variable
unsigned char payload[]
; and (b) reads from
stdin(3)
a hexadecimal (4 byte) value as a
string. By running make vcat5_exp,
make(1)
will effectively execute
./exp5 < fifo | ./vcat5 > fifo, allowing you to
feed vcat5
with the exact contents of
FMT_STR
and unsigned char payload[]
,
and exp5
with the output of vcat5
.
Lastly, if you wish to execute ./exp5 | ./vcat5
under gdb(1)
, and attach the debugger to
vcat5
, run make vcat5_dbg and commence
execution as follows: r < <(./exp5).
vcat5
contains both a stack-based buffer
overflow and a format string vulnerability. However, it is
hardened, against code injection and code reuse, by
using executable space protection
and full address space layout randomization;
note that vcat5
is a position-independent
executable (PIE). exp5
contains: (1) a format
string template (FMT_STR
) for leaking a 4-byte
hexadecimal value from the stack of vcat5
; and (2)
a template payload (unsigned char payload[]
) that
smashes the stack of vcat5
.
vcat5
(e.g., a saved
return address). What should be the value of
the format string template (i.e.,
macro FMT_STR
in
exp5.c
) to achieve that?0x0defaced
(4 bytes) to
mgk1
; and (b) invokes
raise(SIGUSR1)
using the
return-to-plt
(ret2plt) technique. What should
be the value of payload (i.e.,
variable unsigned char payload[]
in exp5.c
) for getting the
flag? (You may modify exp5.c
,
however you want, in order to dynamically
compose the required payload.)rnd1
and rnd2
(4
bytes each); (b) adds them; (c)
stores the result tomgk2
;
and (d) invokes
raise(SIGUSR2)
. What should be the
value of payload (i.e., variable
unsigned char payload[]
in
exp5.c
) for getting the flag? (You
may modify exp5.c
, however you
want, in order to dynamically compose the
required payload.)vcat5
under gdb(1)
,
but without feeding exp5
with the output of vcat5
.
Therefore, the leaked address of
vcat5
will be printed in
stdout(3)
, allowing you to
experiment with different format string
templates until you complete Warm-up 1. Once you have successfully leaked an address belonging to the .text section of
vcat5
, you can manually feed it to
exp5
, by typing it in
stdin(3)
, which, in turn, will
automatically compute the base address of
vcat5
(see variable
unsigned long baddr
in
exp5.c
). Armed with that
information, you can then dynamically compute
the absolute address of each gadget or symbol
in vcat5
, and attempt Flag 3.
vcat5
.
(Note that someone else may have already
uploaded the binary; do not upload it
multiple times.)README
.
First, edit section 0xf
(whoami), and fill
‘Name’ with your name. Next,
fill every other section
(0x0
-- 0x4
) with the
respective answer(s). If you cannot capture a flag, you
can still get partial credit by providing a
brief description of your attack plan (e.g.,
what exactly you plan on corrupting, with what value(s),
and why; or what you plan on injecting, where, and why),
the actions you took for implementing it
(i.e., partial or incomplete payload values,
memory dumps, and gdb(1)
excerpts), as
well as your findings.ctf-3/
to submit
your write-up -- you may want to
alias
that command for multiple submissions. You can resubmit
as many times as you like, prior to the deadline, but
note that your old submission(s) will be
overwritten by the latest one.You should not discuss CTF-1 with anyone except the CSCI 1951H course staff. You may consult ‘outside sources of information’, but you must cite them; and you may rely on such sources only for concepts, not for solutions to problems -- the write-up must be entirely your own work.