Disallow all unauthenticated web GUI access #3357
Comments
|
In general, I can see stuff like this falling into three categories:
In situation one, people are already pretty much agreeing to not mess with each other's stuff, and therefore it's not really relevant to this issue (except for mentioning it for completeness). This is likely the most common situation for traditional 'home computer' users. I would not personally consider situation three particularly relevant, because if a remote attacker can connect to arbitrary ports on your loopback interface, you've got bigger issues to deal with because they've either already hit you with an ACE exploit, or they've tricked you into letting them access your system, or they already have a trojan or other malicious software on your system. In any of those situations, they can almost certainly get your files more easily and less noticeably via other means. This leaves situation two, which can be primarily solved as suggested. There are a few things to keep in mind though:
|
|
Agreed on scenario 2. On scenario 3, there are a number of ways that an attacker can obtain network traffic to a port on localhost without having more seriously compromised the system (Javascript and Java are two examples). As @calmh advised, Syncthing does have some protections against remote Javascript, but there are still possible issues here. |
|
I'd like to see a plausible scenario for your remote attacker accessing the interface on 127.0.0.1. If there is one, I'll reconsider that aspect. My position is otherwise that the vast majority of installs are on single user systems or the mutually-trusted-users setup. For setups with untrusted users on the same hardware the issue is plain and I'd hope that such users are aware of it - it's a fairly niche setup after all, in my opinion. Of course, using authentication is more secure than not, but there is also a convenience aspect. As it is we throw up large red alerts when bound to something other than localhost without authentication. |
|
@calmh Any web based scripting language (Javascript, Silverlight, whatever else someone might use), as well as Adobe Flash, and Java can do it with almost no user intervention, and it's not always guaranteed that these will be properly sand-boxed, and more importantly, are not always traceable as illegitimate connections. There's all kinds of other potential vectors, but they require much more effort from the attacker, and almost always result in either the system being more severely compromised (SSH can port forward, but for an attacker to use this they need an existing login or to compromise an existing login), or the user helping them out. |
No? I don't think they can, unless the script host is already compromised or the application in question is signed and accepted by the user (for Java). Can you point to any case or documentation where this is the case? SSH and so on of course yes, but then you're in the case where the user has actively given someone access. I'm talking about something initiated remotely, or something like a malicious webpage running in an otherwise uncompromised browser. |
|
Flash itself can, it's a pretty much complete (albeit isolated) programming environment, though most browsers these days that support it though have it properly sandboxed. Silverlight I can't give any background on because I have zero experience dealing with it aside from uninstalling it on every system I manage because of Microsoft's lack of support, it runs any .NET language though, so it should be trivial to do there. Javascript in a browser probably can't go cross-site anymore (it's been years since I've dealt with it so I don't know for certain), but I do know that it has the ability to open regular socket connections, and I do know there were browsers when I was dealing with it that didn't sandbox it well enough. As far as the Java prompt, that can be turned off (and I know quite a few people back when Java was the web app language who did), and things like that are not really all that much of a security item,, because a majority of users will just blindly accept it after the first time (It happened with Java prompts, it's pretty much happened with UAC and downloaded file protection on Windows, and it continues to happen in similar situations). There's all kinds of other methods of course, but most of them are still on the level of regular malware vectors or require significant user assistance. Using a virus vector to do this would be stupid though, almost all of them end up eventually being an ACE exploit, and if you've got such an exploit, you can do pretty much whatever the hell you want with the system, and therefore don't need to loop through user visible software to steal data. |
|
All the things you mention should have proper cross domain access restrictions. If your point is that they can compromise this via various exploits to get access anyway then you are correct, but the point is meaningless because then they might as well access the local filesystem directly. |
|
Should is not the same as must. You can't assume your users are using up-to-date software, or even well written software. I'm not saying you need to account for this, just that you need to consider it. |
|
Here are some examples.
Java - I have a home automation system controlled via a JavaWS app. I
have to click accept the first time, but then it can make arbitrary
network socket connections. So very many users do not understand the
implications of things and just click Accept all the time. I would
consider Java apps a viable attack vector.
Multiple user accounts - the untrusted account is more common than you
might think. For instance, families might set up limited accounts for
children that might have proxied Internet or keep them out of the
parents' private files. People that do this are unlikely to understand
the implications of connecting to a Syncthing web UI at localhost.
In fact, a great many people are unlikely to think of the implications
of that. Even ssh. For instance, consider someone that wanted to grant
someone else the ability to run a supposedly-secure and locked-down
command on their machine, but didn't know to add no-port-forwarding to
their authorized_keys file.
Basically what I'm saying is this is a real threat, and our battle
security-wise is to make things as hard as possible for attackers. This
just makes it easier for attackers.
|
If they are running an application on their PC which they trust, that application can already access all of their files. Syncthing is completely irrelevant. This is the classic "It rather involved being on the other side of this airtight hatchway",
Bear in mind that Syncthing is supposed to be run on login as the login user, so we're only worried about multiple currently-logged-in user accounts, which helps a bit. |
|
I think that for the Windows and Mac setups we recommend, this (multiple logged in users, that don't trust each others) is very unusual setup.
I'll change my mind on that when there is data to back it up. :) On Linux I'm sure it's legitimately much more common to have remote users logged in. I'm hoping that those users are a technically savvy niche that do appreciate the concerns. Basically, securing a multi user system is tricky. It's possible we could improve things though. I think one good way to do that would be to ship a good GUI app by default, with this GUI app being able to get access to Synchting by virtue of launching it itself - we can then enforce authentication as much as we like, without the user having to be confronted with it in in the normal case. |
|
It's fully possible to have multiple user logins on a single seat on both Linux and Windows (not sure about OS X). User switching has been around since at least XP on WIndows, and for at least since I started using Linux half a decade ago on Linux. Only one user is active at a time, but the other user's applications do keep running in the background. Under such a situation, it's fully possible to use the 'start at login, persist for session duration' approach used by Syncthing now and still have multiple instance s running at the same time on a given system. I do like the idea of adding a basic GUI that doesn't need a web browser, with two specific caveat's:
|
|
I don't think this issue should be solved in syncthing, since I don't see syncthing (the core application) targeting users without any knowledge of networks. In my opinion, it fits better in the wrapper applications like Syncthing-Gtk or SyncTrazor, which could set a randomly generated username and a password via environment variables (setting the login parameters via environment variables needs to be implemented in syncthing). But what really could improve the security, would be splitting the core application with the REST interface and the GUI into two separate binaries. The REST interface will be only accessible via API key and the GUI just connects to it, just like the wrapper applications do now. |
Again, I'm not arguing it can't be done, I'm arguing that it's a small minority case. We should be safe for the default 99% deployments, and I expect we are.
No, I think we do, I just don't think those users also have remote untrusted users on their computer. :)
Sort of, yes, with the main point is that the thing that launches Syncthing can specify an API key and use it to access the web UI. |
|
Maybe there should be a mode where Syncthing forces the user to specify a username and password before allowing them to do anything else (provided an API key isn't given)? Although this has its own issues: if a user uses a wrapper to set up Syncthing, someone else on the system could then do the first-time setup of the user and pass... |
What I meant with "core application" is the syncthing binary itself. I currently wouldn't recommend a windows desktop user to download the syncthing binary and use it without a wrapper application. For linux and osx, syncthing is actually usable on its own, but most non-technical people will probably still prefer a desktop application that wraps the syncthing binary. My guess is that there is only a small percentage of users that is using the plain syncthing binary that don't have at least basic knowledge of networks and web technologies. For all the others, the wrapper could start syncthing in a secure "single-user" mode, by setting a set of environment variables.
Yes. With the current GUI, which is provided by a http server, I thought of something like:
Wouldn't it be possible for the wrapper application to just set the username and password to something random and only use it internally? Is it really required that the user even knows of these login data? |
|
I think you're confused as to how the GUI works. The GUI is just a set of javascript and html files. The GUI uses the REST API in order to fetch the data to display. Given this, I really don't understand what your
I still offer users the ability to open Syncthing using a normal web browser, as sometimes there are display issues with my embedded browser. |
|
I may be wrong, but from my understanding, the basic authentication does not apply to the REST API, only to the GUI Web interface. It least that's how the REST APIs I've seen used to work.
You just have to include the username and the password you generated in the URL you send to the browser. If the REST API and the GUI is split in two binaries, there need to be two http servers running at different ports, at least in the first iteration, because that's how it currently works. First binary: syncthing-core and http server that provides the REST API. Secured by required API key in HTTP header Second binary: a second http server that just serves the HTML and JS files. This one should be secured by basic auth. For wrappers like Syncthing-Gtk, the syncthing-gui binary is not required, since it directly talks to the REST API. SyncTrayzor would have to start the GUI binary when the user opens the embedded browser window and can stop it when the window is closed. |
Nope.
Again, securing this gives you nothing. Someone could download the html/js files off github, and point them at the REST API. No different. |
|
The difference is that a running syncthing-gui process knows the API-Key. If you have access to the GUI, you can access the REST API without knowing the key. That's the point of the basic authentication in it's current form as well. |
|
So the browser talks to If you're going down that route, why not just start a single |
|
No, syncthing-gui would contain the complete GUI, HTML, JS, CSS files, images etc. The REST requests are performed in the same way it is currently done, via AJAX calls. |
|
In that case I still don't understand what you're trying to achieve. In case this is what's confusing you, I'll say it again: the GUI is just static html and javascript files. That javascript makes requests to the REST API, just like any wrapper. There is no difference between the GUI and a wrapper, as far as the REST API is concerned. |
|
Exactly, the current GUI would be just like a wrapper. You could then run syncthing without a GUI which is obviously more secure. If you require a GUI, you can start syncthing-gui or any sort of syncthing-wrapper and kill the process when you're done. |
|
You're still not telling me what security the |
|
syncthing-gui wouldn't be more secure, but the syncthing-core binary would. And the syncthing-gui binary can be started and stopped independently of syncthing-core and doesn't need to run all the time. |
|
@xduugu That still provides only marginally better security. The REST API is the security issue here, not the GUI itself. Anybody with a decent understanding of the API can talk directly too it. Having an API key will not necessarily help, because you can almost certainly retrieve the API key thorough any number of other methods (if it's a CLI argument, then you just need to know the core process' PID, if it's a config item, you just read the file, etc). @canton7 The point is an attempt at a separation of privileges, what @xduugu is talking about is proxying REST API calls through the component serving the UI pages, then having that add a API key or in some other way handshaking/authenticating with the REST API itself. |
No he isn't. I specifically asked that:
|
|
Also, just having the REST API does not make it more secure. I talk directly to it with wget on multiple systems I run syncthing on. Relying on the assumption that people won't know how to get to it without a GUI is security by obscurity, which is a method that's been proven regularly to be useless. |
|
@canton7 Then at least one of us is confused, because what I'm reading out of this except for one specific comment about using the 'same AJAX calls' is that he's talking about serving the UI from a separate program which would proxy the API calls and add an API key. |
|
On my (non-commercial) linux distribution, /proc/*/environ is only readable by the owner of the process. That's using the default configuration. Commandline on the other hand: But if the OS is not configured correctly, I don't see a possibility to hide sensitive data. You can only obfuscate it, but if you know what you are looking for, that doesn't help much. |
|
Apologies, I hadn't realized that environ and fd were readonly outside of the owning user, most of the time when I'm debugging things directly there, I'm running as root, so I don't typically see the permissions themselves. |
|
So, bringing this back on track: Syncthing can have the REST interface (and GUI) protected by auth (hashed in config file) and/or API key (unencrypted in the config file or environment variable), both of which is mostly secure against other non-adminstrator users. To provide a secure and easy to use GUI we could restrict it so that the GUI is not accessible without auth. The GUI wrapper would start Syncthing with a random API key in the environment and thus be able to provide a view of it without requiring the user to authenticate. SyncTrayzor, Syncthing-GTK etc could mostly do this today, if we provided a way to say "don't serve the UI without authentication". The user could set up authentication in this GUI and then be able to use from anywhere. This is a middle ground that I would consider valid. The next step would then be to ship Syncthing with such a GUI wrapper by default, leaving the current command line installation for servers only. I'm quite certain that I want the initial user experience after downloading and double clicking something to be that the user gets a usable GUI in front of them - not a requirement to set up a password. |
Yes! |
calmh
changed the title
calmh
added
the
enhancement
|
Reading other user's file, allowing attacker to bypass OS file permission system by just connecting to localhost (allowed to connect for all local users) is a vulnerability. |
|
Jupyter notebook is another localhost web application with similar security problems. They solved it by using tokens for authentication. When you run There is no requirement to setup a password and it works seamlessly. Once your browser is authenticated, you can close and reopen it as many times as you want, unless you remove authentication cookies. I wish SyncThing just copied this solution. |
|
@link2xt If the URL is passed to the browser on the command line, then that token is visible to all processes on the same machine (in That can work if you have a secure way to pass a secret URL to the user's browser, but the usual way (the command line) is not secure. |
|
@argv-minus-one Haven't thought about it, even though now I think that is the reason Jupyter documentation specifically says browsers token is one-time.
One way to work around this problem that I can think of is to create a temporary HTML file with redirect and point browser to it. |
I know. That's why it only creates a window of opportunity, rather than being a wide-open vulnerability.
That's better. Then, only processes that can read the temporary file can get the token. Note that this doesn't protect against malicious processes running under the same user ID. Normally, the user ID is a single security domain in which all processes trust each other, so that's okay, but if you're using something that restricts security domains further (like AppArmor), then the token may still be exposed across security domains. For example, sandboxed apps might have access to It would be completely safe to pipe a page or URL to the browser, but this would require special support in the browser (to pass the pipe file descriptor from the launcher process to the main browser process), which neither Firefox nor Chrome seem to have. A secure IPC mechanism like D-Bus would also be safe, but this, too, requires special browser support that doesn't seem to exist. |
I think Firefox supported D-Bus at some point, but looking into |
|
Most browsers already use a custom IPC mechanism to open URLs in a running instance, and would probably overwrite argv[0] anyway. |
|
What about matching incoming requests against the entries in (Or retrieve the same data via |
|
@yrro It is not portable. There is no |
|
Is there any way to disable insecure REST and the insecure HTML-GUI so as to mitigate those attack vectors and just use a local non-hosted GUI?? No TCP nonsense, no web sockets other than the sync operations, nothing but security. EDIT: you can have IPC without sockets, which is much more secure |
This thinking seems inverted. A secure system is not any that the world has failed to convince you of not being so. No one needs to show you data that an attack is possible, simply to invalidate your confidence to the contrary. The relevant question is whether evidence supports your confidence is, not whether it supports others' doubts. A system is secure when all of the components are secure, when their connections to each other are secure, and when the entire system rigorously follows a design that prioritizes security. The preferred approach in this case would be of acknowledging the application being designed without security taking priority, and holding the default assumption of its being insecure, until it might be rejected by a clear demonstration. If you wait to secure a system until someone discovers a vulnerability, then someone eventually will make such a discovery, and that person might not be a friend who politely explains the problems in a public discussion. |
|
HTTP is insecure, relying on extensions such as authentication and encryption inside the context of existing operating and networking systems. An application binding only to a loopback interface is not sufficient to resolve the security limitations of basic HTTP. IPC design is largely system-dependent and bound to the security model of the operating system, providing the security level appropriate to the use and design of the system. No assumption otherwise should be made by an application developer about how many users have access to a system, or which applications and of which types run on a system, except in embedded and sandboxed deployments that guarantee the required level of isolation. For control of the application, the following security-relevant cases emerge:
Cases of mutually-trusting users openly sharing data are unnecessary to consider, because from a security standpoint, each such case is the same as a single-user case, multiple users simply being a convenience. For case (1), a native front-end application is needed. A web browser is inadequate for this case, unless it is subsumed under (2), which would require a password even for local access. The front-end might be an adaptation of the existing third-party GTK interface, or a port of the existing web interface into Electron, in either case, the native wrapper providing secure communication, as through IPC, to a backend process, as appropriate for the operating system, rather than through an HTTP loopback connection. For case (2) and for case (3), a web interface is appropriate, with the application features protected by an authentication mechanism. Case (3) requires the further enhancement of the backend managing files and configuration for separate users, while itself running as a service with elevated permissions. It seems to me that the most natural course of evolution is to change the backend to process requests by native IPC, applying the security model of the local system, and adding a standalone desktop client. It may be desired to develop a further component that serves a web interface for remote access, protected by password authentication. Note that existing bittorrent applications handle case (1) and (2), but not (3). |
That's fine, OpenBSD users can fall back to using a password as they already do? |
Do not forget those who already have a strong auth : authelia, disallow unauthenticated mean condamn us to authenticate 2 time, one time with strong (2FA auth) and one with weak simple http auth credential. Edit: it's why i have totally disabled the auth and used the toogle "insecure admin access". |
|
I think forcing users to an option like the one described in the title and not providing ways to get out is a bad idea. I am deploying syncthing inside kubernetes to sync data between some nodes. I would like to get rid of this nagging error message: A solution - that involves extra work is to (manually) add username and password and always supplying those values at the http proxy level. For my use cases, I would also like to be able to specify folders and sync options in a declarative manner so I can automate them. But this is not currently possible. |
These is a way to get out "modify the config file ....... |
|
@BirdInFire : can you please be more specific? |
in the mean time i have found under advanced a way to remove this notification but a notification will appear (after each restart) to say it's disabled and unsecure (but not appear everythime and you can ignore it (if like me you have an SSO in front of it). |
You can also embed the username and password in the URL itself, or alternatively use a one-line custom theme to hide the notification with CSS completely. This isn't really the right place for an extended discussion of the topic though, so if you'd like to ask more questions regarding hiding the notification specifically, please open a new topic at https://forum.syncthing.net. |
Hello,
I initially discussed this with security@syncthing.net, and @calmh advised me to submit this here.
Through the "GUI" (web interface), an attacker could easily obtain all of the user's files by authorizing a new device ID into the sync. All an attacker has to do is somehow connect to the port on localhost.
Although syncthing supports setting a username/password for this, it is not done by default.
Unfortunately, connecting to a port on localhost is quite simple in a lot of cases. More and more systems are effectively multiuser today (not just Linux, but also think of Windows machines with multiple family members with accounts), and there are other ways to proxy a connection to localhost.
The simple solution to this would be to require (or at least very strongly encourage) the user to set a username/password if either the username or password are blank.
Furthermore, if syncthing wanted to let the user bypass this prompt when the web GUI is started from the CLI or syncthing-gtk, it could pass along an auth token in the initial URL (git-annex does this). I do not see this as all that critical, thoough.
@calmh advised me that the API is already secured and that Syncthing does have protections for XSS in the web GUI, which narrows but does not eliminate the attack surface.
Current behavior as of 0.13.9.
The text was updated successfully, but these errors were encountered: