Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 168196 - net-mail/courier-imap remote execution vulnerability
Summary: net-mail/courier-imap remote execution vulnerability
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Highest major (vote)
Assignee: Gentoo Security
Whiteboard: B2 [glsa]
Depends on:
Reported: 2007-02-23 23:48 UTC by CJ Kucera
Modified: 2020-03-11 08:30 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description CJ Kucera 2007-02-23 23:48:05 UTC
/usr/lib/courier-imap/courier-imapd.indirect and /usr/lib/courier-imap/courier-pop3d.indirect do not protect the variable ${XMAILDIR} and could lead to remote command execution.  For instance, we have a user on our system with a username like "user&name" (the ampersand character is, regrettably, valid in email addresses, per the RFC), and the user's maildir expands to /var/spool/mail/

Upon logging in via IMAP or POP, we received the following in our logs:
pop3d: /usr/lib/courier-imap/courier-pop3d.indirect: line 3: name: command not found
pop3d: chdir /var/spool/mail/ No such file or directory

As you can see, the "&" was able to background the process, and then it tried to run the command "name."

Now, it does look like there would have to be malicious code in our users' maildir settings in order for this to be actually exploited, but it's still far from ideal, and required patching in our case for our five users with ampersands, since they wouldn't be able to log in otherwise.

I've changed my local copies of these two scripts to quote quote ${XMAILDIR}, and use "exec" instead of "eval," because that will enforce the argument list properly.  That seems to work fine for us.

I'm also curious as to why the script is there to begin with.  The Courier docs (specifically ) seem to suggest just using courierpop3d directly, without an "indirect" script inbetween.  Ideally I'd like to do without a bash inbetween.

Reproducible: Always

Steps to Reproduce:
Comment 1 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2007-02-24 10:21:45 UTC
XMAILDIR should be quoted yes.
the point of the indirect script is the 'LOGINRUN' variable and specifically evaluating it. This makes it possible to nicely do things like SMTP-after-POP/IMAP, by configuring something into the LOGINRUN variable.
Comment 2 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2007-02-26 23:19:53 UTC
yeah indeed, that's not a nice shell script :((
Comment 3 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2007-03-09 21:50:00 UTC
Hi Robin, i don't know why you weren't CCed, sorry
Comment 4 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2007-03-15 21:49:20 UTC
CCing herd, please advise
Comment 5 Luca Longinotti (RETIRED) gentoo-dev 2007-04-07 01:43:31 UTC
This is fixed in the new revisions of courier-imap, 4.0.6-r2 and 4.1.2-r1.

To arch-teams: please stable 4.0.6-r2, NOT 4.1.2-r1! Thanks.

To SH-arch-team: I have no clue what happened to your keyword, it's just present in 4.0.1 and then disappears totally... Please fix the situation, would be great if you could stable 4.0.6-r2 too, as to fix the security issue, thanks!

Best regards, CHTEKK.
Comment 6 Peter Weller (RETIRED) gentoo-dev 2007-04-07 08:10:41 UTC
-4.0.6-r2 stable on amd64
Comment 7 Christian Faulhammer (RETIRED) gentoo-dev 2007-04-07 09:54:56 UTC
x86 stable
Comment 8 Jeroen Roovers (RETIRED) gentoo-dev 2007-04-07 16:14:36 UTC
Stable for HPPA.
Comment 9 Markus Rothe (RETIRED) gentoo-dev 2007-04-08 10:34:57 UTC
ppc64 stable
Comment 10 Raúl Porcel (RETIRED) gentoo-dev 2007-04-09 21:09:21 UTC
ia64 stable
Comment 11 Gustavo Zacarias (RETIRED) gentoo-dev 2007-04-10 17:05:28 UTC
sparc stable.
Comment 12 Tobias Scherbaum (RETIRED) gentoo-dev 2007-04-11 18:57:27 UTC
ppc stable
Comment 13 Fernando J. Pereda (RETIRED) gentoo-dev 2007-04-12 10:25:20 UTC
Alpha done.
Comment 14 Nicola 2007-04-15 09:42:34 UTC

why 4.1.2-r1 should not be marked stable? I'm running it since 3 days with no issue:

[ebuild   R   ] net-libs/courier-authlib-0.59.2  USE="berkdb crypt gdbm mysql pam -debug -ldap -postgres -vpopmail" 0 kB 
[ebuild   R   ] net-mail/courier-imap-4.1.2-r1  USE="berkdb fam gdbm nls -debug -ipv6 (-selinux)" 0 kB 

emerge --info
Portage (hardened/x86/2.6, gcc-3.4.6, glibc-2.3.6-r5, 2.6.18-hardened-r6 i686)
System uname: 2.6.18-hardened-r6 i686 Intel(R) Xeon(TM) CPU 3.00GHz
Gentoo Base System release 1.12.9
Timestamp of tree: Sat, 14 Apr 2007 03:00:01 +0000
dev-lang/python:     2.4.3-r4
dev-python/pycrypto: 2.0.1-r5
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.60
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
sys-devel/binutils:  2.16.1-r3
sys-devel/gcc-config: 1.3.15-r1
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.17-r2
CFLAGS="-O2 -march=i686 -fomit-frame-pointer -fforce-addr"
CONFIG_PROTECT="/etc /var/bind"
CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/php/apache1-php5/ext-active/ /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo"
CXXFLAGS="-O2 -march=i686 -fomit-frame-pointer -fforce-addr"
FEATURES="distlocks fixpackages metadata-transfer parallel-fetch sandbox sfperms strict userpriv usersandbox"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*"
USE="apache2 berkdb crypt gdbm hardened midi ncurses nls nptl pam perl pic python readline ssl tcpd x86 xorg zlib" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="mouse keyboard" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU"

Comment 15 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2007-04-15 11:05:43 UTC
@Nicola, please don't use security bugs as feature/version requests but open a new bug assigned to the maintainer if needed.
Comment 16 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2007-04-22 21:28:47 UTC
GLSA 200704-18 - thanks to everybody
Comment 17 CJ Kucera 2007-10-06 07:02:34 UTC
Hello again...

A recent upgrade of Courier on our systems have uncovered this again - it's the same issue.  The $XMAILDIR variable *is* quoted properly now, but the "eval" statement ends up working against the quotes.  In order for this to work properly, "exec" has to be used instead, because then each argument gets passed properly, instead of concatenating the string and calling it that way.

From the bash manpage on the "eval" function:
> The args are read and concatenated together into a single command

The bit of bash's manpage which deals with the "exec" function doesn't explicitly state that the arguments are handled properly, but it's clearly just calling exec(3) behind the scenes, which will Do The Right Thing in this case.

So, again, just to clarify - the files courier-imapd.indirect and courier-pop3d.indirect are still not handling "&" in usernames correctly, because eval is being used instead of exec.

I know that this is definitely a corner case here, and that it'd be mightily difficult to actually exploit this on a live system, but it should still probably be Done The Right Way.


Comment 18 Robert Buchholz (RETIRED) gentoo-dev 2007-10-08 00:57:15 UTC
net-mail, please advise.
Comment 19 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2007-10-17 18:58:34 UTC
Any news on this one?
Comment 20 Pierre-Yves Rofes (RETIRED) gentoo-dev 2007-11-06 19:28:34 UTC
net-mail, please provide an updated ebuild.
Comment 21 Pierre-Yves Rofes (RETIRED) gentoo-dev 2008-01-20 10:57:31 UTC
(In reply to comment #20)
> net-mail, please provide an updated ebuild.

Comment 22 Jakub Moc (RETIRED) gentoo-dev 2008-02-03 11:06:44 UTC
Shall this get masked, or WTH?! It's not like net-mail would be exactly understaffed.

# herdstat net-mail
Herd:             net-mail
Description:      Email servers, clients, and related packages
Developers(12):   chtekk* chutzpah* dertobi123 ferdy* g2boojum hansmi hattya lcars robbat2 strerror* ticho tove
Comment 23 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2008-02-10 14:52:13 UTC
Is there any patch we can try bumping the existing ebuilds with?
Comment 24 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-08-20 19:49:46 UTC
chutzpah is actively maintaining courier-imap now.
Comment 25 Matti Bickel (RETIRED) gentoo-dev 2008-12-07 15:20:53 UTC
rerating B2 as user/admin needs to pick a malicious name for this to pose a threat. But anyway: this is long, long overdue.

chutzpah: ping!

If nothing happens, i'll patch it myself to use exec instead of eval at the end of next week. (Target for B2 is 10 days...)
Comment 26 Matti Bickel (RETIRED) gentoo-dev 2008-12-14 21:16:30 UTC
i've committed courier-imap-{4.0.6-r3,4.1.2-r2,4.4.1-r1} and fixed the two init scripts to use exec instead of eval.

Target keywords:
=net-mail/courier-imap-4.0.6-r3: alpha amd64 arm hppa ia64 ppc ppc64 s390 sparc x86

sh: is there any reason you never marked 4.0.6-* stable?

Comment 27 Brent Baude (RETIRED) gentoo-dev 2008-12-15 19:57:44 UTC
ppc64 done
Comment 28 Jeroen Roovers (RETIRED) gentoo-dev 2008-12-16 13:49:43 UTC
Stable for HPPA.

@Brent: Did you omit the commit?
Comment 29 Brent Baude (RETIRED) gentoo-dev 2008-12-16 15:47:00 UTC
Dunno what happened there.  Nice catch.  ppc64 committed
Comment 30 Markus Meier gentoo-dev 2008-12-17 20:08:57 UTC
amd64/x86 stable
Comment 31 Tobias Scherbaum (RETIRED) gentoo-dev 2008-12-18 19:01:49 UTC
ppc stable
Comment 32 Raúl Porcel (RETIRED) gentoo-dev 2008-12-22 20:04:44 UTC
alpha/arm/ia64/sparc stable
Comment 33 Matti Bickel (RETIRED) gentoo-dev 2008-12-26 10:51:03 UTC
Do we issue a glsa on this one? It's over a year old bug... Dunno if it's still relevant.

I'll draft one if needed.
Comment 34 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2009-01-11 17:20:54 UTC
it is still relevant since the goal is to advice our users to upgrade to a safe version. So [glsa].
Comment 35 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2009-01-12 23:46:32 UTC
I rerate this as C1.

The GLSA has been drafted with severity=High which corresponds to B1, not B2.

Remote root compromise is always *1, not depending on a particular configuration of the software. If only a specific non-default configuration is affected, then it's C1.
Comment 36 Matti Bickel (RETIRED) gentoo-dev 2009-03-12 22:59:18 UTC
courier-authlib drops privileges after logging in the user, and before executing our script.

The following happens for a remote compromise:
1) imaplogin gets called and the attacker tries to authenticate against the server
2) attacker guesses vulnerable username containing '&' AND users password
3) imaplogin calls auth_login, which calls imaplogin's login_callback()
4) login_callback() calls courier-authlib's login_callback_default(), which drops privileges to the logged in user's and changes to his home
5) login_callback() executes our imapd script
3) attacker gets to execute a local user chosen command with the rights of the user logged in (may even be a special vmail user, as with my installation)

So this is NOT a remote root compromise. You need special information and a very specific setup for this to actually pose a threat.

To clarify: if i have a user who sets MAILDIR="/home/user/.maildir&#!/bin/bash\nupload_and_install_my_rootkit()" every login by that user will execute upload_and_install_my_rootkit() with the rights of that user.
BUT if your user can set his own MAILDIR, he might as well execute that function himself.

On my system MAILDIR is set by a query to a root controlled mysql table. So the values there are safe, even if the script won't handle '&' properly, and might even execute a command by accident.

I apologize for not doing that analysis beforehand and rushing the change in under the flag of security.

I'll reset the glsa tag to the last known good state for now, this is not a security issue in my eyes. Feel free to reopen if you think otherwise.