OpenRefine has endpoints with intentional remote code execution without authentication (like running Python or Clojure transformations). While the lack of authentication would not be an issue with normal desktop use when OpenRefine is bound to a loopback interface like 127.0.0.1, the current implementation still exposes users to Remote Code Execution via DNS rebinding attacks.
To Reproduce
I did not prepare a full Proof of Concept exploit, but the general steps would be:
- Run OpenRefine
- Visit rebindable.com, which loads a malicious script in the browser
- Attacker rebinds rebindable.com to 127.0.0.1
- Malicious script calls OpenRefine endpoints as if they were under rebindable.com
Current Results
The calls will succeed and an attacker can use them to run arbitrary code on the user's computer. This works because after the domain has been rebound, the script can now call OpenRefine endpoints as if they were same-origin.
Expected Behavior
The calls should be rejected.
Additional context
I have sent a pull request (#3212) to address this problem by validating the Host header. See implementation details in the thread associated with the PR. This issue was opened at the request of @tfmorris.
OpenRefine has endpoints with intentional remote code execution without authentication (like running Python or Clojure transformations). While the lack of authentication would not be an issue with normal desktop use when OpenRefine is bound to a loopback interface like 127.0.0.1, the current implementation still exposes users to Remote Code Execution via DNS rebinding attacks.
To Reproduce
I did not prepare a full Proof of Concept exploit, but the general steps would be:
Current Results
The calls will succeed and an attacker can use them to run arbitrary code on the user's computer. This works because after the domain has been rebound, the script can now call OpenRefine endpoints as if they were same-origin.
Expected Behavior
The calls should be rejected.
Additional context
I have sent a pull request (#3212) to address this problem by validating the Host header. See implementation details in the thread associated with the PR. This issue was opened at the request of @tfmorris.