4 ms·
Slightly, but not exactly. Any remote code execution could lead to "example.com/run_this.txt" being filled with "evil_hacker.sh". However if "run_this.txt" we
by ramses0 9y ago
Slightly, but not exactly. Any remote code execution could lead to "example.com/run_this.txt" being filled with "evil_hacker.sh". However if "run_this.txt" were somehow signed and verified prior to downloading (with signing keys kept off the distribution box) then it's much safer.
Practically, there are tons of instances where executing code downloaded from URL's is how software is updated, but again most of those instances are human-driven, not automated.
- joshribakoff 9y agoOur main issue is if someone tampers with content stored on the server, which gets copied to devices. For example someone replaces a JPG with the wrong JPG that is something offensive. If someone gains access to our server, its already game over. Being able to execute code on the devices is then moot because we were already hacked & potentially lost all credibility in the industry. To everyone saying not to execute code at URL, this is how oh my zsh, and many other open source projects are installed. And SSL should prevent any kind of MITM attacks. The point about keeping keys off the server is a good idea, but is not always possible when the server needs to dynamically send content down to the device. The server would need to access the private key in order to sign this content dynamically. For statically built executables this is a good idea though.