Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

🚨 [security] [js] Update vite 2.9.13 → 2.9.18 (patch) #1165

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

depfu[bot]
Copy link
Contributor

@depfu depfu bot commented Apr 3, 2024


🚨 Your current dependencies have known security vulnerabilities 🚨

This dependency update fixes known security vulnerabilities. Please see the details below and assess their impact carefully. We recommend to merge and deploy this as soon as possible!


Here is everything you need to know about this upgrade. Please take a good look at what changed and the test results before merging this pull request.

What changed?

✳️ vite (2.9.13 → 2.9.18) · Repo · Changelog

Security Advisories 🚨

🚨 Vite's `server.fs.deny` did not deny requests for patterns with directories.

Summary

Vite dev server option server.fs.deny did not deny requests for patterns with directories. An example of such a pattern is /foo/**/*.

Impact

Only apps setting a custom server.fs.deny that includes a pattern with directories, and explicitly exposing the Vite dev server to the network (using --host or server.host config option) are affected.

Patches

Fixed in [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]

Details

server.fs.deny uses picomatch with the config of { matchBase: true }. matchBase only matches the basename of the file, not the path due to a bug (micromatch/picomatch#89). The vite config docs read like you should be able to set fs.deny to glob with picomatch. Vite also does not set { dot: true } and that causes dotfiles not to be denied unless they are explicitly defined.

Reproduction

Set fs.deny to ['**/.git/**'] and then curl for /.git/config.

  • with matchBase: true, you can get any file under .git/ (config, HEAD, etc).
  • with matchBase: false, you cannot get any file under .git/ (config, HEAD, etc).

🚨 Vite dev server option `server.fs.deny` can be bypassed when hosted on case-insensitive filesystem

Summary

Vite dev server option server.fs.deny can be bypassed on case-insensitive file systems using case-augmented versions of filenames. Notably this affects servers hosted on Windows.

This bypass is similar to https://nvd.nist.gov/vuln/detail/CVE-2023-34092 -- with surface area reduced to hosts having case-insensitive filesystems.

Patches

Fixed in [email protected], [email protected], [email protected], [email protected]

Details

Since picomatch defaults to case-sensitive glob matching, but the file server doesn't discriminate; a blacklist bypass is possible.

See picomatch usage, where nocase is defaulted to false: https://github.com/vitejs/vite/blob/v5.1.0-beta.1/packages/vite/src/node/server/index.ts#L632

By requesting raw filesystem paths using augmented casing, the matcher derived from config.server.fs.deny fails to block access to sensitive files.

PoC

Setup

  1. Created vanilla Vite project using npm create vite@latest on a Standard Azure hosted Windows 10 instance.
  2. Created dummy secret files, e.g. custom.secret and production.pem
  3. Populated vite.config.js with
export default { server: { fs: { deny: ['.env', '.env.*', '*.{crt,pem}', 'custom.secret'] } } }

Reproduction

  1. curl -s http://20.12.242.81:5173/@fs//
    • Descriptive error page reveals absolute filesystem path to project root
  2. curl -s http://20.12.242.81:5173/@fs/C:/Users/darbonzo/Desktop/vite-project/vite.config.js
    • Discoverable configuration file reveals locations of secrets
  3. curl -s http://20.12.242.81:5173/@fs/C:/Users/darbonzo/Desktop/vite-project/custom.sEcReT
    • Secrets are directly accessible using case-augmented version of filename

Proof
Screenshot 2024-01-19 022736

Impact

Who

  • Users with exposed dev servers on environments with case-insensitive filesystems

What

  • Files protected by server.fs.deny are both discoverable, and accessible

🚨 Vite Server Options (server.fs.deny) can be bypassed using double forward-slash (//)

Summary

Vite Server Options (server.fs.deny) can be bypassed using double forward-slash (//) allows any unauthenticated user to read file from the Vite root-path of the application including the default fs.deny settings (['.env', '.env.*', '*.{crt,pem}'])

Impact

Only users explicitly exposing the Vite dev server to the network (using --host or server.host config option) are affected, and only files in the immediate Vite project root folder could be exposed.

Patches

Fixed in [email protected], [email protected], [email protected], [email protected]
And in the latest minors of the previous two majors: [email protected], [email protected]

Details

Vite serve the application with under the root-path of the project while running on the dev mode. By default, vite using server options fs.deny to protected the sensitive information of the file. But, with simply double forward-slash, we can bypass this fs restriction.

PoC

  1. Create a new latest project of vite using any package manager. (here I'm using react and vue templates for tested and pnpm)
  2. Serve the application on dev mode using pnpm run dev.
  3. Directly access the file from url using double forward-slash (//) (e.g: //.env, //.env.local)
  4. Server Options fs.deny restrict successfully bypassed.

Proof Images:
proof-1
proof-2

Release Notes

2.9.18

Please refer to CHANGELOG.md for details.

2.9.17

Please refer to CHANGELOG.md for details.

2.9.16

Please refer to CHANGELOG.md for details.

2.9.15

Please refer to CHANGELOG.md for details.

2.9.14

Please refer to CHANGELOG.md for details.

Does any of this look wrong? Please let us know.


Depfu Status

Depfu will automatically keep this PR conflict-free, as long as you don't add any commits to this branch yourself. You can also trigger a rebase manually by commenting with @depfu rebase.

All Depfu comment commands
@​depfu rebase
Rebases against your default branch and redoes this update
@​depfu recreate
Recreates this PR, overwriting any edits that you've made to it
@​depfu merge
Merges this PR once your tests are passing and conflicts are resolved
@​depfu cancel merge
Cancels automatic merging of this PR
@​depfu close
Closes this PR and deletes the branch
@​depfu reopen
Restores the branch and reopens this PR (if it's closed)
@​depfu pause
Ignores all future updates for this dependency and closes this PR
@​depfu pause [minor|major]
Ignores all future minor/major updates for this dependency and closes this PR
@​depfu resume
Future versions of this dependency will create PRs again (leaves this PR as is)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant