Wings is the server control plane for the Pterodactyl game-server management panel. In versions up to and including 1.13.2, the SFTP write path does not enforce a server's disk quota during a transfer, allowing a tenant with SFTP write access to a single server to exhaust the host node's physical disk and take down every server on it. Wings checks available space only once, as a boolean, when the write handle is opened, using a stale cached usage value and without knowing the size of the incoming data, and it then returns a raw, unaccounted file handle that is never re-checked as the transfer proceeds. A single upload can therefore be written without bound, far beyond the configured disk limit, until the node's disk is full, and because a server stopped for exceeding its limit is not treated as suspended, SFTP writes are still accepted even after the quota is already exceeded. This issue is fixed in version 1.13.3.

Summary Websockets within wings lack proper rate limiting and throttling. As a result a malicious user can open a large number of connections and then request data through these sockets, causing an excessive volume of data over the network and overloading the host system memory and cpu.

Additionally, there is not a limit applied to the total size of messages being sent or received, allowing a malicious user to open thousands of websocket connections and then send massive volumes of information over the socket, overloading the host network, and causing increased CPU and memory load within Wings.

Summary Wings does not consider SQLite max parameter limit when processing activity log entries allowing for low privileged user to trigger a condition that floods the panel with activity records

Details After wings sends activity logs to the panel it deletes the processed activity entries from the wings SQLite database. However, it does not consider the max parameter limit of SQLite, 32766 as of SQLite 3.32.0.

If wings attempts to delete more than 32766 entries from the SQLite database in one query, it triggers an error (SQL logic error: too many SQL variables (1)) and does not remove any entries from the database. These entries are then indefinitely re-processed and resent to the panel each time the cron runs.

https://github.com/pterodactyl/wings/blob/9ffbcdcdb1163da823cf9959b9602df9f7dcb54a/internal/cron/activitycron.go#L81 https://github.com/pterodactyl/wings/blob/9ffbcdcdb1163da823cf9959b9602df9f7dcb54a/internal/cron/sftpcron.go#L86

PoC Any method that can create the required 32767+ activity entries can trigger this vulnerability. It can (and has) been triggered by normal (non-malicious) use. I attached a simple PoC I used while verifying this that uses sftp to quickly create many small files, thus creating activity entries in the SQLite database. https://ptero.co/mococesoca.go

Impact By successfully exploiting this vulnerability you can trigger a situation where wings will keep uploading the same activity data to the panel repeatedly (growing each time to include new activity) until the panels’ database server runs out of disk space.

Summary Pterodactyl does not revoke active SFTP connections when a user is removed from a server instance or has their permissions changes with respect to file access over SFTP. This allows a user that was already connected to SFTP to remain connected and access files even after their permissions are revoked.

Details When a user opens a connection to a server using the Wings SFTP server instance the permissions are checked and returned from the authentication API call made to the Panel. However, credentials are not checked again after the initial handshake. Thus, if a user is removed from a server in the panel or have their permissions modified, those permissions are not updated in the SFTP connection.

As a result, a user that has already gained access to a server's files via the SFTP subsystem will maintain those permissions until disconnected (via Wings restart, or a manual disconnection on their end).

[!NOTE] This issue impacts the SFTP subsystem for server files specifically. There is no exposure of Wings private data, or any data outside of a server's local filesystem. Additionally, a user must have been connected to SFTP at the time of their permissions being revoked in order for this issue to be exploited. If a user was not connected, they would not be able to connect once their permissions were reduced.

Fix Please upgrade to wings@1.12.0 and panel@1.12.0 to resolve this issue. Patches are available via the implementation PRs, but it is recommended to apply by upgrading the entire instance.

Impact

This vulnerability impacts anyone running the affected versions of Wings. The vulnerability can potentially be used to access files and directories on the host system. The full scope of impact is exactly unknown, but reading files outside of a server's base directory (sandbox root) is possible.

In order to use this exploit, an attacker must have an existing "server" allocated and controlled by Wings. Details on the exploitation of this vulnerability are embargoed until March 27th, 2024 at 18:00 UTC.

Resolution

In order to mitigate this vulnerability, a full rewrite of the entire server filesystem was necessary. Because of this, the size of the patch is massive, however effort was made to reduce the amount of breaking changes. While tests were written to ensure security and functionality, there may be some semantic differences of certain operations, such as different errors being returned for example. If you notice any major semantic differences, please open an issue on our issue tracker so it can be resolved. <https://github.com/pterodactyl/panel/issues/new/choose>

Patches

This vulnerability has been resolved in version v1.11.9 of Wings.

Everyone should update to Wings v1.11.9 (or newer).

Workarounds

None.

Wings is Pterodactyl's server control plane. Affected versions are subject to a vulnerability which can be used to create new files and directory structures on the host system that previously did not exist, potentially allowing attackers to change their resource allocations, promote their containers to privileged mode, or potentially add ssh authorized keys to allow the attacker access to a remote shell on the target machine. In order to use this exploit, an attacker must have an existing "server" allocated and controlled by the Wings Daemon. This vulnerability has been resolved in version v1.11.3 of the Wings Daemon, and has been back-ported to the 1.7 release series in v1.7.3. Anyone running v1.11.x should upgrade to v1.11.3 and anyone running v1.7.x should upgrade to v1.7.3. There are no known workarounds for this vulnerability.

Workarounds

None at this time.

Wings is Pterodactyl's server control plane. This vulnerability can be used to delete files and directories recursively on the host system. This vulnerability can be combined with GHSA-p8r3-83r8-jwj5 to overwrite files on the host system. In order to use this exploit, an attacker must have an existing "server" allocated and controlled by Wings. This vulnerability has been resolved in version v1.11.4 of Wings, and has been back-ported to the 1.7 release series in v1.7.4. Anyone running v1.11.x should upgrade to v1.11.4 and anyone running v1.7.x should upgrade to v1.7.4. There are no known workarounds for this issue.

Impact

An authenticated user who has access to a game server is able to bypass the previously implemented access control (https://github.com/pterodactyl/wings/security/advisories/GHSA-6rg3-8h8x-5xfv) that prevents accessing internal endpoints of the node hosting Wings in the pull endpoint. This would allow malicious users to potentially access resources on local networks that would otherwise be inaccessible.

Workarounds

Enabling the api.disableremotedownload option or updating to the latest version of Wings are the only known workarounds.

Patches

https://github.com/pterodactyl/wings/commit/c152e36101aba45d8868a9a0eeb890995e8934b8

Impact

If the Wings token is leaked either by viewing the node configuration or posting it accidentally somewhere, an attacker can use it to gain arbitrary file write and read access on the node the token is associated to.

Workarounds

Enabling the ignorepanelconfigupdates option or updating to the latest version of Wings are the only known workarounds.

Patches

https://github.com/pterodactyl/wings/commit/5415f8ae07f533623bd8169836dd7e0b933964de

Impact

This vulnerability impacts anyone running the affected versions of Wings. This vulnerability can be used to gain access to the host system running Wings if a user is able to modify an server's install script or the install script executes code supplied by the user (either through environment variables, or commands that execute commands based off of user data).

Patches

This vulnerability has been resolved in version v1.11.6 of Wings, and has been back-ported to the 1.7 release series in v1.7.5.

Anyone running v1.11.x should upgrade to v1.11.6 and anyone running v1.7.x should upgrade to v1.7.5.

Workarounds

Running Wings with a rootless container runtime may mitigate the severity of any attacks, however the majority of users are using container runtimes that run as root as per our documentation.

SELinux may prevent attackers from performing certain operations against the host system, however privileged containers have a lot of freedom even on systems with SELinux enabled.

TL;DR: None at this time.

Extra details

It should be noted that this was a known attack vector, for attackers to easily exploit this attack it would require compromising an administrator account on a Panel. However, certain eggs (the data structure that holds the install scripts that get passed to Wings) have an issue where they are unknowingly executing shell commands with escalated privileges provided by untrusted user data.

Wings is the control plane software for the open source Pterodactyl game management system. All versions of Pterodactyl Wings prior to 1.4.4 are vulnerable to system resource exhaustion due to improper container process limits being defined. A malicious user can consume more resources than intended and cause downstream impacts to other clients on the same hardware, eventually causing the physical server to stop responding. Users should upgrade to 1.4.4 to mitigate the issue. There is no non-code based workaround for impacted versions of the software. Users running customized versions of this software can manually set a PID limit for containers created.