Lessons Learned From Open Source Security Audits: Insights From OCX 2024

As open source adoption grows, attackers are paying more attention to finding new and creative ways to exploit vulnerabilities in popular projects.

This is why security audits are an important and valuable element of open source development. Having an outside team look specifically and formally into a project's architecture and code can reveal security gaps that even the broad knowledge base of an open source community may not have captured.

In the last two years, the Eclipse Foundation has conducted several external security audits of its projects with funding from the Alpha-Omega project and support from the Open Source Technology Improvement Fund (OSTIF).

During the Open Community Experience 2024 (OCX) conference, representatives of various projects joined the stage to talk about their recent experiences with security audits. 

The panelists were: 

• Simone Bordet from Eclipse Jetty. Eclipse Jetty is one of the world’s most widely deployed web server and servlet containers, supporting many protocols like HTTP/1, HTTP/2, HTTP/3, and various Jakarta EE standards. Jetty is usually integrated with application code that handles data. 
• Scott Fryer from Adoptium and Eclipse Temurin. Eclipse Temurin is the open source Java SE build based upon OpenJDK. The Temurin project includes, among other things, build scripts for different configurations.
• Mickael Istria from Eclipse Equinox p2. The p2 project is a sub-project of Eclipse Equinox that focuses on provisioning technology for OSGi-based applications.
• Sven Erik Jeroschewski from Eclipse Kuksa. The Eclipse Kuksa project aims to provide shared building blocks for the software-defined vehicles that can be shared across the industry.
• Marc Nuri San Felix from Eclipse JKube joined on video. Eclipse JKube is a collection of plugins and libraries that are used to build container images of Java applications using Docker, JIB or S2I build strategies.
• Marta Rybczynska from the Eclipse Foundation Security Team moderated the panel.

Expectations and Scope

The panel assembled representatives from projects using various programming languages and frameworks at different levels of the software stack. Each project independently defined its audit scope, enabling focused reviews of specific software modules. Indeed, audits were time-based, with auditors allocated a set number of hours per project. Consequently, only parts of each codebase were reviewed.

The session started with an introduction of the different projects:

Eclipse Jetty’s audit focused on aspects as header and cookie parsing for HTTP/1 and HTTP/2, the security of the WebSocket, HTTP/2, and HTTP/3 implementations, including protocols and standards like QUIC, HPACK, and QPACK, and secure access to the file system when serving static resources.

Eclipse Temurin has a different scope, so the audit had a different objective. The auditors focused on authentication and authorisation, data flow, and command injection vulnerabilities in the build scripts.

The Equinox p2 focused its audit on its new feature, the new signature verification mechanism included in the Eclipse IDE 2023-06.

Eclipse Kuksa is a relatively new project that takes its place in the dynamic domain of  Eclipse SDV (Software Defined Vehicle). In this case, the project wanted assurance of its data broker and Python client, two elements of the bigger picture.

Finally, Eclipse JKube is closely linked to the Kubernetes and OpenShift ecosystems. The main focus was on the security of artifacts generated by JKube and the use of current security best practices in Kubernetes configuration.

During the discussion, Simone Bordet shared that Jetty had undergone previous audits and had modest expectations based on those experiences. In contrast, for projects like Equinox p2 and Kuksa, it was their first audit, and the teams were curious about the process and outcomes.

Stages of the Audit

Each of the audits had the same general structure, with the phases of threat modelling and code review, and auditors spent a fixed amount of time on each project. 

• The thread modelling described a typical usage of each project and possible ways attackers could approach it. 
• The code review consisted of a review of selected parts of the code, resulting from the early decision of the project and the threat analysis, using automated tools and manual review.

Surprising Findings

In the case of Eclipse Jetty, auditors concentrated the effort on parsers. The Jetty team was pleasantly surprised by the detailed analysis of some obscure RFCs (Requests for Comments specifying Internet protocols) and related findings.

Eclipse Termurin audit revealed fewer vulnerabilities than expected, reflecting the team’s secure coding efforts. Still, the audit caused the removal of support of some old Linux distributions that required unsafe settings.

Marc Nuri San Felix from JKube was surprised by the auditors' ability to understand the project’s complex architecture quickly.

Recommendations

The audit results have been published and all discovered issues have been fixed. Audit results can be found in these blog posts:

• Eclipse Jetty audit published on the Eclipse Foundation blog.
• Eclipse Adoptium - Temurin audit published on the Eclipse Foundation blog en-completed. The Temurin team has provided their response to audit findings and details of their solutions in the Security Assessment Response. 
• Eclipse Equinox p2 audit published on the Eclipse Foundation blog. 
• Eclipse Kuksa audit published on the Eclipse Foundation blog. 

• Eclipse JKube audit post on the Eclipse Foundation blog. 

   

Benefits for Other Projects

The panelists encouraged any project that has the opportunity to get an audit to do so. They also pointed out that the audits that have been completed were documented thoroughly. The results are detailed, including links to the tools and configurations that were used as well as clear descriptions of procedures. In other words, the materials are there if developers working on similar projects would like to review and audit their own documentation and code if they’d like to give it a try. 

We’d like to thank the Alpha Omega project for their funding, which made these audits possible, as well as the assistance provided by the Open Source Technology Improvement Fund. 

If your project is interested in a future security audit opportunity, contact the Eclipse Foundation Security team at security@eclipse-foundation.org