Guest blog, written by Robert Hörr (e-mail: robert (dot) hoerr (at) t-systems (dot) com)
(Security Evaluator of Deutsche Telekom Security GmbH)
My name is Robert Hörr and I am working as a penetration tester at Deutsche Telekom Security GmbH. Pentesting is mostly done on security software, as for instance the wolfSSL TLS library to discover issues like the Heartbleed bug of OpenSSL. I have discovered some issues in the wolfSSL TLS library (see https://www.wolfssl.com/docs/security-vulnerabilities) using my own developed TLS-FAST (Fast Automated Software Testing) framework. In the future my goal is to provide our customers a FAST service to test their software products.
Why are TLS libraries tested?
It is important to check TLS libraries because TLS is one of the most deployed security protocols in the Internet. Typically, there is no client authentication on a standard Internet server by default configuration, to ensure that every Internet user can use it. Hence, any vulnerability in the TLS protocol implementation can be exploited easily. There are many TLS vulnerability entries in the public CVE list and the number is growing constantly.
Which testing approach is used?
The wolfSSL TLS library is a constantly growing project, with more and more functionalities, extensions and TLS versions added to its scope over time. This offers wolfSSL customers maximal flexibility in the use of the wolfSSL TLS library. Because of this growing process, the source code gets more complex. It is hardly possible to check all code paths by a manual source code review. Hence, dynamic automated machine testing must be performed. An efficient way to perform this kind of testing is the code coverage fuzzing approach. This fuzzing variant allows to discover all code paths. The discovering speed depends on the available computing resources. The code paths are checked systematically for memory leaks, buffer overflows, logical issues and so on.
Which tools are used for TLS testing?
Several open source fuzzing tools, which are based on this fuzzing approach, are public available. Some of the most popular ones are AFL, LibFuzzer and HonggFuzz. The community discovered many issues using any of them. Each of these tools has its strengths in certain fuzzing areas, for example HonggFuzz has a higher number of executions per second than the other tools. To benefit from all fuzzers at the same time, I have developed the FAST (Fast Automated Software Testing) framework for TLS libraries, which combines the strengths of several fuzzing tools. Over the time, the following features and approaches have been added to this framework:
- Deterministic runs:
- The entire testing process is deterministic, so that discovered issues can be reproduced easily.
- Independence:
- The testing process is independent from the environment. So that for example the process can be executed on every operating system.
- Realistic use:
- The TLS libraries are used realistically to discover issues occurring in the field. So for example the original source code and the code paths should not be changed.
- Detection:
- All kinds of implementation issues can be discovered by the testing process. For example buffer overflows or memory leaks are detected by the AddressSanitizer.
- Logical issues or vulnerabilities are discovered by specific TLS tests.
- Scalability:
- The testing process can be scaled linearly by adding more computation and storage resources.
- Coverage:
- Code coverage is used to detect all code paths. If all applicable code paths are identified, the actual testing will start.
- Automation:
- The full testing process runs automatically on a machine. Therefore no manual work is needed anymore.
- Flexibility:
- The framework can be adapted to another tested software. This adaption to a new software takes some hours or days.
How is the wolfSSL TLS library tested?
The wolfSSL TLS library includes several TLS versions, features, extensions and crypto options. The testing focus was mainly defined on the TLS handshake of TLS versions 1.2, 1.3 and their extensions and features, because the TLS handshake implementations include most of the known TLS vulnerabilities (CVEs) and the other TLS versions are not recommended to use anymore.
Currently I am using the TLS-FAST framework for checking the API functions wolfSSL_accept(…) and wolfSSL_connect(…) of the wolfSSL TLS library master branch. This master branch gets the newest updates first. So the master branch must be tested to discover the newly added issues from the updates and to avoid that these new issues are linked into a stable version.
Most issues I have found (see https://www.wolfssl.com/docs/security-vulnerabilities) are located in the parsing process of the TLS messages client_hello and server_hello. These issues were buffer overflows or uninitialized memory. They could be fixed easily by simply adding a sanity check or a memory initialization. For the sake of completeness, it should also be mentioned that the wolfSSL TLS library source code includes about 521,655 lines of code (without comments and blanks). Hence, it is not easy to avoid issues without fuzzing.
What will be fuzzed in the future?
Currently I am testing the wolfSSL TLS library only, but wolfSSL provides further libraries, like wolfCrypt. These libraries interoperate and make use of each other. For example, the wolfSSL TLS library uses functions from the wolfCrypt library. So the other libraries must be tested, too. In the future, I will develop a new FAST framework for each of them. These new FAST frameworks will have the same features and approaches like the TLS-FAST framework. Over the time, new features will be added to these FAST frameworks.
My goal is to provide our customers a FAST framework as a testing service for their software products. This service detects all issues as quickly as possible.
Contact wolfSSL at facts@wolfssl.com with questions about the wolfSSL embedded SSL/TLS library, or to get started with wolfSSL in your project! wolfSSL supports TLS 1.3, FIPS 140-2/3, DO-178, and much more!