[SECURITY] CVE-2024-27456 - Insecure File Permissions in rack-cors v2.0.1

[ajmilazzo]

Description

I have identified an issue with insecure file permissions in the rack-cors Ruby gem, starting from version 2.0.1. Previous versions of the gem do not exhibit this problem.

The files are set with world-writable permissions (666), which could lead to unauthorized disclosure or modification of the files, posing a security risk.

rack-cors 2.0.1:

./lib/rack/cors
total 24
-rw-rw-rw- 1 root root 4602 Feb 22 18:44 resource.rb
drwxr-xr-x 2 root root 4096 Feb 22 18:44 resources
-rw-rw-rw- 1 root root 1435 Feb 22 18:44 resources.rb
-rw-rw-rw- 1 root root 1424 Feb 22 18:44 result.rb
-rw-rw-rw- 1 root root   88 Feb 22 18:44 version.rb

rack-cors 2.0.0:

./lib/rack/cors
total 24
-rw-rw-r-- 1 root root 4365 Feb 22 18:49 resource.rb
drwxr-xr-x 2 root root 4096 Feb 22 18:49 resources
-rw-rw-r-- 1 root root 1435 Feb 22 18:49 resources.rb
-rw-rw-r-- 1 root root 1424 Feb 22 18:49 result.rb
-rw-rw-r-- 1 root root   88 Feb 22 18:49 version.rb

Steps to Reproduce

1. Install rack-cors version 2.0.1.
2. Check the permissions of the files using the command ls -l.

You should observe that the permissions are set to 666, indicating that they are readable and writable by all users.

Expected Behavior

To prevent unauthorized access or modifications, files distributed with the gem should have secure default permissions, limiting write access to the owner (and possibly the group), e.g., 644 or similar.

Actual Behavior

The files are distributed with 666 permissions, making them world-readable and writable.

Suggested Fix

Review and adjust the file permissions for the distributed files in the gem's repository and packaging process to ensure they are set securely by default.

Relevant Information

• CWE-276: Incorrect Default Permissions - This issue is related to CWE-276, which involves the assignment of insecure default permissions to sensitive files.
• CVE-2024-27456: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-27456
• Gem Version Affected: 2.0.1
• File System: Observed on a UNIX-like file system.

Security Risk

This issue could lead to unauthorized information disclosure, data tampering, or other security vulnerabilities depending on the deployment environment and usage of the affected files.

[joaomarcos96]

It does not seem the permissions were changed at all.

Output from latest version rack-cors 2.0.1:

$ ls -la ./lib/rack/cors/
total 32
drwxr-xr-x 3 ubuntu ubuntu 4096 Feb 22 08:57 .
drwxr-xr-x 3 ubuntu ubuntu 4096 Feb 22 08:57 ..
-rw-r--r-- 1 ubuntu ubuntu 4602 Feb 22 08:57 resource.rb
drwxr-xr-x 2 ubuntu ubuntu 4096 Feb 22 08:57 resources
-rw-r--r-- 1 ubuntu ubuntu 1435 Feb 22 08:57 resources.rb
-rw-r--r-- 1 ubuntu ubuntu 1424 Feb 22 08:57 result.rb
-rw-r--r-- 1 ubuntu ubuntu   88 Feb 22 08:57 version.rb

[joaomarcos96]

git also shows that the mode of those files are 100644, they're not world-writable

$ git cat-file -p master^{tree}
040000 tree 1c2aae3e5fd64a39678bfc11a5574b36beab400c    .github
100644 blob 7efaeb188bf2c27a2f5c031012d630298def9e48    .gitignore
100644 blob 3debd8ad1756dac213e792b4c66101dc0a8fe498    .rubocop.yml
100644 blob 4eb37305acd238a000abbb8c14f1fb47817ad0d7    CHANGELOG.md
100644 blob e1fa8a180263679571540032f44782b458685004    Gemfile
100644 blob 1aff8f8170c433f9b50ab6353c6e47f36137bd7f    LICENSE.txt
100644 blob 238171add947e334f9247d8ad34ce81d51a1e03f    README.md
100644 blob c3ec29fde703f7971131f0f963aa80e58d409e35    Rakefile
040000 tree aafde09900d30e05d5841a35287796c080c18167    examples
040000 tree 84136f4508c434ce1d6dbd6673f91ff1f425e6bb    lib
100644 blob ada68f1e6a689a1c1295d624b57675e4069d161a    rack-cors.gemspec
040000 tree c16090b8c3d0c5df262b1544d93234c7daea640d    test

$ git cat-file -p 84136f4508c434ce1d6dbd6673f91ff1f425e6bb
040000 tree d4c6d326bb0482045d64e911f2ca7e291d2128ed    rack

$ git cat-file -p d4c6d326bb0482045d64e911f2ca7e291d2128ed
100644 blob 0c7f41afab1c5e9b3b15f9af50ad08e2389f7e51    cors.rb
040000 tree e5f4109e14a737b44ca6eeb7b76ccf90e544e1d6    cors

$ git cat-file -p e5f4109e14a737b44ca6eeb7b76ccf90e544e1d6
100644 blob 30fdc3b5123773eb17817570db50b13a074a9a8d    resource.rb
100644 blob 4d1d1a1748fb0c40fdf1cd0a4de9d2ea11fa38ab    resources.rb
040000 tree 0d18a8ac17dc65185a8c8510817c3219a0aa2b44    resources
100644 blob ae4c3708b857c9a8b1c91d7fa093ae3fdbc2e998    result.rb
100644 blob 1c45fa9c08808ab2880fbca91b5be8d954eae323    version.rb

[bdewater]

@joaomarcos96 it looks like you're checking the permissions of the git repo files? What you're describing matches what I get on my local git repo. But I do see the original issue as reported for the gem file downloaded from https://rubygems.org/gems/rack-cors/versions/2.0.1 (after decompressing the data.tar.gz inside). The wrong permissions were probably introduced during the gem build process.

[joaomarcos96]

@bdewater maybe there's something I'm missing but after decompressing data.tar.gz from rack-cors-2.0.1.gem (downloaded from https://rubygems.org/gems/rack-cors/versions/2.0.1), the output for file permissions remains the same:

$ ls -la ./lib/rack/cors/
total 20
drwxr-xr-x 1 ubuntu ubuntu  102 Feb 27 12:24 ./
drwxr-xr-x 1 ubuntu ubuntu   22 Feb 27 12:24 ../
-rw-r--r-- 1 ubuntu ubuntu 4602 Mar 17  2023 resource.rb
drwxr-xr-x 1 ubuntu ubuntu   60 Feb 27 12:24 resources/
-rw-r--r-- 1 ubuntu ubuntu 1435 Mar 17  2023 resources.rb
-rw-r--r-- 1 ubuntu ubuntu 1424 Mar 17  2023 result.rb
-rw-r--r-- 1 ubuntu ubuntu   88 Mar 17  2023 version.rb

[joaomarcos96]

@bdewater doing the process manually with tar, I was getting the right permissions but using gem unpack I got the wrong permissions such as described in this issue. It was certainly during the gem build process as you mentioned. Thanks!

[jamiemccarthy]

Confirmed on my local installation that 2.0.1 has different permissions, just by editing Gemfile to read gem "rack-cors", "2.0.0" vs "2.0.1".

root@0c724cd1c07a:/app# vi Gemfile
root@0c724cd1c07a:/app# bundle update rack-cors
Fetching gem metadata from https://rubygems.org/.......
Resolving dependencies...
Fetching rack-cors 2.0.1 (was 1.1.1)
Installing rack-cors 2.0.1 (was 1.1.1)
Bundle updated!
1 installed gem you directly depend on is looking for funding.
  Run `bundle fund` for details
root@0c724cd1c07a:/app# ls -l /usr/local/bundle/ruby/2.7.0/gems/rack-cors-2.0.1/lib/rack/cors
total 24
-rw-rw-rw- 1 root root 4602 Feb 27 20:37 resource.rb
drwxr-xr-x 2 root root 4096 Feb 27 20:37 resources
-rw-rw-rw- 1 root root 1435 Feb 27 20:37 resources.rb
-rw-rw-rw- 1 root root 1424 Feb 27 20:37 result.rb
-rw-rw-rw- 1 root root   88 Feb 27 20:37 version.rb
root@0c724cd1c07a:/app# bundle update rack-cors
Fetching gem metadata from https://rubygems.org/.......
Resolving dependencies...
Fetching rack-cors 2.0.0 (was 2.0.1)
Installing rack-cors 2.0.0 (was 2.0.1)
Note: rack-cors version regressed from 2.0.1 to 2.0.0
Bundle updated!
1 installed gem you directly depend on is looking for funding.
  Run `bundle fund` for details
root@0c724cd1c07a:/app# ls -l /usr/local/bundle/ruby/2.7.0/gems/rack-cors-2.0.0/lib/rack/cors
total 24
-rw-rw-r-- 1 root root 4365 Feb 27 20:38 resource.rb
drwxr-xr-x 2 root root 4096 Feb 27 20:38 resources
-rw-rw-r-- 1 root root 1435 Feb 27 20:38 resources.rb
-rw-rw-r-- 1 root root 1424 Feb 27 20:38 result.rb
-rw-rw-r-- 1 root root   88 Feb 27 20:38 version.rb

[kirkath]

should i be getting this as vulnerability alert on bundle-audit when i am clearly not running 2.0.1 rack-cors version?

[larouxn]

should i be getting this as vulnerability alert on bundle-audit when i am clearly not running 2.0.1 rack-cors version?

Looks like codebases with rack-cors < 2.0.1 should no longer receive the alert as of the following fix.

• https://github.com/rubysec/ruby-advisory-db/pull/755

[canderson-activatecare]

Since this appears to be an issue with the rubygems package that is being distributed, you can attempt to install from the github tag in the meantime which keeps the read-only permissions for other users.

This will not alleviate your bundle audit alerts/blockers.

Out of curiosity, what can we expect here since this appears to be a packaging issue?

[renchap]

I would advise the gem maintainers to setup the new trusted publishing workflow to release this gem: https://guides.rubygems.org/trusted-publishing/

This will allow the gem to be built and published from Github Actions automatically when tagging a new version, using OpenID Connect, so the Github Action will automatically auth with Rubygems and there is no longer a need to store credentials to publish from Github.

Here is an how-to : https://guides.rubygems.org/trusted-publishing/adding-a-publisher/

[timon]

For us, downgrading to v2.0.0 made issue #259 reappear, so had to switch to github: reference in gemfile (plus explicit ignore for this CVE when calling bundle audit)

[cyu]

I've pushed 2.0.2 which should fix this.

[unRARed]

2.0.2 still throwing. Is it false positive / just need to ignore with bundle audit?

ruby-advisory-db:
  advisories:   877 advisories
  last updated: 2024-03-04 02:52:07 -0800
  commit:   b9044073701dd16f4cb6153d2668494b09ff288d
Name: rack-cors
Version: 2.0.2
CVE: CVE-2024-27456
GHSA: GHSA-785g-282q-pwvx
Criticality: Unknown
URL: https://github.com/advisories/GHSA-785g-282q-pwvx
Title: Rack CORS Middleware has Insecure File Permissions
Solution: remove or disable this gem until a patch is available!
Vulnerabilities found!

[aprescott]

Looks like we're just waiting on https://github.com/rubysec/ruby-advisory-db/pull/760 to add metadata about the fixed versions.

[cyu]

Thanks for all the support no this, and apologies for taking so long to turn this around.