You can hijack Google Cloud VMs using DHCP floods, says this guy, once the stars are aligned and...

Google Compute Engine virtual machines can be hijacked and made to hand over root shell access via a cunning DHCP attack, according to security researcher Imre Rad. Though the weakness remains unpatched, there are some mitigating factors that diminish the potential risk. Overall, it's a pretty neat hack if a tad impractical: …

[Anonymous Coward]

Setting authentication information over unauthenticated channels?!

Who thought it would be a good idea to configure credentials over an unauthenticated connection on a shared network?

Why don't they just pass them through the hypervisor instead? Simply communicating over an emulated serial connection or an additional network containing just the VM and the hypervisor/metadata server?

Or they could simply change the necessary files on the template disk before booting it.

So many ways of doing this securely but instead they chose an unencrypted, unauthenticated communications channel, giving everyone on the same subnet root access to all other machines...

[SImon Hobson]

"Oh look, new version of ancient and well known weakness 'invented'"

That's a summary of the article. It was known decades ago that things could be subverted by the simple act of running a rogue DHCP server on a network. There are ways of mitigating that risk - one being to filter DHCP packets at the switch level (why aren't Google doing this ?) so that the rogue server can't get packets to clients; another is to simply monitor the network and manually locate and "terminate with malice" any rogue server; and another is to use secured messages (but that requires pre-configuration of the client which partially defeats the object of DHCP). It's also been known for decades that you can substitute a DHCP packet flood for running an actual service.

So yes, it's a known and solved problem - the only "news" is that in the 21st century it's a problem on a service run by an outfit that you'd think was big enough to employ grown ups to run the networks. The fact that there's weak randomisation involved is pretty well irrelevant - that's really only a mild protection for "idiots didn't do any of the above well known network level defences" and hence allow DHCP "server" packets to come from a device that isn't an authorised DHCP server.

[Claptrap314]

It seems to me

That the IP address could be mapped physically--server #x in rack #y in skiff #z in datacenter #w has an ip address computed. What am I missing?

[matjaggard]

Re: It seems to me

I think you're only missing the difficulty of doing that at the scale that Google works at - it is completely nuts. Still, not impossible especially with ipv6

[Claptrap314]

Re: It seems to me

Actually, I worked at Google 2015-6. And they were well on the way to ipv6 internally when I left.

[SImon Hobson]

Re: It seems to me

You're missing how the server knows what position it is in. It can be done using ... ooh, some form of dynamic provisioning protocol like ... ooh, DHCP. But then you're back to the original problem of protecting systems from rogue DHCP.

But once you get to the size of network where management is "a thing", then it's not too hard to block & detect rogue DHCP packets - it's a common feature on switches once you get out of the mud at the bottom of the feature pond.