3 ms·
There's a really simple (albeit hacky) workaround which can be deployed fairly quickly. In /etc/dhcp/dhclient-exit-hooks.d/google_set_hostname replace this lin
by tytso 5y ago
There's a really simple (albeit hacky) workaround which can be deployed fairly quickly. In /etc/dhcp/dhclient-exit-hooks.d/google_set_hostname replace this line:
if [ -n "$new_host_name" ] && [ -n "$new_ip_address" ]; then
with this:
if [ -n "$new_host_name" -a ! "$new_host_name" =~ metadata.google.internal ] && [ -n "$new_ip_address" ]; then
(Yes, =~ is a bashism, but google_set_hostname is a bash script.)
This prevents /etc/hosts from getting poisoned with a bogus entry for the metadata server. Of course, dhcpd should also be fixed to use a better random number generator, and the firewall should be default stop dhcp packets from any IP address other than Google's DHCP server. Belt and suspenders, after all. But fixing the dhclient exit hooks is a simple text edit.
- floatingatoll 5y ago!= would be a simple non-regex replacement, right? Or are there parts to the exploit hostname that aren’t a literal match?
- tytso 5y agoThe reason why I used the regex match is because the attacker might try to add one or spaces as a prefix and/or suffix, e.g " metadata.google.internal " which wouldn't match "metadata.google.internal" but the spaces in /etc/hosts name would be ignored and still be effective in poisoning the /etc/hosts lookup for metadata.google.internal.