-
Notifications
You must be signed in to change notification settings - Fork 12
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
Server executes arbitrary code from remote machines #14
Comments
Unfortunately UNIX socket was not available when I implemented this feature it's just introduced in Erlang 19. (and not everybody has Erlang 19 yet) I guess the best approach for now would be to disable |
I have just noticed that
|
As @ivan pointed out, listening on localhost wouldn't address all the problems, but it is better than listening on all interfaces like is happening now. The machine I'm using now, for example, is single user only (me). If alchemist server used gen_tcp listen options to limit to localhost, I wouldn't suffer from any of the attacks he pointed out, other than DNS rebinding. However, using the IP address 127.0.0.1 instead of localhost to gen_tcp listen options would prevent DNS rebinding as well. |
The DNS rebinding attack happens in the browser: e.g. domain.com is first 1.2.3.4 and is then swapped to 127.0.0.1, hitting your local server. |
Oh right, good point. Still, I think it'd be worthwhile to change the gen_tcp options to only listen on localhost, as this would prevent the most obvious remote attacks. |
Folks, this is really bad. Listening only on localhost is not enough! Here's a proof of concept that gets code execution from any website via a javascript XHR request to localhost. That means even switching to localhost only isn't the solution. This is incredibly dangerous and we need to fix it ASAP. I think the best solution is to stop running a TCP listener at all and listen on a unix socket instead. @slashmili I understand your concern about this being OTP 19 only, but I think you should be comfortable making OTP 19 a requirement in order to prevent code execution from any webpage on the internet. The code for my exploit is here. The trick is that alchemist server will ignore commands it doesn't understand, so we can send it an HTTP request with code to be evaluated in the body. Since we control the output, we can just format it as an HTTP response with the right CORS header to let us access the response in an XHR. |
This will at least make exploitation via XHR requests harder / impossible. This should be the behavior anyway, but is by no means a complete fix for tonini#14.
This will at least make exploitation via XHR requests harder / impossible. This should be the behavior anyway, but is by no means a complete fix for tonini#14.
try to reduce the security risk as it is pointed out tonini#14
try to reduce the security risk as it is pointed out #14
@mveytsman / @ivan / @drichardson can you check the latest commits and let me know what do you think? |
My only suggestion is to not use system time for the filename (bbd1d20#commitcomment-23265073). Otherwise I think this is the correct solution. |
LGTM |
This issue was resolved in #16 alchemist.vim was updated immediately after the fix was ready Just for the record |
alchemist-server starts a server that executes arbitrary code from any host that can reach you on the network, without any kind of authentication.
Take note of the port, because the exploit below doesn't brute-force the port (though this could easily be done by an attacker).
This also works from a remote machine because alchemist-server listens on all interfaces, not just localhost.
Listening on localhost by default would be a good idea, but is insufficient, because it still leaves the user open to attacks from other (less-trusted) users on the machine, and possibly from the user's web browser via a DNS rebinding attack.
Requiring a secret cookie before accepting any requests would be a good idea(beware, though, the secret needs a constant-time comparison). Even better would be to use a UNIX socket.A secret cookie at the start of the connection is not a bulletproof fix because TCP connections can be hijacked in some cases. ycmd had the same problem with code execution and now HMACs every request, which seems like a better idea (if using a UNIX socket is impossible).
The text was updated successfully, but these errors were encountered: