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.

CPR Publications

Here I will keep an up-to-date list of my publications, as they were published on the research blog of Check Point Research (CPR). The list is ordered by research topics, in a chronological order, meaning that all RDP blog post parts are listed one after the other, instead of by their chronological order.

As some of the research projects were also presented in conferences (Black Hat USA, DEFCON, CCC, etc.), here is the link to the GitHub repo which contains all of the conference slides + demo videos: conference presentations.

Publications list:

• Check Point Responds to AMD Flaws (backup)
• MMap Vulnerabilities – Linux Kernel (backup)
• What The FAX?! (backup) – Conference Talk
• Reverse RDP Attack – Part I: Code Execution on RDP Clients (backup) – Conference Talk
• Reverse RDP Attack – Part II: The Hyper-V Connection (backup) – Conference Talk
• Reverse RDP Attack – Part III: The Path Not Taken (backup)
• Karta – Matching Open Sources in Binaries (backup) – Conference Talk
• Thumbs Up: Using Machine Learning to Improve IDA’s Analysis (backup)
• The NSO WhatsApp Vulnerability – This is How It Happened (backup)
• Say Cheese: Ransomware-ing a DSLR Camera (backup) – Conference Talk
• OptOut – Compiler Undefined Behavior Optimizations (backup)
• Safe-Linking – Eliminating a 20 year-old malloc() exploit primitive (backup)
• Would you like some RCE with your Guacamole? (backup)
• Don’t be silly – It’s only a lightbulb (backup) – Conference Talk
• Graphology of an Exploit – Hunting for exploits by looking for the author’s fingerprints (backup) – Conference Talk
• Graphology of an Exploit – The Story of PlayBit (backup)
• Game On – Finding vulnerabilities in Valve’s “Steam Sockets” (backup)

Blog Updates

On February 2018 I started working on the vulnerability research team at Check Point. This means that my blog posts (such as Linux Kernel MMap Vulnerabilities, and Check Point Responds to AMD Flaws) are now published in our group’s research blog. Although my personal research blog won’t be updated in the near future, I can guaranty that we have some very interesting research results that are waiting to be published, and so subscribing to the group’s blog is highly recommended.

Faxploit Update:

As I promised, we had a very interesting research underway, and it is now published. We were able to remotely exploit all-in-one printers using only a phone line! By sending a malicious FAX we took over a target printer and managed to spread through the network it is connected to. Here is the link to our research.

For more updates, check out the group’s blog.

Thanks for visiting,  @Eyalitkin

ELF caves: hiding in the corner

During exploitation of ELF binaries, it is quite common that one needs to find a writable memory region: a writable “cave”. In this post I’ll present two generic techniques to find such caves, without the need to reverse engineer the target binary.

Tales from a Bug Bounty

On the 18th of November I submitted a ticket to the Monero HackerOne Bug Bounty program. This is the ticket regarding ‘GarlicRust’, a vulnerability I publicly disclosed in my previous blog post. Unfortunately for me, Monero updated the bounty terms after my submission, and the bottom line is that I did not receive the bounty I initially expected.

CVE Publication: GarlicRust CVE 2017-17066

The GarlicRust vulnerability, a.k.a CVE 2017-17066, is a major info-leak vulnerability in C++ implementations of the I2P router. The vulnerability was found in i2pd and kovri, as part of the Monero bug bounty program.

Cartography – Lighting up the shadows

In the previous post I demonstrated how to bypass Microsoft’s RFG, a.k.a. “Shadow Stack”, assuming we can locate the shadow stack. In this post I’ll fill up the missing details, and will describe how to find “Shadow” memory sections in a process’s virtual address space. While the technique works both in Windows and Linux, and it will demonstrate some key differences between the two operating systems.

Bypassing Return Flow Guard (RFG)

At the end of 2016, while checking for updates in Microsoft’s bounty program, I saw a reference to a new defense mechanism called “Return Flow Guard” (RFG). Since at that time I just finished the work on Liberation Guard, I took the time to check if can bypass this new protection method. This post will describe my attack on Microsoft’s Return Flow Guard, an attack that achieves full bypass of the protection method.

MRuby VM Escape – step by step

Last post we discussed format string implementation vulnerabilities, and focused on the vulnerabilities in the (C/M)Ruby implementation. Since shopify integrated MRuby in a VM-like scenario, we will present a step-by-step exploitation of the main shown vulnerability, achieving a VM escape.