*Published: June 2024*


xrdp is a popular open-source remote desktop protocol (RDP) server for Linux systems. It lets you access your Linux desktop from anywhere using standard RDP clients, like those built into Windows. In September 2023, a vulnerability was discovered in xrdp that could let users bypass important security restrictions using a simple trick. This bug, tracked as CVE-2023-40184, exists in xrdp versions before .9.23.

In this article, we’ll explain what this vulnerability is, how it can be exploited, show you a code sample from the xrdp source, and give you clear guidance on protecting your systems.

What is CVE-2023-40184?

When you set up a Linux server accessible via xrdp, you might want to limit how many sessions a user can have at the same time. For example, you can use PAM's (Pluggable Authentication Modules) session control—usually managed in /etc/security/limits.conf—to only allow each user one remote session at a time.

But, due to a bug in older versions of xrdp, session errors weren’t handled properly. In particular, if something went wrong in the auth_start_session function (like a PAM error), xrdp would get an error code but actually start the session anyway. This directly lets users bypass your carefully-set PAM session restrictions.

Who’s affected?

Let's look at the logic behind the problem.

After a user enters their username and password on the xrdp login screen, xrdp tries to authenticate and start a session with PAM. If PAM says “sorry, you’re already at your max number of sessions” (or any other session error), the function auth_start_session() should return an error and the session shouldn't be created.

The BUG:
Instead, the function returned a non-zero value (usually 1), but the rest of the code ignored that and went ahead creating a session. That means any PAM-imposed session limit could be broken by just attempting to log in again and again.

Here's a simplified example drawn from the xrdp code

int auth_start_session(void)
{
    int rv = pam_open_session(...);
    // returns  on success, non-zero (e.g., 1) on failure

    // Buggy old code:
    return rv;  
}

...

// (where called)
if (auth_start_session() != )
{
    // does nothing! Should abort, but ignores the error.
}
// Session proceeds anyway

In words:
When auth_start_session() fails (i.e., session limit reached), the caller doesn’t stop the login. So the user gets a session even though they shouldn’t.

Fixed Behavior (in v.9.23):
Now, xrdp actually checks the result and aborts session creation if PAM says no.

Proof-of-Concept Exploit

This bug isn’t remotely exploitable in the classic sense, but here’s how a legitimate user (or attacker who knows a password) could exploit it:

`

echo "testuser hard maxlogins 1" >> /etc/security/limits.conf

User or attacker logs in *again* with the same credentials.

5. xrdp should block the second session, but due to CVE-2023-40184, it lets the user in. Result: Multiple sessions for testuser, bypassing safety limits.

---

Exploit Details

- Who can exploit? Any user with valid credentials—no superuser rights or code injection required.

Per-user system resource controls

- No known workaround: Disabling PAM restrictions removes risk, but then you have no session limits.

Official References

- xrdp GitHub Security Advisory GHSA-vc38-xvj5-7pmj
- CVE-2023-40184 at MITRE
- xrdp .9.23 Release Notes

On Ubuntu/Debian

sudo apt update
sudo apt install xrdp

On Fedora/CentOS

sudo dnf upgrade xrdp

Or build from source

git clone https://github.com/FreeRDP/xrdp.git
cd xrdp
git checkout v.9.23
./bootstrap
./configure
make
sudo make install

Restart xrdp

sudo systemctl restart xrdp

Conclusion

CVE-2023-40184 is a reminder to always keep your remote-access software patched—and to test your security controls after major upgrades. If you rely on PAM session restrictions (like most Linux admins), it’s essential to upgrade xrdp to .9.23 or newer. There is no other workaround.

Let your team know, and check your session limits today!


Have you been affected by this bug? Share your story or questions in the comments below.


*For more info, see the official advisory.*

Timeline

Published on: 08/30/2023 18:15:00 UTC
Last modified on: 09/15/2023 22:15:00 UTC