Reflections on InfoSec and the Development World – FreeRDP as a Case Study

Recap

In part 1 of this blog series we presented the “Reverse RDP” attack vector and the security hardening patch we designed and helped integrate into FreeRDP. The patch itself was targeting the software design issue that led to many of the info-leak vulnerabilities that were discovered in the project.

Just to recap, my first encounter with FreeRDP was in 2018, when I was looking for client-side vulnerabilities in code that handles incoming RDP messages. After several rounds of vulnerability research and coordinated disclosures, I grew tired of this game of whack-a-mole. Surely something could be done to handle the software design flaw that leads to many of these vulnerabilities. This led to the patch I submitted to FreeRDP on 2021, and that was just included in the project’s recent (3.0.0) release.

In this 2nd part to the series, we will discuss the the wider aspects encountered during the research on FreeRDP. How come the software design flaw in the project wasn’t fixed between 2018-2021 despite repeated coordinated disclosures of vulnerabilities that stemmed from it? How come multiple research teams reported such issues while none of them helped fix the core flaw? Does the InfoSec community even incentivizes researchers to help resolve large software issues in the encountered projects?

As in part 1, this article will combine both of the perspectives the vulnerability researcher who researched FreeRDP (me in the past) and the software developer that helped them fix their design issue (me in the present). Hopefully, this will help the reader understand the full picture about the interaction between the InfoSec world and the Development world, interaction that in my opinion should be significantly improved.

Let’s start.

Lessons from Securing FreeRDP

Introduction

The story behind this 2-part blog series started quite a while ago, on September 2018, when I started a vulnerability research on a (then) novel attack vector: “Reverse RDP” while working at Check Point Research (CPR). Luckily, this research project proved itself right away, and on October the same year we started the coordinated disclosure process with the affected projects: rdesktop, FreeRDP (Open sources) and Microsoft’s MSTSC.

The research itself included several rounds of vulnerability research and publications, and was supposed to reach its end on July 2020 with the publication of a full remote code execution chain (demo) on the FreeRDP-based Apache Guacamole. Sounds like the end of story, doesn’t it?

Well, not only this wasn’t the end, chronologically speaking we were barely halfway there.

While finding a vulnerability, reporting it and waiting for the project to fix it might take some time, eventually we are talking about an isolated fix for a single vulnerability. It is common practice to measure these processes in a magnitude of a few months (90 days disclosure process). Not exactly a smooth waiting process, yet it could be worse. In addition, one might wonder about the overall benefits that might arise from such an isolated patching process. After all, similar vulnerabilities will probably still be discovered in said product, thus turning into a cat-and-mouse game between attackers and defenders.

In this blog post we will present the technical details of the attempt to provide a complete fix to the root cause of the software vulnerabilities found in FreeRDP, and the timeline of this process. Our case study will be a patch I submitted to the project on October 2021 and that just recently (Mid-December 2023) was announced as part of the latest release (3.0.0) of the project. Yup, you read it right. The fix was merged two years ago, was available on the development branch, and yet it was officially launched only the past few days.

To give you a sense of the security implications of this fix, here are some statistics about it. If only the fix was merged early on in 2018, it would have blocked more than half of the info-leak vulnerabilities that were reported to the project. Under my initial role as a security researcher, I found this timeline staggering. After all, what could be the reason for a 2 year fix process? And still, in my current capacity as as software developer I can say that it was actually a good and reasonable software release process on behalf of the project.

The goal of this article series is to present FreeRDP through two perspectives: Information security research on the one hand, and software development on the other. In this process, I hope to shed some light on the side that in my opinion gets too little attention and consideration from the infosec world: The team that actually develops the project.

Let’s start.