Serv-U CVE-2019-12181 Patch Analysis
TL;DR 👓
The patch in Serv-U FTP server version 15.1.7 that fixes my vulnerability (CVE-2019-12181), does so properly. Continue reading to for a walkthrough of the patch analysis.This blog post depends on knowledge and context from this blog post, please read it before continuing.
Motivation 🧠
I was told by a smart and trusted @yoavalon that failed patches are a norm in our industry, and I should therefore ensure the vulnerability I found is properly fixed in the latest allegedly safe version of the program.Potentially Inadequate Fixes 👎
It is possible (and depending on the security mindset of the company, maybe even probable) to unsuccessfully fix a vulnerability or even introduce a new vulnerability in a patch. For example, if some filtering logic is added to block malicious input from the user, it is worth ensuring the filter can't be bypassed.Analysis Process 🔬
The first thing I did was check if my initial POC code worked on the patched Serv-U 15.1.7. Thankfully it didn't. This means that at the very least the Serv-U programmers gave the vulnerability some attention. Now I just need to make sure there isn't a way to bypass the patch and that the patch doesn't introduce a new vulnerability.With both the un-patched Serv-U 15.1.6 and the patched Serv-U 15.1.7 binaries at my disposal, I began searching for the exact location of the vulnerability's fix.
Initial Strategy 1️⃣
The classic methodology for learning more about the delta between two executables is called binary diffing. In binary diffing, a smart algorithm analyzes each function in each of the executables and through heuristics such as, a function referencing the same unique string in both of the executables, the algorithm knows to match equal functions. To learn more about binary diffing view this slideshow.In my research I used a binary diffing tool called Diaphora since it's free and easy to integrate into IDA 7. Diaphora intelligently analyses each function of each executable and gives each function a "Match Ratio" between 0 to 1. The Match Ratio reflects how close the closest function in the other executable is to the current function in the current executable. A score of 1 shows a perfect match, and a score of 0 shows absolutely no match.
Since I was searching for a security patch, I was either looking for a new function added with logic to parse out malicious input (for CVE-2019-12181, that logic would be to filter out anything that isn't the program's filename), or I was looking for a function that changed by adding filtering logic to it directly (instead of putting the logic in a separate function). If a function changed, for example by logic being added to it, the change would be reflected in a Match Ratio less than 1.
![]() |
Partial Function Matches found by Diaphora. Notice the range of the Match Ratio labeled "Ratio" varies and is relatively close to 1. |
![]() |
Unreliable Function Matches found by Diaphora. Notice the range of the Match Ratio labeled "Ratio" varies and is relatively close to 0. |
Winning Strategy 🏆
I took a step back and realized:- The only way to correctly fix this vulnerability (CVE-2019-12181) is to not depend on the user for the path of the current executable running
- The path is a hard-coded value in the program
- The path is calculated during run-time through a system call
Theory #1
Disproving theory #1 was as simple as looking for the path "/usr/local/Serv-U/Serv-U" in the program and finding 0 results.![]() |
Zero results when searching for "/usr/local/Serv-U/Serv-U" in the program |
Theory #2
Proving or disproving theory #2 was more complex. However, I was able to simplify the problem by only looking at certain code. For our purposes we don't care about the grand majority of the code in the program: we only care about the previously vulnerable code.Trying to prove or disprove theory #2 by finding a new system call added to the patched program, I ran both the patched and un-patched version with strace and its -c flag to get a log of the system calls called. After saving the log to a file, I used BeyondCompare to look at the differences between the two files.
![]() |
System calls executed by the program before and after the update |
![]() |
System calls executed by the program before and after the update (cleaned) |
![]() |
IDA Pro decompilation showing call to readlink line 25 |
Since /proc/self/exe is a symbolic link provided by the kernel pointing to the current executable reading the link, reading this link is an excellent and safe way to get the current path of the file running 😁. And, if indeed the variable buf initialized from /proc/self/exe is later used to reference the current file (in contrast to before the patch where argv[0] was used), then CVE-2019-12181 is fully and correctly patched!
After more reversing, debugging, and playing around with the variable buf, I can confirm the data from readlink("/proc/self/exe") is indeed the variable used to reference the current file when calling system(), thus
Conclusion 👾
- The patch for CVE-2019-12181 adequately patches the vulnerability
- It's fun to use advanced tools such as Diaphora for complex tasks such as binary diffing, but sometimes a much more efficient and simple approach should be used.
Comments