Flawed MatrixSSL Code Highlights Need for Better IoT Update Practices

Image

SSL is a primary layer of defense on the Internet that makes it possible to have authenticated private conversations even over an untrusted network. Implementing a robust and secure SSL stack, however, is not trivial. Mistakes can lead to large attack surfaces, such as what we witnessed with OpenSSL when “Heartbleed” was discovered. In the wake of “Heartbleed,” the security community had a number of very technical and public discussions surrounding coding practices and design choices made within various SSL stacks. The incident led many to recommend abandoning OpenSSL in favor of projects like NSS, GnuTLS and Polar SSL. In the case of devices, a common recommendation has been to use MatrixSSL with its super compact SSL/TLS stack designed specifically for Internet of Things (IoT) usage. A 2015 Internet-wide survey from SEC Consult’s 0-day research lab identified more than 80,000 devices online using sample keys published within the MatrixSSL source repository. Tens of thousands of other devices running MatrixSSL can also be found through the Shodan search engine, and an unknown but potentially massive number of additional devices are running within home networks without exposure to Internet-wide scans. The devices in question are very often network gateway devices like the WiMAX gateways or cable modems provided by Internet service providers, meaning a critical vulnerability in this code could expose a quite massive privacy incident. In the past year, well-known researchers Florian Weimer and Hanno Böck revealed dangerous crypto issues in MatrixSSL, including the ability to leak private key material. After some discussion of these flaws with Böck, I decided it would be worthwhile to take a look at the MatrixSSL X.509 certificate handling code for possible memory safety issues. To this end, I prepared an environment to conduct instrumented fuzz testing with the popular American Fuzzy Lop (AFL) tool from Google engineer and renowned security researcher Michal Zalewski. The targeted program’s state was monitored for changes in this process while data was manipulated. Within a matter of minutes, the testing produced results indicating memory safety issues, and before long, I had identified three distinct problems, including exploitable heap buffer overflow. CVE-2016-6890 has been assigned to the buffer overflow, CVE-2016-6891 has been assigned to a buffer over-read, and CVE-2016-6892 is assigned to an improper free in x509FreeExtensions(). Systems using MatrixSSL to process untrusted X.509 certificates, such as what might happen if a certificate is sent for client authentication, could be prone to remote unauthenticated code execution in the context of the SSL stack. In the case of a router or other IoT devices, this almost certainly means an attacker could gain complete control of an affected system as the root user. Certain embedded device manufacturers making use of MatrixSSL should have been notified of the issue in September and should be releasing updates to affected products soon if they haven’t already. Vendors and individual consumers of MatrixSSL can obtain updated code from the Matrix SSL GitHub repository. The changes to fix these issues are included in the commit for release 3.8.6. In my opinion, these vulnerabilities should not discourage the use of MatrixSSL any more or less than Heartbleed should encourage users to stay away from OpenSSL. The bigger problem is designing systems that encourage good security practices, such as regular patching. Unfortunately, many devices running the vulnerable MatrixSSL code will likely never be updated to incorporate fixes. This is due to a combination of factors, including that many IoT device vendors fail to release updates to resolve security defects and most users will never install them unless the update is automatic. If you are reading this as a vendor, my advice is to focus on building devices with better update mechanisms and development practices to support quick delivery. Consumers, on the other hand, need to press vendors toward long-term support commitments for the embedded devices they buy.