CVE-2024-32460 - FreeRDP `/bpp:32` Legacy GDI Bug Leads to Out-of-Bounds Read

FreeRDP is a popular open source implementation of Microsoft’s Remote Desktop Protocol (RDP). It lets users connect to Windows desktops and servers from Linux, macOS, Windows and embedded devices. In April 2024, researchers found a security issue in FreeRDP known as CVE-2024-32460. This bug affects clients using the “legacy GDI” drawing path with /bpp:32 (32 bits per pixel flag) and can lead to an out-of-bounds read in affected versions.

Let’s break things down, look at the risks, and show mitigation and patching steps with clear code samples.

What is the Vulnerability?

If you use a FreeRDP-based client (like xfreerdp) with the /bpp:32 parameter on a vulnerable version of the library, and you’re using the old “GDI” drawing engine, a bug in FreeRDP’s code can make it read memory outside the expected buffer (“out-of-bounds read”). This can result in:
- Application crashes (due to segmentation fault/access violation)

Potential foothold for further exploitation, if attackers can control what is being read

This vulnerability does not impact all users—only legacy setups using 32-bit color depth and the default GDI path, on versions prior to 3.5. (main branch) or 2.11.6 (LTS/2.x branch).

Technical Details

The bug is in the code that handles drawing when /bpp:32 is passed, and the session uses the GDI (“Graphics Device Interface”) path (the default unless you select /rfx or /gfx):

Vulnerable code:
(Based on real GitHub diff fixing this issue)

// (Pseudo)snip from update.c
// Problem: improper bounds checking with GDI drawing and bpp:32

if (settings->ColorDepth == 32)
{
  // Allocates a buffer for drawing, but size can be miscalculated
  // ... if source or destination width/height fields are not checked
  BYTE* dst = (BYTE*)calloc(width * height, 4); // bpp is 4 bytes

  // <vulnerable processing...>
  memcpy(dst, src, width * height * 4); // May over-read src if values are bad
}

The key point: if the RDP server sends crafted drawing orders with tricky sizes, the FreeRDP client may read outside the bounds of the source buffer (src) when copying or converting the image data.

Exploitation Example

An attacker (someone controlling the RDP server or man-in-the-middle network traffic) can send bad bitmap update messages with misreported width/height or data length. The client, on certain connections, will then read memory before/after the buffer and possibly:

Here is how a session might look (for exposure)

xfreerdp /v:malicious.server /bpp:32

If the attacker’s server sends the crafted data, the client may crash as described.

Fix and Mitigation

Patching

The project fixed the bug in

- FreeRDP 3.5. (mainline)
- FreeRDP 2.11.6 (LTS)

Update as soon as possible

# Ubuntu/Debian (if package is available)
sudo apt update && sudo apt install freerdp2-x11

# Or build from source:
git clone --branch 2.11.6 https://github.com/FreeRDP/FreeRDP.git
cd FreeRDP && cmake . && make && sudo make install

Instead of relying on the GDI drawing path with /bpp:32, you can use a modern drawing path by

- Adding /gfx (Graphics Pipeline) or /rfx (RemoteFX) to your client’s options

Example

xfreerdp /v:your.server /gfx
# or
xfreerdp /v:your.server /rfx

Note:
Your RDP server must support the selected advanced codec (/rfx or /gfx)—some older or default Windows RDP setups may not.

For more

- Official FreeRDP Security Advisory GHSA-5pc4-hvwg-9q44
- Patched commit on GitHub
- Red Hat Security advisory
- FreeRDP Releases

Summary Table

| Product | Vulnerable? | Fixed In | Workaround |
|-----------------|----------------------------------|--------------------|---------------|
| FreeRDP 3.x | < 3.5. with /bpp:32 + GDI | 3.5. | /rfx, /gfx|
| FreeRDP 2.x LTS | < 2.11.6 with /bpp:32 + GDI | 2.11.6 | /rfx, /gfx|
| Windows Client | N/A (Not FreeRDP) | - | - |

Conclusion

CVE-2024-32460 is a good example of how complex image handling in network protocols can introduce subtle but critical bugs. If you use FreeRDP, update your clients to the latest fixed version or switch to the modern /rfx or /gfx paths until you can. If you maintain custom RDP-based software, check for similar logic—never trust remote image sizes without bounds checking!

Timeline

Published on: 04/22/2024 22:15:07 UTC
Last modified on: 06/10/2024 18:15:33 UTC