![]() It is 12am by this point and I could go to sleep now, but why sleep when at peak performance? So that was fun finding that buffer overflow vuln. Multiple Directory Traversal Vulnerabilities (Chroot Bypass) To reproduce this, try sending this in: USER anonymous Had the FTP server had written the address and port back to the user without updating it first anywhere in the code, I would've been able to leak memory by crafting a PORT command with not enough integers to satisfy the format.Īnd even if somehow I leaked memory and somehow I got lucky with ASLR and the addresses were all ASCII numeric, it wouldn't be possible to exploit unless uftpd was compiled without stack canaries since I cannot write a null byte. Considering I can't bypass the stack canary, I haven't bothered looking into this. So an attacker would have to either find a way to leak the stack canary that I couldn't or would have to brute force the canary.Īlso, there's another restriction: the address must be constructed out of the characters because of the %d specifier. I tried to find a way to leak memory, but other than leaking memory into logs (which maybe you could consider a vulnerability?), I couldn't get anywhere. The string representation of a signed integer is not at most 4 bytes like an (octet + '.' char) is, and it isn't checking the value of each octet to ensure that they are each between 0 and 255 inclusive.Ĭrap, a stack canary. ![]() That sprintf line is using the %d format specifier which takes a signed integer. The buffer size is INET_ADDRSTRLEN? What's that?Ī quick search shows that it's the value 16 (the maximum length of an IPv4 address in #.#.#.# format). I eventually came upon the handle_PORT function in ftpcmd.c: That made me think to re-check all uses of ^*printf$ in the code. He told me about some awful code he had seen where the author had basically gone out of the way to make a program vulnerable by constructing the query with sprintf instead of the built-in parameterized library's functions. Buffer Overflow Vulnerabilityįor some reason I thought about what a friend had told me at Defcon about how Go is basically bulletproof as far as SQL injection goes. After a few dead ends I followed and several hours wasted, I really wished I hadn't committed myself to finding something. Keep in mind, at this point, I was only looking for obvious buffer overflows, use-after-frees, off-by-ones, and format string injection vulnerabilities. I also carefully looked at uses of malloc and free. strcat / strncat, strcpy / strncpy, etc). ![]() Then, I began looking for uses of functions that could be used insecurely that involve string manipulation (e.g. How stupid am I? It's modern software compiled with a modern compiler. I started out by looking for uses of inherently vulnerable functions that should absolutely never be used. I wrote a fuzzer and ran it the entire time I was testing, but clearly I did not do a good job of writing it, because the fuzzer did not cause a single crash the entire time. So, it seems prone to off-by-one (which could lead to a buffer overflow) or heap corruption-related vulnerabilities. I chose the FTP server uftpd because I understand the FTP protocol very well, it is a plaintext protocol (mostly/usually/sometimes), and it involves a lot of string parsing. I'm sure I'll be glad I did it in a few years. I am writing this so that in the future I can look back and read about my first binary exploitation related vulnerability that I found outside of CTF. In this section I will walk through my thought process as I was discovering these vulnerabilities. If you want a tl dr of the vulnerabilities I found, skip to the section titled "Summary of Vulnerabilities".The section titled "Discovery Process" explains how I found the vulnerabilities and a bit about their root causes.On August 28, 2019, I sat down, picked an FTP server written in C to target, and told myself that I wouldn't stop and I wouldn't go to sleep until I found something (spoiler: I got to sleep that night). I know that I am not nearly as experienced as many people are, so in the past when I've searched, I would quickly begin to doubt that I would find anything and lose motivation. ![]() ![]() I've been wanting to find a binary exploitation-related vulnerability in something that isn't a Capture The Flag challenge for a very long time. This post is a very informal writeup about multiple vulnerabilities in uftpd FTP server, some of which could lead to remote code execution. Uftpd - Buffer Overflow and Directory Traversal Writeup ![]()
0 Comments
Leave a Reply. |