Penetration Test Report (Cure53): pentest report dovecot

Dr.-Ing. Mario Heiderich, Cure53
Rudolf Reusch Str. 33
D 10367 Berlin
cure53.de · mario@cure53.de
Pentest-Report Dovecot 11.2016
Cure53, Dr.-Ing. M. Heiderich, M. Wege, BSc. D. Weißer, Dr. J. Magazinius, MSc. N. Krein
Index
Introduction
Scope
Test Methodology
Part 1 (Manual Code Auditing)
Part 2 (Code-Assisted Penetration Testing)
Identified Weaknesses
DOV-01-001 Format String Protection can be bypassed (Low)
DOV-01-002 Default Makefile fails to add Hardening Flags (Low)
DOV-01-003 Memorypool Allocator fails to check for Integer Overflows (Low)
Conclusion
Cure53, Berlin · 11/29/16 1/10
Dr.-Ing. Mario Heiderich, Cure53
Rudolf Reusch Str. 33
D 10367 Berlin
cure53.de · mario@cure53.de
Introduction
“Dovecot is an open source IMAP and POP3 email server for Linux/UNIX-like systems,
written with security primarily in mind. Dovecot is an excellent choice for both small and
large installations. It's fast, simple to set up, requires no special administration and it
uses very little memory.”
From http://www.dovecot.org/
This report documents the findings of a penetration test and source code audit against
the Dovecot email server software. The project was carried out by four testers of the
Cure53 team over the course of twenty days in October and November 2016.
In the broader web and security community, Dovecot is known for being very much
robust and secure1. With good reasons, the positive assessment of the software, which
is unlike many others regarding fulfilment of its security promises, is largely used for
promotional and advertising purposes. On the Index page of the Dovecot website, one
can read that
“Dovecot's design and implementation is highly focused on security. Rather than
taking the traditional road of just fixing vulnerabilities whenever someone
happens to report them, I offer 1000 EUR of my own money to the first person to
find a security hole from Dovecot.”
During this project, the Cure53 security investigations aimed at a thorough and in-depth
assessment of the selected parts of the Dovecot codebase. The scoped components
should be viewed as top priorities in further safe development, and, as such, they
pertained mostly to the POP and IMAP protocol stacks, SSL wrapper, implementations
of dcrypt and GUID, as well as other items elaborated on later in this report.
The tests proceeded in two distinct phases, with the first one dedicated to a manual
code review, and the second one centered on a penetration test. The latter component
took advantage of several running instances of Dovecot. The tests largely sought to spot
any vulnerabilities that could allow malicious attackers to benefit from memory
corruption, information leaks, authentication bypasses, and logical flaws. In scope was
the 2.2.26.0 version of the Dovecot email server software suite, which was released on
October 28, 2016. The date coincided with the start date of the Cure53 assignment2.
Despite much effort and thoroughly all-encompassing approach, the Cure53 testers only
managed to assert the excellent security-standing of Dovecot. More specifically, only
1 http://www.dovecot.org/security.html
2 http://www.dovecot.org/doc/NEWS
Cure53, Berlin · 11/29/16 2/10
Dr.-Ing. Mario Heiderich, Cure53
Rudolf Reusch Str. 33
D 10367 Berlin
cure53.de · mario@cure53.de
three minor security issues have been found in the codebase, thus translating to an
exceptionally good outcome for Dovecot, and a true testament to the fact that keeping
security promises is at the core of the Dovecot development and operations.
It has to be mentioned that the analyzed code can be only characterized as highly
complex. Many parts are commonly interwoven and entangled together in the code
base, which makes it particularly hard to grasp. Against this backdrop, one should see
the audit process as slightly hindered in terms of the speed and pace it allows to external
security investigators. This was especially visible for the API code, while other areas
appeared to be less entwined and much more readable for the auditors.
Regardless of complexity, most of the issues and concerns prompted by the code have
ultimately turned out non-exploitable. For the most part, they have not warranted
creation of dedicated issue-tickets. It is important to underscore that even the areas
which looked exploitable at first glance were equipped with an important value of being
checked properly, thus having all attack potential successfully mitigated.
It is noticeable that Dovecot has already received a lot of scrutiny regarding its code
security. For a complex piece of software that Dovecot constitutes, it is an extremely rare
result to stand strong with so few problems. As the findings are few and far between, the
report can discuss both test methodologies in considerable detail and elaborate on the
logic and sequence of steps within the tests. Only then, it will move on to the coverage of
the three spotted weaknesses and their corresponding fix recommendations.
Scope
• Dovecot Sources & Signatures
◦ http://dovecot.org/releases/2.2/dovecot-2.2.26.0.tar.gz
◦ http://dovecot.org/releases/2.2/dovecot-2.2.26.0.tar.gz.sig
◦ (released on 28th of October 20163)
• General Info
◦ http://www.dovecot.org/security.html
• More detailed Scope
◦ The POP and IMAP protocol stacks
◦ The process architecture and particularly the login process
◦ The User/Password MySQL and LDAP plugins
◦ The internal dcrypt encryption API wrapper
◦ The GUID implementation
3 http://www.dovecot.org/list/dovecot-news/2016-October/000329.html
Cure53, Berlin · 11/29/16 3/10
Dr.-Ing. Mario Heiderich, Cure53
Rudolf Reusch Str. 33
D 10367 Berlin
cure53.de · mario@cure53.de
Test Methodology
The following section describes the methodology that was used during this source code
audit and penetration test. The test was divided into two phases with specific two-fold
goals and focal points in scope. The first phase concentrated mostly on manual source
code reviews. These reviews aimed at spotting insecure code constructs with a capacity
to lead to memory corruption, information leakage or other similar flaws. The second
phase of the test was dedicated to classic penetration tests, which examined whether
the security promises made by Dovecot in fact hold in the real-life attack situations.
Part 1 (Manual Code Auditing)
A list of items below seeks to detail some of the noteworthy steps undertaken during the
first part of the test, which entailed the manual code audit against the sources of the
Dovecot software in scope. This is to underline that, in spite of the relatively low number
of findings, substantial thoroughness was achieved and considerable efforts have gone
into this test. The completed steps are listed next.
• The doc/documentation.txt files were studied. It was verifying whether the
content of doc/securecoding.txt is sane. While this component was found rather
complete, it lacked a few points, e.g. regarding the implementation of the
refcounter assertions4
• Existing mitigation against standard memory corruption attacks was analyzed.
Using secure wrapper functions instead of direct memory access is considered
best practice in this realm. One issue regarding the protection against format
string exploits was discovered in this area and is documented in DOV-01-001.
Heap management appeared reasonable. The additional hardening against 0-
sized and large allocations inside the mempool were certainly considered useful
and appropriate. Similarly, making sure that memory is always zero-initialized
paired with the strategy of having the free'd pointers nulled, effectively aided the
prevention of additional problems. Another idea pertinent to hardening and aimed
at increasing general memory safety was added to the report.
• The checks of the default Makefiles revealed them to be lacking all sorts of
hardening flags. These should be enabled per default and must be added instead
of having distributions apply their compilation option. The alternative approach is
described in DOV-01-002.
• At