Swift's container-sync uses a combination of a static key authentication, mutually agreed and set between the two containers ("X-Container-Sync-Key") and IP-based authantication for the whole cluster, as set in the "allowed_sync_hosts" configuration directive.
Unfortunately, the code that validates the IP-based authentication has this:
and (req.remote_addr in self.allowed_sync_hosts
or swift_utils.get_remote_client(req)
in self.allowed_sync_hosts)):
(from keystoneauth, but is the same in tempauth & swauth)
And, in turn, get_remote_client() is:
def get_remote_client(req):
# remote host for zeus
client = req.headers.get('x-cluster-client-ip')
if not client and 'x-forwarded-for' in req.headers:
# remote host for other lbs
client = req.headers['x-forwarded-for'].split(',')[0].strip()
if not client:
client = req.remote_addr
return client
In other words, it unconditionally trusts X-Cluster-Client-IP or X-Forwarded-For as sent by the remote end. This is on the path to the proxy servers, which are exposed and on the public side of the cluster.
This isn't very serious, since the attacker would have to know the key too; but it essentially renders the IP-based authentication part almost useless and the two-factor authentication breaks down to just one factor.
@John: could you (or someone elese in swift-core) attach a patch to fix that to this bug (no public fix at the moment please) ?
We still need to decide if we'll consider this a vulnerability that would force us to embargo the fix (not directly exploitable but definitely a false sense of security)
@Russell, Steve: opinion on whether this warrants an OSSA ?