tl;dr Moderately interesting and high-impact directory traversal bug, awesome bug bounty response. CVE-2017-12843
As I began to cope with the impending loss of my university email address, I decided to use the opportunity to migrate my mail from Gmail to FastMail. FastMail is mostly public about their software stack. Their IMAP and POP3 servers are run on Cyrus IMAP server. I cloned the repo and looked for the main IMAP REPL.
imap/imapd.c, I started going over each of the commands accessible by regular users. I came across the following:
I didn’t think
sync_parseline looked particularly interesting, but this was already my second pass over this code so I decided to be a bit more thorough. I followed
sync_parseline over to
reservefile sounds interesting. Let’s check that out…
dlist_reserve_path is sane?
Oops. We have complete control over
base (read directly from user input), and it gets inserted as the path prefix in
snprintf. This maybe wouldn’t be so bad if the
snprintf didn’t mean that the maximum path length was capped, since we would have the
/sync./ garbage always appended afterwards. But since we can make
base more or less arbitrarily long, we can run that suffix off of the end and specify the entire file path. Later, code in
reservefile allows the user to write arbitrary contents to the created file. Here’s a PoC that writes some stuff to
This is a pretty bad vulnerability and depending on your configuration could very easily lead to remote code execution. I emailed FastMail as per their bug bounty program, and in two hours (?!) they had a patch rolled out to their production servers and pushed upstream.