Bugzilla Bug 168196

/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/domain.com/user&name.

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/domain.com/user: 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 http://www.courier-mta.org/?download.php~imap ) 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:

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.

yeah indeed, that's not a nice shell script :((

Hi Robin, i don't know why you weren't CCed, sorry

CCing herd, please advise

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.

-4.0.6-r2 stable on amd64

x86 stable

Stable for HPPA.

ppc64 stable

ia64 stable

sparc stable.

ppc stable

Alpha done.

Hi, 

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 2.1.2.2 (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
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=i686 -fomit-frame-pointer -fforce-addr"
CHOST="i686-pc-linux-gnu"
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"
DISTDIR="/usr/portage/distfiles"
FEATURES="distlocks fixpackages metadata-transfer parallel-fetch sandbox
sfperms strict userpriv usersandbox"
GENTOO_MIRRORS="http://distfiles.gentoo.org
http://distro.ibiblio.org/pub/linux/distributions/gentoo"
LANG="it_IT.ISO-8859-1"
LC_ALL="it_IT.ISO-8859-1"
MAKEOPTS="-j5"
PKGDIR="/usr/portage/packages"
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-*"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
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"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, LINGUAS,
PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS,
PORTDIR_OVERLAY

@Nicola, please don't use security bugs as feature/version requests but open a
new bug assigned to the maintainer if needed.

GLSA 200704-18 - thanks to everybody

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.

Thanks!

-CJ

net-mail, please advise.

Any news on this one?

net-mail, please provide an updated ebuild.

(In reply to comment #20)
> net-mail, please provide an updated ebuild.
> 

*ping*

Shall this get masked, or WTH?! It's not like net-mail would be exactly
understaffed.

# herdstat net-mail
Herd:             net-mail
Email:            net-mail@gentoo.org
Description:      Email servers, clients, and related packages
Developers(12):   chtekk* chutzpah* dertobi123 ferdy* g2boojum hansmi hattya
lcars robbat2 strerror* ticho tove

Is there any patch we can try bumping the existing ebuilds with?

chutzpah is actively maintaining courier-imap now.

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...)

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?

Thanks.

ppc64 done

Stable for HPPA.

@Brent: Did you omit the commit?

Dunno what happened there.  Nice catch.  ppc64 committed

amd64/x86 stable

ppc stable

alpha/arm/ia64/sparc stable

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.

it is still relevant since the goal is to advice our users to upgrade to a safe
version. So [glsa].

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.
http://www.gentoo.org/security/en/vulnerability-policy.xml

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.