New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider referencing GCP metadata service by IP in Ignition/Afterburn #891
Comments
Looking a bit more into GCP related material, the explicit 169.254.169.254 address is already referenced in a few places:
Specifically, a comment in the Go library says |
We discussed this in the meeting today:
|
PRs in coreos/ignition#1247 and coreos/afterburn#595. |
Both PRs have merged upstream. Closing this out. |
Those changes landed in Ignition The fix for this went into stable stream release |
On GCP, both Ignition and Afterburn access the GCE metadata service via the hostname
metadata.google.internal
without any further authentication of the service, as instructed by official documentation.An attack that rebinds that hostname can inject arbitrary code (Ignition) or SSH keys (Afterburn). There have been multiple exploits that involve poisoning that hostname via forged DHCP replies and a vulnerable DHCP hook called
google_set_hostname
. We don't ship that script, but since DNS poisoning in this case leads to trivial instance takeover, we should perhaps consider mitigations.metadata.google.internal
resolves to 169.254.169.254. One option is to just hardcode that IP. It's not clear that Google has documented the address as stable, but it'd probably be hard to change it at this point. Other clouds use the same address.In the case of Ignition, another potential option is to query the metadata service before a globally routable address has been configured. However, that would require structural changes to Ignition, since merged configs are fetched in the same Ignition stage as the main config. It also wouldn't help Afterburn.
xref #885
The text was updated successfully, but these errors were encountered: