<<< Date Index >>>     <<< Thread Index >>>

Dovecot IMAP/POP3 server: Off-by-one buffer overflow



Version: 1.0test53 .. 1.0.rc14 (ie. all 1.0alpha, 1.0beta and 1.0rc
versions in the middle).

0.99.x versions are safe (they don't even have mmap_disable setting).

Problem: When mmap_disable=yes setting is used (not default),
dovecot.index.cache file is read to memory using "file cache" code. It
contains a "mapped pages" bitmask buffer. In some conditions when
updating the buffer it allocates one byte too little.

Exploitability: I think it's going to be pretty difficult to cause
anything else than a crash, but I wouldn't say impossible. Only logged
in IMAP/POP3 users can exploit this.

In theory you might be able to exploit this for other users as well by
sending them a lot of specially crafted emails, but this requires
knowing what dovecot.index.cache file contains. Normally its contents
can't be predicted, although perhaps with POP3 users it gets empty often
enough that the exploit could be tried. Then again, the exploit requires
having at least 4MB cache file, which won't happen with POP3 users
before the mailbox has about 170k mails (if I counted right).

With IMAP the cache file is used more, so it's easier to fill the 4MB
with for example a lot of To-headers.

Workaround: Use INDEX=MEMORY so the cache files aren't used at all.

Fix: 1.0.rc15 fixes this. You can also use this patch:
http://dovecot.org/patches/1.0/file-cache-buffer-overflow-fix.diff

BTW. I'd be interested in getting other people to audit Dovecot's
sources as well. I'll pay 1000 euros for the first person to demonstrate
a remotely exploitable security hole. This hole might have qualified as
one. See http://dovecot.org/security.html

Attachment: signature.asc
Description: This is a digitally signed message part