Security Feature Request: Randomized URL Suffix for Administrative GUI

Currently the URL is like

http://localhost:<some port>:

The wish is:

http://localhost:<some port>/<some at least 30 characters long random suffix>

The URL with the random suffix would be printed to the console at startup or to keep the personal bookmarks working the URL is given as a console argument to the "bin/rethinkdb".

To make it useless to try to guess the URL suffix by trying out different versions of it (brute force attack), the GUI server side should implement a ~5ms mandatory delay, which is added to the time it takes to actually process the request. The delay should be added to ALL RESPONSES, including the ones with the correct URL suffix. The ~5ms delay will not be noticed by humans, but it limits the maximum number of tries per second to 200.

The reason, why all authenticated responses must have at least as long a delay as the responses, where the authentication fails (the URL suffix is wrong) is that if an authenticated response has a delay of X and a non-authenticated response has a delay of 3X, then the attacker can conclude that the authentication failed by waiting a time period of X+delta, including 2X, and that makes the effective delay to be equal with X, not 3X. To avoid a workaround, where a swarm of bots tries out different URL suffixes in parallel and also waits out the delays in parallel, the delay must be global, id est if 2 requests to the web GUI server come in, then they will be delayed sequentially, the processing, including the delay, of a new request starts after the delay of the previous request ended. Only the delays must be sequential, id est it's OK to work on a request that has an expired delay while the delay of another request is in progress.

The same idea applies to web-apps that use password based authentication, except that the delays are "global" for each user(name) individually. Different users can be processed in parallel, they can wait the expiration of their delays in parallel.

An improvement of this feature might be that if the URL suffix was not given as a command line argument, then the URL suffix is automatically changed in every 10 minutes. The "bin/rethinkdb" prints the new URL to the console and the Web GUI does an automatic redirect to the new URL.

The length of the random steam of characters is debatable, but the following things should be kept in mind:

If a command line based URL suffix is used, then users will probably be pretty lazy at changing it and the same URL suffix will be used for years.
As of 2017 general purpose CPU-s that have 1024 cores do exist

@martinvahi you really shouldn't be exposing the web UI over the public internet in the first place. Making it difficult to guess what path the server responds to does not even begin to address the security concerns. Not only would you still be opening yourself up to potential DoS attacks, but if you're not connecting to the UI over https someone could just sniff your network traffic to discover the suffix you're using.

I don't think we should expose functionality like this that encourages users to expose their cluster over the internet without fundamentally addressing the security implications.

@marshall007 Thank You for Your comment, but my feature request was about the

localhost

not public network interfaces. Generally speaking, if some server attaches itself to a localhost port, then unless that server has also other open ports or pipes or the localhost port is redirected, that server is not available from the public IP-address of the machine. However, there is the issue that if an operating system user U_1 opens up port P_1 at localhost, then another operating system user, U_2, of the same machine can attach to the port that the U_1 opened.

A workaround to separate operating system users might be to use named pipes in stead of network interfaces. Named pipes use file system permissions to enforce the boundaries between the operating system users, but they do nothing against a situation, where the same operating system user, for example the U_1, accidentally executes a spy-malware that tries to access the database administration interface. The spy-malware might use some general library as a Trojan horse and be loaded as part of some "JPEG-decoding" library or something else perfectly legitimate and innocent that many different programs use. The operating system process table will not display the spy-malware, because the spy-malware is part of a perfectly legitimate operating system process, which is, as expected and as it should be, listed at the list of operating system processes.

At an era, where development tools and packaging systems (apt-get, yast, gem, npm, mvn, gprbuild, You-Name-Your-Favorite) download dependencies automatically, from a vast variety of rolling repositories, it is unlikely that absolutely all developers in the world have their development machines so well secured that nobody can insert spy-ware or something "small" that hooks to the spyware before the developer signs and publishes its work. At least I am INCAPABLE of guaranteeing that my software is free from malware, despite the fact that I will never embed malware in my software.

(Actually, the NEVER really is NEVER, even, if I intentionally wanted to attack someone with malware, because no obfuscator obfuscates away the math theory and architecture of the software and the thinking style and knowledge about math is a HUGE FINGERPRINT for every developer, but malware must keep the attacker anonymous. That probably explains, why the malware writers publish their creations as open source virus kits, because the more people use those malware kits, the greater the possibility that the original author of the malware can also use its own software for attacks.)

My view about security audits is described at my blog: The Future of Security Audits, Episode 0 (archival copy)

To prevent the malware that runs as an operating system process of the same user that runs the RethinkDB server from accessing the RethinkDB data storage files directly, something like the Security-Enhanced Linux has to be used, but that is outside of the scope of the RethinkDB project and up to the end users to configure properly. An attack, where the malware makes a screenshot and uses Optical_Character_Recognition to get the RethinkDB administrative GUI URL, is, again, outside of the scope of the RethinkDB project and up to the end user to patch. Probably the first people, who can "patch" the screenshot based vulnerability are the GenodeOS developers, because the GenodeOS has a special "X11-replacement" that prevents different applications from accessing each other's windows.

We are not going to do this, because the economic value is negative.

Thank You for the reply.

Interestingly I thought of the RethinkDB as a project, where reliability was considered important. Security is a sub-field of reliability: secure software/hardware is able to work more RELIABLY in the environment of adversarial activity. I thought that at the era of NSA and Edward Snowden an application like a DATABASE ENGINE is exactly one of those applications that, if done well, is implemented with security in mind.

Yet, here I read the typical corporate speak for being sloppy: "economic value is negative". In my view it would be perfectly OK to just set the feature request to some low priority status and say/write it directly that due to the huge amount of tasks at hand and due to the loss of funding tasks have to be prioritized and the current feature request is so low priority that it won't be even considered for years, because people do it from their free time and we already have a pile of pull requests to merge, etc.

But, the "Won't fix, because there's no economic value" excuse??? Since when did any of the free software, including the whole Linux operating system, have any ECONOMIC VALUE as the basis for doing anything? If open source software were developed for ECONOMIC VALUE, in stead of being developed for practical needs to get something done, including business related tasks, then the result would be something that the Microsoft with its products already offers. ECONOMICALLY SPEAKING: open source projects that are developed for ECONOMIC VALUE LOOSE THEIR COMPETITIVE EDGE to vendors like Microsoft. (Yes, I'm referring to the quality of their products, specially security.)

So, I suggest that You reopen it and set it to some low priority task with a label, "security enhancement", in stead of leaving the feature request closed. As I said: open source software is about QUALITY, not ECONOMIC VALUE. The "economic value niche" has been already thoroughly fulfilled by various megacorporate vendors and now that the company behind the RethinkDB has also collapsed, there's no rush to make ends meet, which in turn gives an opportunity to try to do a really good job, to make the RethinkDB have the properties, where the "economic value" oriented vendors, for example the fierce competitor of the RethinkDB, MongoDB, fail to deliver, because "the economic value is negative", they need to feed their investors, pay salaries, etc.

Historic examples of open source project that focused on technical delivery in stead of "economic value" and which now literally define the industry are the GCC compiler and Vim. The GCC command line options and compatibility with GCC is something that all other C/C++ compiler implementations have to consider. Even the Microsoft's C++ compiler had to cope with code that GCC was able to compile, with the exception of DLL related code, which could be made conditionally available with macros. The Vim key bindings are supported by all major IDE-s either by default or in a form of some plugin.

Why to give up with the RethinkDB?

Thank You for reading my comment.

One way to look at the situation might also be that there's a difference between the start-up mode of development, where new round of investment is needed, which depends on the market penetration, number of users, etc. and the non-commercial open source development, where there is no rush, no hurry to gain as many users as possible and the main goal is to create the technically best product that one can imagine, even when only a small group of people use that product.

Basically, in the start-up mode the goal is to become the popular party in town and in the non-commercial open source development mode one focuses on creating a beautiful pyramid or mountain temple that outlives all the popular parties and is admired only by a few, who take their time to get into the details, but the admiration by the elite minority lasts for thousands of years.

@martinvahi I feel like I have to but in as I think @srh is doing an important job of cleaning up the issues. While I don't have an opinion at the matter at hand, there are a ton of issues and little resources. I think it would be best to get rid of all issues that aren't bugs for now unless someone adds a pull request. Other issues could be opened in the future once the project gains some steam. Otherwise nobody can see the forest for the trees... You can always ask to reopen this in the future.

This issue was closed along with many others in an effort to close inactive low-priority issues.

@martinvahl I think everyone here already understands the implications of exposing an unprotected admin interface on a local port. It is (perhaps unfortunately) a common practice in a lot of other software too.

However I think there is a solution that is more consistent with the rest of RethinkDB (#6037).

The availability of easy workarounds also makes fixing this bug low priority. RethinkDB can be run in a container or passed the --no-http-admin option.

@martinvahi By economic value I mean the sum of the practical usefulness, positive or negative, to people.
I.e. quality. For starters, it doesn't really improve security. And it'd be really annoying to people -- if it were on by default, the project would get forked. Nobody would use it. Hence, negative value.

This entire feature is for the threat model of somebody on the same machine. Because this doesn't help much if you're on a public network. This isn't a real problem, and the right solution is TLS and some form of authentication if you're on a public network. Which suffices for a local machine too. If anybody implements anything, it's going to be that.

So this is a bad idea. I'm guessing @atnnn reopened the issue because you felt bad. It still should be closed because this is a 100% wontfix.

Thank You, everybody, including the @srh, for the answers, thank You for the kindness and I also thank the @srh for the further explanation about the background of the closing of this feature request.

However, what regards to the statement that the threat model, where an adversary is on the same machine with the RethinkDB server, is not frequent or severe enough to be addressed with countermeasures, then I disagree with that statement. My explanation is that given the

efforts to compromise system administrators (archival copy)

there is absolutely no reason to believe that there are no efforts to compromise software developers. I'm not an author of any popular software component, but authors of a popular software components are certainly a greater prize than system administrators, because popular software components get installed to multiple networks, including many virtual appliances that run in the "cloud", whilst system administrators usually manage only a single network, unless they work at some service company. If a software developer's computer gets compromised and he/she has a habit of signing his/her creations, then the software developer is likely to sign a Trojan horse or some other form of malware or part of some malware that might be just a few modifications to his/her own software and appear as if the software developer had done a few, small, accidental typos or something similar, minor. I, for instance, am not capable of guaranteeing that my own software is malware free, despite the fact that I self do not place any malware to my open source projects.

What regards to the argument that open source software can be audited by a lot of people, then first of all, everybody is overwhelmed with a lot of work and software can be audited only by those, who know the software project's internals. Even if people had lot's of time for manual audits, there's still the "chessboard case", where both players can see all of the buttons on the chessboard, but still only the smarter/more_skillful player wins. In the case of a huge software project not only are there much more buttons on the "chessboard", but some of the buttons are not even visible, specially those, which get loaded with "eval" or in a form of third party libraries, including dynamically linked libraries.

To bring a bit of historical perspective to my current comment, the things that the Edward Snowden revealed, could be concluded from the publicly known technical facts that were covered at a basic level computer security courses in 2003 at the University of Tartu. As a bit of a joke, it turns out (archival copy) that even the lecturer, Meelis Roos, is still the same there, still running the same course, in Estonian. (He is really good at what he does, I like him as a lecturer, but that case just shows that if people at the middle of nowhere like Tartu can figure things out and do a good job, without any Edward Snowden telling them about it, then clearly I as a small and irrelevant freelancer would do a tremendously shoddy job if I dismissed the computer security basics in practice.)

I'm not sure that I know a proper solution right now, but I suspect that one way, how to partly counter the situation, where a library has been compromised, is to wrap libraries that do not have direct read/write access to data store to an application specific wrapper that acts also as an adapter (archival copy) that connects the library to the "main" program. The wrapper would run at the rights of a separate user and communicates with the "main" program through Linux named pipes. Actually, that's just one tiny bit of the whole story, I've spent quite some time thinking and designing the countermeasure and as of 201705 I still need to try things out and experiment, but the general scheme is to build a "castle island" so that in stead of raising a small fence and then tearing it down and replacing it with a greater fence and then tearing that down and replacing it with even greater fence, proper walls are designed and built from the very start, without wasting time and effort on building the temporary, shoddy, useless, fences. (The Google streetview images of the Kuressaare castle originate from one of my former home towns, Kuressaare, where I spent most of my childhood. That's how I knew, where to look :-)_

So, again, thank You for Your answers, thank You for reading my comment, but I still maintain that the threat model, where the adversary resides within the same machine with the protection worthy resource is serious enough to be NOT dismissed, even, if it is a low priority issue that is handeled at some later date. There is no need to wait, till some "new Edward Snowden" tells the World about it.

But the right way to handle it is with TLS and authentication, a login, not some rotating URL scheme.

rethinkdb / rethinkdb

Security Feature Request: Randomized URL Suffix for Administrative GUI #6329