While the vulnerability remains unpatched, there are a number of factors that mitigate its potential severity. Its operation is quite graceful, albeit impractical, and is of interest from a network security point of view.
The attack involves overloading the attacked virtual machine with DHCP traffic, as a result of which it starts using a metadata server controlled by attackers on the same network or on the other end of the Internet. A source of junk DHCP traffic can be a neighbouring system under the control of cybercriminals in the Google Cloud.
When, instead of the official Google server, the attacked virtual machine uses a malicious metadata server to configure its configuration, attackers can log in to it via SSH as a superuser. As Rad explained, Google relies on its metadata servers to distribute SSH keys. By forging a metadata server, an attacker can gain access to virtual machines via SSH.
In two of the three attack scenarios presented by the researcher, attackers must be on the same subnet with the attacked virtual machine in order to send DHCP traffic to it. One scenario requires a reboot of the virtual machine, and another requires DHCP lease cleanup. The third scenario allows attacks to be carried out remotely over the Internet, but this requires that the firewall protecting the virtual machine be fully open.
To protect against attacks, it is recommended that you do not access the metadata servers using the virtual hostname (metadata.google.internal), do not manage the virtual hostname via DHCP, protect the metadata server with TLS, and block UDP on ports 67/68.
Glad notified Google of the issue in September 2020, but the company hasn't fixed it. In this regard, after nine months, the researcher published the results of his research.