Subject: Dovecot IMAP/POP3 server: Off-by-one buffer overflow
From: Timo Sirainen <tss@iki.fi.>
To: [email protected]
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-izrfJxlGARhFpn8ru23w"
Date: Sun, 19 Nov 2006 02:39:23 +0200
Message-Id: <1163896763.8783.331.camel@hurina.>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.3
X-Virus-Scanned: antivirus-gw at tyumen.ru
--=-izrfJxlGARhFpn8ru23w
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
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=3Dyes 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=3DMEMORY 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
--=-izrfJxlGARhFpn8ru23w
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQBFX6e6yUhSUUBViskRApTjAJ42irhEVyW2QGMSGd3mk52hX75afgCeJ2Jn
9SAalKE8ZjO0skUxlbSw/Mw=
=rnTs
-----END PGP SIGNATURE-----
--=-izrfJxlGARhFpn8ru23w--
