Penetration Test Report (Cure53): pentest report fluent

Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
Pentest-Report Fluentd, Fluent-Bit Plugins 05.2019
Cure53, Dr.-Ing. M. Heiderich, M. Wege, MSc. N. Krein, BSc. J. Hector, BSc. F. Fäßler
Index
Introduction
Scope
Test Methodology
Part 1. Manual code auditing
Part 2. Code-assisted penetration testing
Identified Vulnerabilities
FLU-01-003 fluent-bit/in_forward: Heap overflow via negative length (Critical)
FLU-01-004 fluent-bit: Missing Error-Checking leads to DoS (Medium)
FLU-01-005 fluent-bit/in_mqtt: Heap overflow in MQTT parser (Critical)
FLU-01-006 fluent-bit/in_mqtt: Heap overflow due to negative size (Critical)
Miscellaneous Issues
FLU-01-001 fluent-ui: User-model implements static password-salt (Low)
FLU-01-002 fluent-bit: flb_malloc-functions permit zero-sized allocations (Low)
Conclusions
Cure53, Berlin · 05/30/19 1/16
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
Introduction
“fluentd is an open source data collector, which lets you unify the data collection and
consumption for a better use and understanding of data.”
From https://www.fluentd.org/architecture
This report showcases the results of a security assessment targeting the Fluentd
software compound. Carried out by Cure53 in May 2019, this project entailed both a
penetration test and a source code audit. Besides Fluentd itself, the core scope also
included selected Fluent-bit plugins. Further, a brief analysis of the Fluentd-UI was also
conducted. Six security-relevant discoveries were made by Cure53 during the
assessment.
As for the resources, this test was executed by five members of the Cure53 team. The
testers dedicated a total of eighteen days to the project and it is believed that good
coverage has been reached within the available budget. As with many other CNCF-
related projects, Cure53 chose to employ a two-pronged approach to evaluating the
security premise of the Fluentd project. Consequently, the available time has been split
to allow for combining the source code audit with actual penetration testing against a
locally built setup.
It can be derived from the above that a white-box methodology has been chosen and
used. This has proven optimal in previous CNCF-related security assessments and
indeed worked well for this Fluentd-Cure53 cooperation. To be able to investigate the
scope in a comprehensive manner, Cure53 had access to all relevant sources. While no
maintainer-provided setup was available for this test, Cure53 relied on several locally
built setups when testing possible vulnerabilities for exploitability.
Contrary to numerous CNCF projects audited by Cure53 in the recent past, the Fluentd
project does not rely on the Go language code as much. In fact, the code had been
written mostly in Ruby for Fluentd and in C/C++ for Fluent-bit. This certainly influenced
the array of tests in that, for instance, Cure53 viewed fuzzing with AFL as a viable route
to spotting possible weaknesses.
Unsurprisingly, the tests yielded more numerous and more diverse issues than the
assessments against the typical projects in Go. As noted, Cure53 managed to spot six
issues, four of which were considered to be vulnerabilities and two are documented as
general weaknesses. Three out of four vulnerabilities were ranked as “Critical” in terms
of severity. Quite clearly, these signify extreme risks and exploitability levels. Note
however that all documented issues have been spotted in the Fluent-bit and Fluentd-UI
codebases, Fluentd itself passed the tests without noteworthy findings.
Cure53, Berlin · 05/30/19 2/16
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
In the following sections, this report will first shed light on the scope by supplying the
URLs to all Fluentd platforms and code repositories in scope. Next up, the focus is
shifted to methodology and coverage. The report then furnishes case-by-case
descriptions of the findings, featuring both technical details and possible mitigation going
forward when applicable. Based on the results of this spring 2019 assessment, Cure53
issues a broader verdict about the privacy and security posture of the tested items.
Conclusions about the Fluentd software complex - including Fluent-bit and Fluentd-UI
are supplied in the final section of this document.
Scope
• Fluentd software, Fluent-bit plugins, Fluentd web-UI
◦ https://github.com/fluent/fluentd
◦ https://github.com/fluent/fluent-bit
▪ Inspected plugins were:
• in_tail
• in_forward
• out_forward
• out_elasticsearch
• filter_kubernetes
◦ https://github.com/fluent/fluentd-u i
▪ minor emphasis, early terminated and moved out of scope
Test Methodology
The following paragraphs describe the testing methodology used during the audit of the
Fluentd codebase and the selected external plugins. The test was divided into two
phases, each fulfilling different goals. In the first phase, the focus was on manual source
code reviews needed to spot insecure code patterns. In this realm, issues around
memory corruption, information leakage or similar flaws can often be found. During the
second phase, it was evaluated whether the stated security goals and premise can, in
fact, withstand real-life attack scenarios.
Part 1. Manual code auditing
This section lists the steps completed during the first phase of the audit against the
Fluentd unified logging layer. It describes the key aspects of the manual code audit.
Since only a few minor issues were spotted during this part, the list portrays the
thoroughness of the penetration test and ascertains the quality of the project.
Cure53, Berlin · 05/30/19 3/16
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
• General Ruby command/code sinks were checked, particularly in respect to their
application within the mechanics of plugin integration and execution.
• Special focus was given to the out_exec plugin. Since the command to be
executed is solely configured via a configuration file and the influenceable
arguments are correctly bound, no obvious vulnerability was discovered.
• Additional time was spent on checking the functionality of the in_tail,
out_mongodb, in_http, filter_* and parser_* plugins for path traversals and LPE.
• The rather limited HTTP-server component only exposes a few endpoints with
minimal request support and without actionable attack surface.
• Found the HTTP-client to support multiple types of HTTP-servers to post metric
data to; verified the handling of critical response headers like Content-Length.
• in_tail was audited for buffer overflows in its database functionality, in particular
for the usage of ‘%s’ in query construction, along with SQL injection. Extra time
was spent on the verification of docker_mode JSON parsing.
• Typically insecure sinks common in C applications (like sprintf, snprintf, memcpy,
strcpy, etc.) were checked for incorrect usage but found unexploitable.
• Checked authentication handling which was quickly dismissed since exploiting
the timing-unsafe code constitutes a rather unrealistic scenario.
• Audited the base implementation and derived use of protect_from_forgery within
the ApplicationController without being able to identify weaknesses.
• The insecure use of send within Mass-Assignment was deemed unexploitable.
• Password-change functionality was evaluated, field checks are done correctly.
• Handling of Rails’ secrets was checked for possibly implicated RCE weakness.
• Potentially insecure sinks like const_get, system and `` were found unexploitable.
• Calls to File.open and similar functions were found to be somewhat abusable
(http://localhost:9292/api/file_preview?file=/etc/passwd). Later on, they were
deemed unexploitable since they are only part of the application’s logic and log-
file parsing.
Part 2. Code-assisted penetration testing
The following list documents the steps completed during the second part of the test. A
code-