CVE-2021-20247: isync/mbsync data leak/destruction vulnerability

[Oswald B. <osw...@gm...>]

description:

mbsync didn't validate the mailbox names returned by IMAP LIST/LSUB, 
which would allow a malicious/compromised server to use specially 
crafted mailbox names containing '..' path components to access data 
outside the designated mailbox on the opposite end of the 
synchronization channel. gory details follow below.
the attack vector is rather narrow, but the effects can be disastrous.
the vulnerability has been there "forever", though it wasn't of much 
concern prior to 1.3 used with a specific configuration.

mitigation:

upgrade to the freshly released v1.3.5 or v1.4.1 available from 
https://sourceforge.net/projects/isync/files/isync/ , or apply one of 
the attached patches (patches for earlier versions can be produced 
easily, should anyone care).

credit:

the possible existence of the vulnerability was suggested by a user who 
does not wish to be credited. :-D

vulnerability details:

- the victim must be using the Pattern channel option containing the '*' 
    wildcard. this is fairly likely (even though only those who actually 
    use hierarchical mailboxes (presumably a minority) actually need that 
    - others may use the '%' wildcard).
- if the opposite end is also an IMAP server (which is presumed to be 
    rare), the exact impact depends on the server. most servers will 
    expose only a very restricted amount of data to any particular user, 
    and will likely reject weird paths. also, most servers use '.' as the 
    hierarchy delimiter, which would make mbsync reject the crafted paths 
    as non-representable after delimiter translation. however, 
    uw-imap/panda-imap for example would be vulnerable, as it basically 
    just exposes the file system via IMAP.
- the much more common case is the opposite end being a local Maildir 
    store, which is somewhat similar to the uw-imap case:
    - users who don't actually use hierarchical mailboxes locally are 
      usually not vulnerable, as they won't set the SubFolders option, 
      which will make mbsync reject any mailbox names containing 
      hierarchy delimiters. (not applicable before v1.3.)
    - if SubFolders is Maildir++, no attack is possible, as periods are 
      hierarchy delimiters and are consequently rejected by the 
      translation. (not applicable before v1.3.)
    - if SubFolders is Legacy, an attack is limited to hidden 
      directories, as a '.' is prepended to each subfolder when mapping 
      to file system paths.
    - if SubFolders is Verbatim, exposure is unlimited. (not applicable 
      before v1.3.)
    - the most likely target are Maildir folders that are synchronized to 
      other servers (e.g., work vs. private mail stores)
      - if the victim is using '*' for the SyncState option (which most 
        users seem to do judging by support requests; the example config 
        file suggests it), all previously synchronized messages will be 
        deleted from that folder (that this happens is a seperate bug 
        that v1.4.1 also fixes), while new messages will be stolen.
      - otherwise, all messages from that folder will be stolen. i 
        consider this the main danger of this vulnerability.
    - non-Maildir paths can be attacked only if they end with one of 
      {cur,new,tmp}, as this is imposed by the expected Maildir structure.
      - if no 'cur' is present, the victim must have the Create option set 
        for that end of the channel (this is likely).
      - all files from 'tmp' will be deleted
      - all files from 'cur' and 'new' will be stolen, and in the process 
        renamed to add some Maildir "decorations"
      - subdirectories are not affected
      - in principle the attacker can deposit dangerous files, but these 
        will also have "weird" names that cannot be influenced much, so 
        they are unlikely to pose an actual threat. (general content 
        attacks are neglected here, as they don't require this 
        vulnerability to be executed.)
    - the attacked paths must be guessed or known in advance. if guessing 
      is used and the victim has Create enabled, every attempted target 
      path will be actually created, so the attacker will leave rather 
      obvious traces, and might be even noticed before landing a single 
      hit.
    - users who run mbsync interactively in verbose mode will likely spot 
      an attack immediately (this is presumed to be rare; cron jobs are 
      more likely).

i got an NVSS score of 'high', but there are lots of caveats that would 
qualify as mitigating factors if the criteria are not interpreted quite 
as literally (the case of a malicious server does not seem to fit very 
well).