Bug 1741141 (CVE-2019-11500) - CVE-2019-11500 dovecot: improper NULL byte handling in IMAP and ManageSieve protocol parsers leads to out of bounds writes
Summary: CVE-2019-11500 dovecot: improper NULL byte handling in IMAP and ManageSieve p...
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2019-11500
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1741787 1741788 1746666 1747451 1751383 1752708
Blocks: 1741154
TreeView+ depends on / blocked
 
Reported: 2019-08-14 11:11 UTC by msiddiqu
Modified: 2020-04-30 17:41 UTC (History)
21 users (show)

Fixed In Version: dovecot 2.3.7.2, dovecot 2.2.36.4
Doc Type: If docs needed, set a value
Doc Text:
A flaw was found in dovecot. IMAP and ManageSieve protocol parsers do not properly handle the NULL byte when scanning data in quoted strings which leads to an out of bounds heap memory write. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
Clone Of:
Environment:
Last Closed: 2019-09-20 06:45:36 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2019:2822 None None None 2019-09-20 01:51:49 UTC
Red Hat Product Errata RHSA-2019:2836 None None None 2019-09-20 09:24:15 UTC
Red Hat Product Errata RHSA-2019:2885 None None None 2019-09-23 20:18:45 UTC

Description msiddiqu 2019-08-14 11:11:53 UTC
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.

Comment 3 msiddiqu 2019-08-14 11:30:23 UTC
Acknowledgments:

Name: the Dovecot project
Upstream: Nick Roessler (University of Pennsylvania), Rafi Rubin (University of Pennsylvania)

Comment 8 Huzaifa S. Sidhpurwala 2019-08-16 06:41:56 UTC
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.

Comment 10 Huzaifa S. Sidhpurwala 2019-08-29 05:03:52 UTC
External References:

https://dovecot.org/pipermail/dovecot-news/2019-August/000418.html

Comment 11 Huzaifa S. Sidhpurwala 2019-08-29 05:04:25 UTC
Created dovecot tracking bugs for this issue:

Affects: fedora-all [bug 1746666]

Comment 12 customercare 2019-08-29 07:29:46 UTC
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@redhat.com, who build the last package. thx.

Comment 13 msiddiqu 2019-08-29 12:37:25 UTC
References: 

https://www.openwall.com/lists/oss-security/2019/08/28/3

Patches included.

Comment 16 Georg Sauthoff 2019-09-15 15:55:33 UTC
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@gms.tf> - 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@redhat.com> - 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

Comment 18 Huzaifa S. Sidhpurwala 2019-09-17 03:43:54 UTC
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.

Comment 20 Rais Mense 2019-09-18 08:58:00 UTC
(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.

Comment 21 errata-xmlrpc 2019-09-20 01:51:45 UTC
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

Comment 22 Product Security DevOps Team 2019-09-20 06:45:36 UTC
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

Comment 23 errata-xmlrpc 2019-09-20 09:24:14 UTC
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

Comment 24 Huzaifa S. Sidhpurwala 2019-09-23 09:35:09 UTC
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

Comment 25 Rais Mense 2019-09-23 10:23:32 UTC
(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.

Comment 26 errata-xmlrpc 2019-09-23 20:18:43 UTC
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

Comment 27 Timo Sirainen 2019-09-27 08:13:26 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.