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