-
Notifications
You must be signed in to change notification settings - Fork 115
wolfsshd: expand AuthorizedKeysFile %u/%h/%% tokens per user #1064
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
Open
yosuke-wolfssl
wants to merge
1
commit into
wolfSSL:master
Choose a base branch
from
yosuke-wolfssl:fix/f_5827
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+262
−30
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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
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
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🟠 [High] Windows drive-relative AuthorizedKeysFile paths are treated as absolute
🚫 BLOCK
bugThe PR adds Windows absolute-path detection, but it treats any
<letter>:prefix as absolute. On Windows, paths likeC:keys\aliceorC:aliceare drive-relative, not fully qualified. BecauseResolveAuthKeysPath()skips the home-directory join whenIsAbsoluteAuthKeysPath()returns true (copying the path unchanged forSearchForPubKeyto open), anAuthorizedKeysFile C:keys\%upattern is opened relative to the daemon process's current directory on drive C instead of under the user's home directory. Data flow: config/public setter ->ExpandAuthKeysTokensexpands%u->IsAbsoluteAuthKeysPathreturns true solely becausepath[1] == ':'->ResolveAuthKeysPathcopies unchanged ->SearchForPubKeyopens it. Under a misconfigured Windows deployment usingX:relativesyntax, an attacker with write access to the relevant current-directory tree can influence which authorized_keys file is loaded. This is introduced by the new_WIN32branch and is not covered by the new Windows test vectors, which only checkC:\keys\%u. Severity views differ across modes: review rates this High (BLOCK), security rates the practical impact Low (requires Windows, a non-default/mistyped config, and write access to the current-directory tree); the stricter High is kept.Recommendation: Require a slash or backslash after the drive colon for fully qualified Windows paths (
path[1] == ':' && (path[2] == '\\' || path[2] == '/')), and add Windows test vectors forC:%uandC:keys\%uthat expect home-relative resolution (or rejection).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Confirmed and fixed