Windows Autostart: Service or Start-On-Login. Comments please!

Going to http://localhost:8080/rest/config in my browser gives me the API key…

1 Like

Actually, now I’m getting a bit scared. If I merely trick you into visiting my webpage, some Javascript from my page running in a browser can get the config from localhost:8080, get the API key, modify the config to add the folder containing your NT SAM database (or where ever the Windows passwords are kept these days) and share it with me, post the config back, and reset your Syncthing.

Exactly. Unless you’ve configured a GUI password (which is the caveat I’ve always stated), anything that can open a connection on localhost:8080 can do whatever the hell it likes to Syncthing.

And of course you can add a share this way. How do you think the GUI works? Just edit the config, and post it back.


The same origin policy should prevent this attack, I think?


You have a very good point in that issue, see my comment.

I agree with @calmh - there’s no vulnerability inherent in the REST interface. The vulnerability is that you’ve got a service running as local admin which is not password-protected.

I think there’s a case in point here. It took me 2 threads and 2 other people chipping in to convince you that there’s a security risk here. You were very receptive and patient (and I’m grateful for that): if you weren’t, I’d have never managed to make my point.

Now, try carrying out the same knowledge transfer to every newbie who wants to install Syncthing. Are you going to be able to explain all of the risks, implications, and security considerations to someone who just wants to install the damn thing? Particularly, as you don’t have two-way dialogue or a way of holding their attention. No, you’re not.

Service installation is possible, fine, and works well, provided that the person doing it understands the implications of what they’re doing (and the Windows security model). I don’t trust the average user to do this. Hell, I don’t trust 99% of people to handle Windows permissions correctly. I certainly don’t trust myself here.

It is for this reason that I’m so strongly against making installation-as-a-service something that’s easy to do for the casual user. By all means provide an installer, but hide it behind a page of explanation, and don’t include it in the safer, user-level installer.

1 Like

I guess we could have a Install as a service as some hidden advanced option in the installer with the explanation of threat, and an option to setup UI creds there and then (perhaps even mandatory). Also, how does it work, if SyncTrayzor implements service controls, does the user still get a tray icon even though the service runs under a different account?

It would also be cool to have an unattended installer, both for a user and for a service (again, with creds provided or something), so that it could be baked in into the standard OS image.

1 Like

My preferred approach would be:

Something about running a file synchronization program as local admin makes me very nervous indeed, even if there is a password on it. It makes Syncthing a very tasty program to find an exploit in, and you don’t want to find yourself between someone with a lot of skill and time on their hands, and their money.

A decent prompt saying “which user do you want to run the Syncthing service as?”, and not making it obvious that Local Admin is an option (although allowing it if the person really knows what they want) might be sensible. That way people are prompted towards installing the Syncthing services as either an existing user, towards creating a new dedicated user account.

If you wanted to integrate Syncthing into a tray utility, that’s a little bit of work. You’d need to write a wrapper for Syncthing (replacing NSSM) which would be responsible for starting / restarting / stopping it, managing the API key and host address, and for capturing its STDOUT. The tray utility would then communicate with the wrapper instead of managing the process directly.

Another thought: if Syncthing is running system-wide, do you want to give individual users access to it? That depends on whether you want users to muck about with the config, just be able to see the results of the synchronization, or not care at all (as in the case of the guy who was using Syncthing to transfer database backups). In the latter two cases, a tray utility would be useless.

1 Like

Syncthing is inherently a single user thing at the moment. Running it as a privileged user is not tested nor recommended. Running it as a specific service user on OS:es where that makes sense sounds fine, but that won’t make it multiuser.

It sounds as if a Windows service would be better off running as the intended end user account, and/or possibly the installer should enforce setting up authentication as part of the install process?

1 Like

I like the idea of asking the user which user to run the service as during installation.

I’m not a security expert, but I might be paranoid. Suggestions/ideas:

  • If Syncthing detects it is running as Local System, or an account in an admin group,
    • Show a big red warning at the top if there is no WebGUI password set
    • Show a warning if the password strength is weak
    • Lock out the webGUI login for a default of 2 (?) minutes if the user has 5 incorrect attempts within 5 (?) minutes.

Service if it’s a pure implementation of the entire protocol spec , with the intention of running on Windows Server 2008 or similar type instance. Like a build for an Amazon EC2 Windows instance should run as LocalService/LocalSystem , so it would continue to start across reboots (without the need for human intervention).

I’d think it should be start-on-login for ‘end user’ type code (probably a majority of users), as their machines will usually only be on when they are logged in. In other words, few ‘end users’ will leave their laptop open at the Windows login screen, yet still expect Syncthing to be running in the background.

Most end-users I think would expect that for Syncthing to work, they’d need to be (A) powered on , and (B) logged in for the file sharing to work.

+1 for the option to setup a new user as part of the install process and maybe this could also make the Default share also point into their %HomePath%?

I really don’t like the idea of having to install Syncthing for each user on each machine and setup several ID’s for each one as I’m unsure of how Syncthing will react when I just copy the same certificates over and then that user logs in on 2 machines at the same time…

That’s a tough call Rewt0r… You could easily formulate two arguments.

(1) Syncthing ID should be associated with a machine, and not a user. This would be in line with the fact that the .pem files are not password protected / encrypted, etc. So the ID is unique to a particular IP. That means only one Syncthing instance can run per machine, and it runs for ALL users on that machine. Each user could access sharing for the other users on the same local machine.

(2) Syncthing ID should be associated with a ‘machine AND user’ … This makes more sense for non-personal machines… For example, a work computer, whether there might be a day shift and a night shift, with two different people. In this case, you’d want Syncthing to be specific to your files (the day shift for example), and not accessible from other users.

I think #1 (install for all users on a ‘machine’ level) makes more sense overall. It also means minimal / zero changes to the code base, and thus less work involved. Plus – Most people are not going to be running a file sharing app like Syncthing on a shared computer. But I’m sure there will be a sub-group of users that prefer option #2.

I think start on login is the best option for desktop use, but the service option for servers is needed. Choice of account for the service is good as you might strike folder permission issues if the folders have also been shared in Windows.

1 Like

I like the sound of this.

If we do enforce setting up authantication as part of the install process, then that means that any tray utility won’t be able to talk to Syncthing without user input, every time it’s started. If the tray utility (running as the user) has a means of determining Syncthing’s credentials then that’s a security hole - we’re defeated the point of enforcing authentication.

This isn’t an argument against encforcing authentication - I’m in favour of this. It’s questioning the use of a tray icon in the service scenario.

So you could setup syncthing (via syncthing -generate) and then take note of the API key during the installation process. You’d still need elevated priviledges to install the service, hence at that point you could peak into the config.xml. After that, a simple user cannot peek into the config as it would not be stored under his account, and probably he wouldn’t have privileges to read it.

Doesn’t Windows have some smart API for storing secrets that are only supposed to be available to a certain program? Things like database connection strings and such come to mind. If so, the traything could use that to store the API key perhaps?

(I may be talking out of my ass since it was years and years since I coded for Windows and I did no such thing at the time.)

The problem being where do you store the API key, where you can read it but a user with your permissions can’t.

I’m not aware of any, and another team here at $dayjob didn’t find anything in their research. I’m more than happy to be proved wrong here though! It would make my life easier…

Exposing my Windows noobness here, but what’s the problem with simply running syncthing as the account that intends to use it? It can still run as a service, but as the user who installed it, no?