Security flaw in server

[defeo]

Hi,

Isn't this embarassing?

linux-remote-control/opt/lrc-server/lrc.js

Line 64 in 065c0b8

exec(command);

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

[Agneli]

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]

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]

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.