So, we should work locally, on /levels/lab07/lab7A, or on its copy in /tmp. So, it is running as the lab7end user (so we would have to become root to debug it) and has ugly timeout of 60 seconds, making debugging additional hassle. This is the way it is being run (output from ps aux from the gameadmin/root user): More insight on the target appįirst of all, LAB7A.c comes with the following readme: Here is the second heap overflow, directly resulting from the first one, making it possible to overwrite the heap contents far beyond currently edited message body and its length field (so we will overwrite the print_msg pointer of the next message we create on the heap, getting a foothold into execution control).Īlso, note the numbuf buffer used to store user input before converting it to an integer used for message index (with 10 being maximum expected number of messages, which are indexed from 0, hence one digit is actually enough to store the index). This can be taken advantage of in the edit_message() function: And what will we overwrite this way? Yup, the msg_len field! This way we can achieve having created a message with nearly any size in msg_len, as we can control 3 out of its 4 bytes. So we can overflow the new_msg->message buffer by up to three bytes. So, read() (to which there are no bad characters, by the way! :D) writes new_msg->msglen bytes from standard input to the new_msg->message buffer. So, 128/4 = 32, but also 129/4 = 32, 130/4 = 32 and 131/4 = 32.ġ29,130 and 131 are possible length values we can sneak in without hitting the (new_msg->msg_len / BLOCK_SIZE) > MAX_BLOCKS condition and having our input length overwritten with the safe value of MAX_BLOCKS*BLOCK_SIZE.Īnd then, right away after smuggling the slightly bigger new_msg->msg_len, in the same create_message() call, we have this: Results of arithmetic division operations on integers give integer results. Msg->message buffer size is 128 ( MAX_BLOCKS*sizeof(int)). So, the vulnerability resides on lines 109-110: It gets interesting when the program asks the user to provide the length for the new message by calling get_unum() (which is defined in, for the record): The initial (and very short) heap overflow resides in the create_message() function and was quite trivial to find: There is a structure with buffers, length field and a pointer to overwrite:Īnd there are standard CRUD (Create/Read/Update/Delete) options available from the user interface, which - when chosen - call relevant functions: The vulnerability But instead of Use after Free, it's vulnerable to a multi-stage heap-based overflow. The target app is, on the face of it, quite similar to the previous one LAB7C.c ( ). While finding the vulnerability was trivial, building a working exploit was quite of a challenge here. This is was one of the most painstaking ones (which is reflected in the length of this write up).
0 kommentar(er)
