5 ms·

I didn't know Syncthing and after installing it on a couple of machines I'm very impressed! However, I'm surprised too see that by default the whole interface

I didn't know Syncthing and after installing it on a couple of machines I'm very impressed! However, I'm surprised too see that by default the whole interface is available on 127.0.0.1:8384. It is possible to set a password but it's a bit hidden in the settings and the documentation does not insist on it. This makes me wonder, how bad is it for a malicious program running locally to have access to this API?

zamadatix 8y ago
It's not great but not particularly horrible either. It takes the interesting combination of "this machine is locked down to the point it does not allow outbound connections by default" and "this machine has a default syncthing install with no password set and an actively running piece of malware that can't create an outbound connection otherwise". Pretty rare someone manages every outbound connection but doesn't configure a password on the tool handling syncing all of their data across the network. Still, would be better if it prompted for a password the first time a user visited the page to set up the client.
tagrun 8y ago
So? Local programs also have access to the filesystem, which includes the synced data, config files and procfs. What exactly is your threat model?
- dddddaviddddd 8y ago
  On a multiuser system it could be an issue. Other users with access to make HTTP requests could add a malicious endpoint. e.g. on a shared server of some sort. I could see this in academia or some business settings. Threat model would be an attacker with a foothold on one machine gaining access to the documents of another user.
  - tagrun 8y ago
    Could be, theoretically, but this would probably be inconveniencing all syncthing users for a negligible fraction of the userbase. On a shared computer where you perceive your peers as a threat, adding a password to syncthing web UI is probably a minor entry in a long list of things you have to do to secure your processes and data, and to ensure the kernel and programs you're running are trustable (in practice, you can't verify that with 100% confidence; they can be backdoored, out-of-date with known security flaws, etc etc). Ensuring security in such a malicious (where your co-workers/peers are apparently a nasty bunch) shared environment is so hard that to begin with that I personally wouldn't put any sensitive data there at all.
- puetzk 8y ago
  It defeats user-privilege separate on localhost - I (or an unprivileged daemon) can't get at parts of the filesystem belonging to their user instead of mine, but I can get at TCP ports on localhost that belong to other user's syncthing daemons, and reconfigure their syncthing to send all their data to me.
- nicolaslem 8y ago
  You assume a machine with a single all powerful user. These days computers don't really work this way, for our own good. A huge amount of effort is put into keeping programs as isolated as possible (unix permissions, chroots, cgroups...). Most systemd units include isolation features enabled by default. Having an API that can reconfigure syncing being available without authentication for anything running on the machine feels backwards to me. More so for a project that focuses on security. If anyone from the project reads this, may I recommend either encouraging users to set a password or mentioning the implications on the page about Security Principles[0]? [0] https://docs.syncthing.net/users/security.html https://docs.syncthing.net/users/security.html
  - tagrun 8y ago
    The real reason behind isolated systemd services is to confine the damage if a world-accessible daemon gets breached. If your threat model is you can't trust the programs running on your computer, then maybe you should switch to a different OS, for example Debian, and stick to the package manager.
puetzk 8y ago
It's also possible to move the listener to a permission-protected unix socket https://docs.syncthing.net/users/config.html?highlight=unix%20socket https://docs.syncthing.net/users/config.html?highlight=unix%... Pity that I don't know of any browser that readily supports HTTP over a unix socket (nginx can proxy_pass it, but then you're back to a TCP listener). But a multi-user install could reasonably lock things down in that way, though the defaults definitely favor "works out of the box on a single-user machine".

zamadatix 8y ago

It's not great but not particularly horrible either. It takes the interesting combination of "this machine is locked down to the point it does not allow outbound connections by default" and "this machine has a default syncthing install with no password set and an actively running piece of malware that can't create an outbound connection otherwise". Pretty rare someone manages every outbound connection but doesn't configure a password on the tool handling syncing all of their data across the network. Still, would be better if it prompted for a password the first time a user visited the page to set up the client.

tagrun 8y ago

So? Local programs also have access to the filesystem, which includes the synced data, config files and procfs. What exactly is your threat model?

dddddaviddddd 8y ago
On a multiuser system it could be an issue. Other users with access to make HTTP requests could add a malicious endpoint. e.g. on a shared server of some sort. I could see this in academia or some business settings. Threat model would be an attacker with a foothold on one machine gaining access to the documents of another user.
- tagrun 8y ago
  Could be, theoretically, but this would probably be inconveniencing all syncthing users for a negligible fraction of the userbase. On a shared computer where you perceive your peers as a threat, adding a password to syncthing web UI is probably a minor entry in a long list of things you have to do to secure your processes and data, and to ensure the kernel and programs you're running are trustable (in practice, you can't verify that with 100% confidence; they can be backdoored, out-of-date with known security flaws, etc etc). Ensuring security in such a malicious (where your co-workers/peers are apparently a nasty bunch) shared environment is so hard that to begin with that I personally wouldn't put any sensitive data there at all.
puetzk 8y ago
It defeats user-privilege separate on localhost - I (or an unprivileged daemon) can't get at parts of the filesystem belonging to their user instead of mine, but I can get at TCP ports on localhost that belong to other user's syncthing daemons, and reconfigure their syncthing to send all their data to me.
nicolaslem 8y ago
You assume a machine with a single all powerful user. These days computers don't really work this way, for our own good. A huge amount of effort is put into keeping programs as isolated as possible (unix permissions, chroots, cgroups...). Most systemd units include isolation features enabled by default. Having an API that can reconfigure syncing being available without authentication for anything running on the machine feels backwards to me. More so for a project that focuses on security. If anyone from the project reads this, may I recommend either encouraging users to set a password or mentioning the implications on the page about Security Principles[0]? [0] https://docs.syncthing.net/users/security.html https://docs.syncthing.net/users/security.html
- tagrun 8y ago
  The real reason behind isolated systemd services is to confine the damage if a world-accessible daemon gets breached. If your threat model is you can't trust the programs running on your computer, then maybe you should switch to a different OS, for example Debian, and stick to the package manager.

puetzk 8y ago

It's also possible to move the listener to a permission-protected unix socket https://docs.syncthing.net/users/config.html?highlight=unix%20socket https://docs.syncthing.net/users/config.html?highlight=unix%... Pity that I don't know of any browser that readily supports HTTP over a unix socket (nginx can proxy_pass it, but then you're back to a TCP listener). But a multi-user install could reasonably lock things down in that way, though the defaults definitely favor "works out of the box on a single-user machine".