tl;dr Moderately interesting and high-impact directory traversal bug made worse because of snprintf, awesome bug bounty response. CVE-2017-12843
Another plus to FastMail is their awesome bug bounty program.
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.