Version 5.3.2 of the Passenger application server for Ruby, Node.js, Meteor and Python has been released. This release contains fixes for 4 CVEs and we urge you to upgrade.
[CVE-2018-12029] CHMOD race vulnerability
The Pulse Security team discovered a vulnerability in Passenger.
The file system access race condition allows for local privilege escalation and affects the Nginx module for Passenger versions 5.3.1, all the way back to 3.0.0 (the chown command entered the code in 2010).
The vulnerability was exploitable only when running a non-standard
passenger_instance_registry_dir, via a race condition where after a file was created, there was a window in which it could be replaced with a symlink before it was chowned via the path and not the file descriptor.
If the symlink target was to a file which would be executed by root such as root's crontab file, then privilege escalation was possible.
This is now mitigated by using
Improved security warnings for various directories
We recognized that CVE-2018-12029 could be an indication of a larger class of similar vulnerabilities, so we immediately started investigating our codebase for other vulnerabilities. We found that a lot of security properties depend on the security of various directories that the user configured Passenger to use. Therefore, we've introduced more security checks into Passenger.
We now check the permissions on the instance registry directory in the same way we already check the Passenger root directory. If the instance registry directory is not secure, that can result in arbitrary file overwrites so it's good practice to fix these warnings if you see them.
[CVE-2018-12026 - 12027 - 12028] SpawningKit exploits
Continuing our security investigation, we found a few vulnerabilities in SpawningKit, affecting Passenger versions 5.3.0 - 5.3.1. SpawningKit is subsystem in Passenger responsible for spawning application processes, and it has gotten a major overhaul in version 5.3.0. However this overhaul introduced new vulnerabilities, which allow a malicious app to cause:
- a local DoS on the system, or
- a local privilege escalation, or
- a local information disclosure
Malicious users on the same system, other than the app's user, could use race conditions to make Passenger connect to (and forward traffic to) arbitrary sockets.
In the first case a malicious app could report its PID incorrectly, then fail to start at which point Passenger would kill the PID regardless of who owned it.
In the second and third case, reads and writes to arbitrary file paths could be induced by replacing specific path elements with symlinks.
In the last case if any of the parent directories of the app socket dir is writable by another user (Joe) that is not the app's user (Jane), then Joe can swap that directory with contents he controls. That way, Joe can cause Passenger to connect to (and forward Jane's traffic to) a process that does not actually belong to Jane.
We mitigate these issues with extra permission checks, by using symlink-resistant I/O operations, and by insisting that any sockets must be created inside the instance directory's app's subdirectory. As well as by not killing the PID returned by the preloader unless we have verified that it is indeed genuine (owned by the app user).
Spawning Error Reporting
During the Handshake step of spawning an app, we ensure that more kinds of spawning exceptions contain environment variable information. This will help us detect bugs or security attacks in the future.
Various improvements & fixes
- Fixes Meteor support in non-bundled mode (regression from 5.3.0). Closes GH-2082.
- [Apache] Fixes PassengerMaxInstancesPerApp not being respected (regression from config refactor in 5.2.0). Closes GH-2059.
- [Enterprise, Apache] Fixes PassengerMaxInstances not being respected (regression from config refactor in 5.2.0).
- [Enterprise] Fixes passenger-irb being unable to connect to an app process (regression from 5.3.0). Closes GH-2087.
Besides support for the latest software (Nginx stable, Ubuntu), the 5.3 series of Passenger features per-application logfiles. There has been a lot of work on the internals to enable vastly improved error reporting.
Upgrading to 5.3.2
We strongly advise staying up to date with the latest version.
Check out our upgrade guides for the different platforms:
If you are upgrading from 4.x, please read the 5.0 upgrade notes to learn about potential upgrade caveats.