You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Browsing the web will allow an attacker to execute arbitrary code on your machine if you are running better errors.
The attack is performed by having the user visit a page like randomid.dnsrebinder.com:3000 (likely embedded in an iframe) then the DNS entry from randomid.dnsrebinder.com is updated to point to 127.0.0.1. Then the page performs XHR requests which will now be sent to 127.0.0.1. The attacker can then interact with the debug functionality to run code.
The fix is to check the host header in the gem to check that it is a safe host like localhost that we know won't be running bad code or an ip address.
This was my proposed patch to the web_console gem if you need some ideas:
For devs who work on this, consider logging / raising an error loudly to the developer when a bad host header is detected, so they're aware of the attack and perhaps suggest actions they can take to make others aware of the problem or have the attacker site taken down.
One of the key features of Better Errors is the useful response to non-HTML requests including XHRs, so disabling Better Errors' responses to XHRs doesn't seem like a great idea (which is what web-console did).
It is important to note that using puma-dev is an easy way to mitigate the risk of a DNS-rebinding attack such as this. There are other reasons to use a "real" hostname instead of using a different port number. Ease of running multiple applications, or working with OAuth, for example. It also includes support for HTTPS.
Also, some (hopefully many) consumer routers do not allow external DNS servers to resolve to RFC-1918 (private) addresses, which stops this problem entirely.
Browsing the web will allow an attacker to execute arbitrary code on your machine if you are running better errors.
The attack is performed by having the user visit a page like randomid.dnsrebinder.com:3000 (likely embedded in an iframe) then the DNS entry from randomid.dnsrebinder.com is updated to point to 127.0.0.1. Then the page performs XHR requests which will now be sent to 127.0.0.1. The attacker can then interact with the debug functionality to run code.
The fix is to check the host header in the gem to check that it is a safe host like localhost that we know won't be running bad code or an ip address.
This was my proposed patch to the web_console gem if you need some ideas:
dns_rebinding.patch.txt
More information and a POC for the webconsole attack are available here:
http://benmmurphy.github.io/blog/2016/07/11/rails-webconsole-dns-rebinding/
The text was updated successfully, but these errors were encountered: