search

Agneli / linux-remote-control

Turn any device into a complete remote control for your GNU/Linux
www.linuxremotecontrol.com
GNU General Public License v3.0
71 stars 21 forks source link

Security flaw in server #49

Open defeo opened 10 years ago

defeo commented 10 years ago

Hi,

Isn't this embarassing?

https://github.com/Agneli/linux-remote-control/blob/065c0b83dd94bff20aaabcc8aca13c4553457f81/opt/lrc-server/lrc.js#L64

This allows arbitrary code execution on the server, to anyone on the same network. Not even a password protection.

Agneli commented 10 years ago

Hi @defeo, I agree with you. Realy arbitrary code can be executed in server by other computer in same network. Do you have a suggestion to improve it?

Thank you for your feedback!

defeo commented 10 years ago

Hi,

You could protect the API with a password. That wouldn't be very secure, as the password would be sent over HTTP and anyone could sniff it, but this will at least stop some trivial attacks.

If you could use HTTPS that would solve the problem, but the server key would be self generated, and the client app would not recognize it.

In my opinion, the only safe and reasonable option is to drop the "custom command" feature the way it is implemented right now. You could use configuration files on the server: the user would put somewhere a text file containing aliases for the commands he wants to use, e.g.:

restart='sudo reboot'
jingle='play jingle.wav'
...

and the client could call these commands with an URL like /custom/restart/, /custom/jingle/, etc.

That would not prevent arbitrary users from executing privileged commands, but it would at least prevent arbitrary code execution. Combined with passwords, this could be a decent protection, albeit not perfect.

Using bluetooth instead of HTTP would be a safer choice, e.g., the client implements a bluetooth mouse/keyboard protocol, while the server maps keys to commands. But I believe the FxOS bluetooth API is not ready yet.

minj commented 9 years ago

You should implement some kind of pairing mechanism using a shared secret on both the client and the server. Obviously the secret should be used cryptographically rather than sent in plain text.

E.g. 'consumer secret' in oAuth 1.0a.