ha_vrrp_auth_type defaults to PASS which is insecure

[Adam Spiers]

With l3_ha enabled, ha_vrrp_auth_type defaults to PASS authentication:

https://github.com/openstack/neutron/blob/b90ec94dc3f83f63bdb505ace1e4c272435c494b/neutron/conf/agent/l3/ha.py#L28

which according to http://louwrentius.com/configuring-attacking-and-securing-vrrp-on-linux.html is totally insecure because the VRRP password is transmitted in the clear.

I'm not sure if this is currently a serious issue, since if the VRRP network is untrusted, maybe there are already bigger problems. But I thought it was worth reporting, at least.

[Jeremy Stanley (fungi)]

Looks like this was introduced in https://review.openstack.org/70700 back in 2014.4 so affects all currently supported branches.

[Jeremy Stanley (fungi)]

Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions.

[Tristan Cacqueray (tristan-cacqueray)]

It seems like the l3-high-availability spec define a dedicated ha network per tenant so that the keepalived traffic isn't visible from instance network. If so, then the authentication shouldn't really matter.

[Adam Spiers (adam.spiers)]

@Tristan Sure, it's not visible from the instance network, but it still requires you to trust the physical network on which the VRRP traffic resides. As I said in the original report, if the VRRP network is untrusted, there are probably already bigger problems to worry about, but presumably that does not make this problem go away; it just makes it less of a priority at the moment.

[Kevin Benton (kevinbenton)]

I don't think this is a security vulnerability. The tenant's HA network is not visible to anyone except for the operator so the risk here is that someone with access to the datacenter network itself could possibly hijack an L3 HA instance. But if they have that level of access they could do all sorts of other things (e.g. interfere with regular tenant network traffic directly rather than trying to interfere with L3HA leader election).

When the feature was originally introduced we probably should have just stuck with no authentication at all. I don't think having operators configure this provides much value since there is no clear threat that it mitigates.

If Neutron networks become accessible to other tenants, then that would be a big vulnerability in itself.

[Adam Spiers (adam.spiers)]

Thanks Kevin for confirming what I wrote in the original report and in comment #4, i.e. that if the VRRP network is untrusted, there are already bigger problems to worry about.

The fact that the option offers the *illusion* of security, without giving any extra security, is IMHO very mildly damaging to the operator (and increases maintenance overheads by a tiny amount too), so it might be worth considering dropping the option for PASS authentication.

[Jeremy Stanley (fungi)]

Thanks for digging into this. Looks like we can treat it as a public report of a potential security hardening opportunity (there are at least some in the community who would eventually like to see every service able to operate over untrusted backend/admin networks, but it should certainly not be an expectation as things stand today).

[Ihar Hrachyshka (ihar-hrachyshka)]

If the config option is worthless, it's a mild usability issue, and we should drop it. Marking with the corresponding tag.