Repository navigation
Conversation
intent(security): symlinks are disabled by default and documented as being treated as if they do not exist, but a directory symlink requested with a trailing slash and a symlink used as an intermediate path component were both followed, exposing files outside the public directory decision(symlink-handling): inspect every path component with lstat instead of only the final one, so the documented "any symlink is a 404" behaviour holds for all requests rejected(symlink-handling): resolving with realpath and checking containment instead — that would start serving symlinks which resolve inside the public directory, contradicting the README constraint(lstat): a trailing slash makes lstat resolve the final symlink, so that component is checked here when the request path ends with a slash; otherwise the existing final-component check still covers it learned(fixtures): the added fixture is a directory symlink pointing outside test/fixtures so the escape path is exercised, rather than a symlink that stays inside the public directory
Author
|
This is a security-relevant fix rather than a plain bug fix: it closes a way to defeat the documented default in which symlinks are disabled and treated as if they do not exist, which could expose files outside the served directory. If you agree, would it be possible to handle this through a GitHub security advisory? I am happy to provide any additional detail (reproduction, affected versions) and to be credited as the reporter. |
Author
|
Sorry for my poor English... |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
serve-handlerdocuments that symlinks are disabled by default and are treated as if they do not exist (README,symlinks). The check only inspected the final path component, so two ordinary requests were still followed and could serve files outside thepublicdirectory:/link/) —lstatresolves the final symlink when the path ends with//link/file) —lstatleaves only the final component unresolvedThis defeats the documented default, which exists specifically to keep symlinks from escaping the served root.
Fix
hasSymlinkInPath()walks the path components withlstatand returns a 404 as soon as one of them is a symlink, which is what the documented default promises. The final component continues to be checked by the existing code path, except when the request has a trailing slash, where the new walk covers it.Tests
a directory symlink should not work by defaulta symlink used as an intermediate path component should not work by defaultdirectory symlinks still work when the option is enabled(no regression)Full suite:
73 passed.Notes
symlinks: trueis unchanged.symlinks: true, requesting a directory symlink without a trailing slash currently throws an uncaughtEISDIRfromcreateReadStreamand terminates the process, becauseisDirectoryis not re-evaluated afterrealpath. I can send a follow-up patch for that if it is useful.