Penetration Test Report (Cure53): pentest report envoy

Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
Pentest-Report Envoy Proxy 02.2018
Cure53, Dr.-Ing. M. Heiderich, M. Wege, MSc. N. Krein, J. Larsson, Dipl.-Ing. A. Inführ,
BSc. J. Hector, G. Kopf, M. Münch
Index
Introduction
Scope
Test Coverage
Identified Vulnerabilities
EP-01-001 HTTP: Lacking Admin-Interface Security allows CSRF and DOS (High)
EP-01-002 HTTP: Potential BoF with HeaderStrings and Inline Buffers (Medium)
EP-01-003 HTTP: Potential UaF with HeaderStrings and Ref. Buffers (Medium)
EP-01-004 HTTP: Potential Integer Overflow during Header Encoding (Medium)
Miscellaneous Issues
EP-01-005 Common: strlcpy does not check for zero-sized Parameters (Low)
EP-01-006 Redis: User-Controlled Allocation leads to DoS (Medium)
EP-01-007 MongoDB: Stack Exhaustion via unbounded Recursion (Medium)
EP-01-008 MongoDB: Lax Parsing when processing malformed Messages (Low)
Conclusion
Introduction
“Originally built at Lyft, Envoy is a high performance C++ distributed proxy designed for
single services and applications, as well as a communication bus and “universal data
plane” designed for large microservice “service mesh” architectures.
Built on the learnings of solutions such as NGINX, HAProxy, hardware load balancers,
and cloud load balancers, Envoy runs alongside every application and abstracts the
network by providing common features in a platform-agnostic manner. When all service
traffic in an infrastructure flows via an Envoy mesh, it becomes easy to visualize
problem areas via consistent observability, tune overall performance, and add substrate
features in a single place.”
From https://www.envoyproxy.io
Cure53, Berlin · 02/27/18 1/13
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
This report documents the results of a penetration test and source code audit of the
Envoy proxy software. The project was carried out by Cure53 in February 2018 and
yielded eight security-relevant findings.
In terms of resources, the testing team comprised six members of the Cure53 and two
invited experts from Secfault Security GmbH. This overall eight-member team was
granted a time budget of twenty days to complete the assessment, with a caveat that an
adequate budget fraction should be preserved for the task of fix verifications and
communications to happen post-assessment. Moving on to the approach, it has to be
underlined that all relevant sources of the Envoy compound are openly available on
Github. This naturally means that the security evaluation was rooted in a white-box
premise since the envisioned attackers would have unlimited access to Envoy public
data.
It should be stated that the core scope items concerned exposition to rogue user-input,
with particular foci pointing to the HTTP parser, the header sanitizer and other
components of similar notoriety. What is more, the Envoy maintainers specifically
requested that the testers examine the TLS configuration, XFF and the generally
slowloris-style DoS attacks. While all this was inspected by Cure53, the focus on DoS
attacks also translated to looking at decompression of malicious HTTP content and
necessitated coverage with tests targeting the HTTP2 features. The Envoy Admin web
interface was placed under scrutiny of the testers as well, yet it was granted a much
lower priority because it is not expected to become a viable target. Upon a later request
from the maintainers, this component of the scope was actually ignored at sequent
stages of the project.
In terms of the execution of this assessment, the project was split into two phases, with
the first centered on the source code audit and a search for code bugs, and the second
encompassing a full-blown penetration test. The latter tried to attack an actually running
instance of Envoy and, quite clearly, investigated more complex attack scenarios, DoS
attacks, spoofing and bypasses. Under this premise, there was a clearly defined
attacker-model, specifically signifying a rogue and external attacker seeking to abuse
bugs and vulnerabilities in the Envoy entities. The presumed goals of the adversaries
would be to escalate their findings and make the Envoy project either slow or completely
shut down.
Among the already noted eight findings, there was an even mid-way split between four
actual security vulnerabilities and four general weaknesses. It is vital to emphasize that
no issues were marked as “Critical” in terms of security impact, severity or scope. This
absence of high-risk problems is a very good indicator for the broader state of security
matters at the Envoy compound.
Cure53, Berlin · 02/27/18 2/13
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
In the following paragraphs, this report will briefly focus on the technical outline of the
scope and illuminates the overall coverage. It then moves on to the findings which are
discussed on a case-by-case basis and presented together with mitigation advice. The
closing section allows for some general notes on the robustness of the Envoy project in
light of this Cure53 and Secfault Security GmbH’s joint assessment.
Scope
• Envoy Proxy
◦ https://www.envoyproxy.io/
◦ Exact snapshot that was used for testing
▪ https://github.com/envoyproxy/envoy/tree/master
▪ Commit c31077b28e4f8a7db17895d5d2570e806e9e2a3e
Test Coverage
This section comments on the test coverage reached by the testing team in the given
timeframe.
To start with the key item of the scope, the HTTP header manipulation was extensively
examined. The handling was investigated with a special focus on sanitization and
performed also with edge-case values. It was attempted to bypass header stripping,
inject duplicate headers and break the HTTP transcoding by message splitting. The
HTTP2 header compression aspect was covered in relation to the Denial-of-Service
attack vectors.
The Admin Web Interface was checked for typical security problems. The findings in this
realm were concerning as the item was admittedly inadequate in terms of no
Authentication, lacking Header Security and the absence of the critical CSRF token.
In relation with the JSON parser, state machine was inspected for malformed input
handling and related memory management defects. An existing problem with incomplete
JSON input was found but ultimately deemed unexploitable. A particular focus was
placed here on the intrinsic types like numbers and strings.
Next on the list was the gRPC implementation which was checked for interface
interference issues. Also in this context there was a preselected item of top-priority,
notably concerning the potential threading model incompatibilities. Buffering and
decoding problems were considered in the HTTP and JSON filters, wherein an existing
general data starvation case was unveiled but discarded as insignificant.
Cure53, Berlin · 02/27/18 3/13
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
The Lua implementation was investigated for common C interface misuse. The coroutine
state machine logic was verified. General integer overflows and null pointer
dereferences could not be identified in this realm.
For the event handling code in the Ratelimit component, extra scrutiny did not yield any
issues and found it adequate. Another aspect that generated no substantial findings was
the Redis protocol parser which was verified with special attention to logic issues like
treatment of invalid messages and illegal field lengths. Denial-of-service scenarios and
out-of-bound situations could not be found in this realm. This positive evaluation
extended to MongoDB parser code which was subjected to similar procedures as the
Redis parser implementation and held strong.
Further, the Network component was considered for potential logic and DoS bugs but
found to be rather clean and strong against the non-standard problem areas. Here the
explication could be derived from the lack of the ap