ssh: use errors.As for PartialSuccessError unwrapping in auth loop#352
Open
XananasX7 wants to merge 1 commit into
Open
ssh: use errors.As for PartialSuccessError unwrapping in auth loop#352XananasX7 wants to merge 1 commit into
XananasX7 wants to merge 1 commit into
Conversation
The authentication loop in serverAuthenticate used a direct type assertion
to detect *PartialSuccessError:
if partialSuccess, ok := authErr.(*PartialSuccessError); ok {
This is inconsistent with how *BannerError is detected in the same loop,
which correctly uses errors.As to unwrap the error chain.
When an authentication callback returns a BannerError wrapping a
PartialSuccessError, two bugs appear:
1. In the isQuery (public-key probe) path, the wrapped PartialSuccessError
is not recognised, so the server never sends SSH_MSG_USERAUTH_PK_OK.
The client therefore never sends the actual signature, and the
PartialSuccess is never surfaced to the authentication loop at all.
2. In the main result path, the wrapped PartialSuccessError is similarly
missed, so authFailures is incremented instead of switching authConfig
to the Next callbacks and sending a partial-success reply.
Replace both direct type assertions with errors.As calls, consistent with
the existing BannerError handling, and add a regression test.
Change-Id: fix-banner-partial-success-unwrap
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
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
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.
Problem
The authentication loop in
serverAuthenticatedetected*PartialSuccessErrorusing a direct type assertion:This is inconsistent with how
*BannerErroris detected in the same loop, which already useserrors.Asto unwrap error chains. When an authentication callback returns aBannerErrorwrapping aPartialSuccessError— a natural combination when a server wants to display a banner and require a second authentication factor — two bugs occur:Bug 1 — public-key query path (isQuery=true):
The wrapped
PartialSuccessErroris not recognised, so the server never sendsSSH_MSG_USERAUTH_PK_OK. The client therefore never sends the actual signature, and the partial success is never surfaced to the outer auth loop at all.Bug 2 — main result path:
Even if the query phase were fixed, the main result check also uses a direct type assertion and misses the wrapped value, incrementing
authFailuresand sending an ordinary failure reply instead of a partial-success reply with the updated allowed-methods list.The net effect: a server callback that returns
&BannerError{Err: &PartialSuccessError{Next: ...}, Message: "..."}}will have the banner sent correctly but the multi-factor continuation silently dropped — the client receives an auth failure and thePartialSuccessError.Nextcallbacks are never used.Fix
Replace both direct type assertions with
errors.Ascalls, matching the pattern already used forBannerError:Test
Added
TestBannerWrappingPartialSuccesstoserver_multi_auth_test.go. It configures a server whosePublicKeyCallbackreturnsBannerError{Err: PartialSuccessError{Next: {PasswordCallback: ...}}}, then verifies that:The test fails on the unpatched code and passes with this change. All existing
ssh/...tests continue to pass.Note for reviewers
This is a purely behavioural fix with no security-boundary change — an attacker cannot exploit this to bypass authentication (they still receive a failure). The impact is that servers implementing MFA flows using
BannerError+PartialSuccessErrortogether would silently break until reported.