IMAP and ManageSieve protocol parsers do not properly handle NUL byte when scanning data in quoted strings, leading to out of bounds heap memory writes.
Acknowledgments: Name: the Dovecot project Upstream: Nick Roessler (University of Pennsylvania), Rafi Rubin (University of Pennsylvania)
Analysis: This is essentially a OOB write flaw into the heap. There are multiple ways in which this can be triggered: 1. Via IMAP pre-auth, attacker can write 8096 bytes on the heap. 2. Via IMAP post-auth, attacker can write 65536 bytes on the heap, after a successful login. 3. An authenticated user, can create specially crafted sieve rules, which when parsed can cause heap write. Seems like exploitation is difficult, since the attacker cannot control the position of arbitrary heap-overwrite.
External References: https://dovecot.org/pipermail/dovecot-news/2019-August/000418.html
Created dovecot tracking bugs for this issue: Affects: fedora-all [bug 1746666]
Good Morning, News about this bug broke the news portals last night, a little more effort would be wise now. "Seems like exploitation is difficult,since the attacker cannot control the position of arbitrary heap-overwrite." so the attacker will just try it over and over and over again, till he hits a working area. This means a constant DOS or DDOS threat until fixed. I can't detected any build process on koji for a fixed version and the advisory says: "Operators should update to the latest Patch Release. There is no workaround for the issue." Can someone pls start a patch build i.e. mhlavink, who build the last package. thx.
References: https://www.openwall.com/lists/oss-security/2019/08/28/3 Patches included.
Upstream commits: https://github.com/dovecot/core/commit/85fcb895ca7f0bcb8ee72047fe0e1e78532ff90b https://github.com/dovecot/core/commit/f904cbdfec25582bc5e2a7435bf82ff769f2526a https://github.com/dovecot/pigeonhole/commit/7ce9990a5e6ba59e89b7fe1c07f574279aed922c https://github.com/dovecot/pigeonhole/commit/4a299840cdb51f61f8d1ebc0210b19c40dfbc1cc
Since RHEL/CentOS 7 hasn't received updated dovecot packages, yet, I've locally bumped the .spec file to dovecot 2.2.36.4 (which fixes the out-of-bounds write issues CVE-2019-11500 is about). An `rpmbuild -ba` succeeded and the test suite completed successfully. The old patches applied with some fuzz for some hunks - but nothing problematic, at the first glance. There were some compile and rpm warnings, but those must have been there for the current stable build, as well. So far, the resulting dovecot package works fine for me. (I'm not using dovecot-pigeonhole thus I didn't look into it if it needs a version bump, as well.) I basically did this: 1. rpm -i dovecot-2.2.36-3.el7.src.rpm 2. Changed the spec like this: --- a/SPECS/dovecot.spec +++ b/SPECS/dovecot.spec @@ -3,9 +3,9 @@ Summary: Secure imap and pop3 server Name: dovecot Epoch: 1 -Version: 2.2.36 +Version: 2.2.36.4 %global prever %{nil} -Release: 3%{?dist} +Release: 0%{?dist} #dovecot itself is MIT, a few sources are PD, pigeonhole is LGPLv2 License: MIT and LGPLv2 Group: System Environment/Daemons @@ -517,6 +517,11 @@ make check %changelog +* Sun Sep 15 2019 Georg Sauthoff <mail> - 1:2.2.36.4-1 +- bump because of CVE-2019-11500 (pre-auth out-of-bounds write) + https://dovecot.org/pipermail/dovecot-news/2019-August/000418.html + https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-11500 + * Wed Sep 19 2018 Michal Hlavinka <mhlavink> - 1:2.2.36-3 - fix global ACL directory configuration search path (#1630380) - update first/last_valid_gid range patch (#1630409) 3. downloaded https://dovecot.org/releases/2.2/dovecot-2.2.36.4.tar.gz 4. rebuilt the rpm Looking at the history of this bug I'm quite surprised that the package updates for RHEL 7 are taking so long. Having a central system service with a pre-auth out-of-bound write vulnerability is quite serious - especially since Redhat/dovecot package maintainers were informed a month ago. I see that there are some secret bugzilla issues this issue depends on. Since there probably are some worried RHEL/CentOS users out there perhaps it would make sense to be more transparent and at least post a small note on what's the current status/hold-up with all this. The warnings I noticed: master-service.h:164:33: warning: type qualifiers ignored on function return type [-Wignored-qualifiers] const enum master_service_flags master_service_get_flags(struct master_service *service); (all over the place and also in master-service.c) => This comes from dovecot-2.2.9-nodevrand.patch and is a legitimate warning which could be easily fixed. Not dangerous, though. And from rpm: warning: File listed twice: /var/run/dovecot/empty warning: File listed twice: /var/run/dovecot/login
Notes on exploitation: The pre-auth OOB write affects the dovecot/imap-login process. This process is run as the restricted dovenull user. As per https://doc.dovecot.org/admin_manual/system_users_used_by_dovecot: "dovenull user is used internally for processing users’ logins. It shouldn’t have access to any files, authentication databases or anything else either. It should belong to its own private dovenull group where no one else belongs to, and which doesn’t have access to any files either (other than what Dovecot internally creates)." Which implies, that even if the remote attacker is able to run arbitrary code via this flaw, because the code runs as dovenull user, which is highly restricted, the impact is very limited. Further, as per https://wiki2.dovecot.org/LoginProcess dovecot is run by default in "high-security" mode. For each incoming login request a new imap-login process is spawned. This process is highly restrictive and unless there is a kernel flaw there is very little the attacker can do to exploit a flaw in this process.
(In reply to Huzaifa S. Sidhpurwala from comment #18) > Notes on exploitation: > > The pre-auth OOB write affects the dovecot/imap-login process. This process > is run as the restricted dovenull user. > As per https://doc.dovecot.org/admin_manual/system_users_used_by_dovecot: > > "dovenull user is used internally for processing users’ logins. It shouldn’t > have access to any files, authentication databases or anything else either. > It should belong to its own private dovenull group where no one else belongs > to, and which doesn’t have access to any files either (other than what > Dovecot internally creates)." > > Which implies, that even if the remote attacker is able to run arbitrary > code via this flaw, because the code runs as dovenull user, which is highly > restricted, the impact is very limited. > > Further, as per https://wiki2.dovecot.org/LoginProcess dovecot is run by > default in "high-security" mode. For each incoming login request a new > imap-login process is spawned. This process is highly restrictive and unless > there is a kernel flaw there is very little the attacker can do to exploit a > flaw in this process. I think there's another viable angle that makes it a bit more problematic, even when the dovenull user is being used correclty. Code execution under the dovenull user does give an attacker access to other processes owned by dovenull. This could allow an attacker to attach to another process and perform malicious actions like capturing login sessions from other clients. Of course getting arbitrary code execution in the first place is still far from trivial.
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2019:2822 https://access.redhat.com/errata/RHSA-2019:2822
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2019-11500
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2019:2836 https://access.redhat.com/errata/RHSA-2019:2836
In reply to comment #20: > (In reply to Huzaifa S. Sidhpurwala from comment #18) > > Notes on exploitation: > > > > The pre-auth OOB write affects the dovecot/imap-login process. This process > > is run as the restricted dovenull user. > > As per https://doc.dovecot.org/admin_manual/system_users_used_by_dovecot: > > > > "dovenull user is used internally for processing users’ logins. It shouldn’t > > have access to any files, authentication databases or anything else either. > > It should belong to its own private dovenull group where no one else belongs > > to, and which doesn’t have access to any files either (other than what > > Dovecot internally creates)." > > > > Which implies, that even if the remote attacker is able to run arbitrary > > code via this flaw, because the code runs as dovenull user, which is highly > > restricted, the impact is very limited. > > > > Further, as per https://wiki2.dovecot.org/LoginProcess dovecot is run by > > default in "high-security" mode. For each incoming login request a new > > imap-login process is spawned. This process is highly restrictive and unless > > there is a kernel flaw there is very little the attacker can do to exploit a > > flaw in this process. > > I think there's another viable angle that makes it a bit more problematic, > even when the dovenull user is being used correclty. Code execution under > the dovenull user does give an attacker access to other processes owned by > dovenull. This could allow an attacker to attach to another process and > perform malicious actions like capturing login sessions from other clients. > Of course getting arbitrary code execution in the first place is still far > from trivial. Are you saying this could happen even if for each login attempt a different process is spawned? An attacker who has control over one process could control other login processes also even if he is non-root (dovenull) ? I dont think this is possible unless you have some other privs
(In reply to Huzaifa S. Sidhpurwala from comment #24) > In reply to comment #20: > > (In reply to Huzaifa S. Sidhpurwala from comment #18) > > > Notes on exploitation: > > > > > > The pre-auth OOB write affects the dovecot/imap-login process. This process > > > is run as the restricted dovenull user. > > > As per https://doc.dovecot.org/admin_manual/system_users_used_by_dovecot: > > > > > > "dovenull user is used internally for processing users’ logins. It shouldn’t > > > have access to any files, authentication databases or anything else either. > > > It should belong to its own private dovenull group where no one else belongs > > > to, and which doesn’t have access to any files either (other than what > > > Dovecot internally creates)." > > > > > > Which implies, that even if the remote attacker is able to run arbitrary > > > code via this flaw, because the code runs as dovenull user, which is highly > > > restricted, the impact is very limited. > > > > > > Further, as per https://wiki2.dovecot.org/LoginProcess dovecot is run by > > > default in "high-security" mode. For each incoming login request a new > > > imap-login process is spawned. This process is highly restrictive and unless > > > there is a kernel flaw there is very little the attacker can do to exploit a > > > flaw in this process. > > > > I think there's another viable angle that makes it a bit more problematic, > > even when the dovenull user is being used correclty. Code execution under > > the dovenull user does give an attacker access to other processes owned by > > dovenull. This could allow an attacker to attach to another process and > > perform malicious actions like capturing login sessions from other clients. > > Of course getting arbitrary code execution in the first place is still far > > from trivial. > > Are you saying this could happen even if for each login attempt a different > process is spawned? An attacker who has control over one process could > control other login processes also even if he is non-root (dovenull) ? > > I dont think this is possible unless you have some other privs I think this should be possible yes. Usually a user has the privileges to trace/debug their own users' processes, and since all the login processes run as the same dovenull user, actions like attaching a debugger to another process running as the dovenull user should be possible unless there is some other mechanism in place to separate process privileges running under the same user. I'm not sure but when running under systemd there might be some sandboxing feature enabled which does this for you. I'd have to investigate the matter further to give you a definitive answer on the matter.
This issue has been addressed in the following products: Red Hat Enterprise Linux 6 Via RHSA-2019:2885 https://access.redhat.com/errata/RHSA-2019:2885
Just a couple of clarifications: With the default high security mode it is not possible for login processes to ptrace each others, because they are running in setuid mode. Post-login exploitation is more likely though and has more impact.