summaryrefslogtreecommitdiffstats
path: root/src/auth
diff options
context:
space:
mode:
authorIlya Dryomov <idryomov@gmail.com>2020-10-16 12:57:50 +0200
committerIlya Dryomov <idryomov@gmail.com>2020-10-17 20:54:18 +0200
commit4a82c72e3bdddcb625933e83af8b50a444b961f1 (patch)
treed3e1a8812bc04d5b4dadcbe2663f59a4a8380f85 /src/auth
parentmsg/async/ProtocolV1: resurrect "implement cephx_*require_version options" (diff)
downloadceph-4a82c72e3bdddcb625933e83af8b50a444b961f1.tar.xz
ceph-4a82c72e3bdddcb625933e83af8b50a444b961f1.zip
mon/MonClient: bring back CEPHX_V2 authorizer challenges
Commit c58c5754dfd2 ("msg/async/ProtocolV1: use AuthServer and AuthClient") introduced a backwards compatibility issue into msgr1. To fix it, commit 321548010578 ("mon/MonClient: skip CEPHX_V2 challenge if client doesn't support it") set out to skip authorizer challenges for peers that don't support CEPHX_V2. However, it made it so that authorizer challenges are skipped for all peers in both msgr1 and msgr2 cases, effectively disabling the protection against replay attacks that was put in place in commit f80b848d3f83 ("auth/cephx: add authorizer challenge", CVE-2018-1128). This is because con->get_features() always returns 0 at that point. In msgr1 case, the peer shares its features along with the authorizer, but while they are available in connect_msg.features they aren't assigned to con until ProtocolV1::open(). In msgr2 case, the peer doesn't share its features until much later (in CLIENT_IDENT frame, i.e. after the authentication phase). The result is that !CEPHX_V2 branch is taken in all cases and replay attack protection is lost. Only clusters with cephx_service_require_version set to 2 on the service daemons would not be silently downgraded. But, since the default is 1 and there are no reports of looping on BADAUTHORIZER faults, I'm pretty sure that no one has ever done that. Note that cephx_require_version set to 2 would have no effect even though it is supposed to be stronger than cephx_service_require_version because MonClient::handle_auth_request() didn't check it. To fix: - for msgr1, check connect_msg.features (as was done before commit c58c5754dfd2) and challenge if CEPHX_V2 is supported. Together with two preceding patches that resurrect proper cephx_* option handling in msgr1, this covers both "I want old clients to work" and "I wish to require better authentication" use cases. - for msgr2, don't check anything and always challenge. CEPHX_V2 predates msgr2, anyone speaking msgr2 must support it. Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Diffstat (limited to 'src/auth')
-rw-r--r--src/auth/Auth.h3
1 files changed, 3 insertions, 0 deletions
diff --git a/src/auth/Auth.h b/src/auth/Auth.h
index 642164985e4..845f56c9bd6 100644
--- a/src/auth/Auth.h
+++ b/src/auth/Auth.h
@@ -192,6 +192,9 @@ struct AuthConnectionMeta {
std::unique_ptr<AuthAuthorizer> authorizer;
std::unique_ptr<AuthAuthorizerChallenge> authorizer_challenge;
+
+ ///< set if msgr1 peer doesn't support CEPHX_V2
+ bool skip_authorizer_challenge = false;
};
/*