LWN: Comments on "Guile security vulnerability w/ listening on localhost + port"

Guile security vulnerability w/ listening on localhost + port

alkadim — Tue, 18 Oct 2016 02:45:18 +0000

> no DNS rebinding is needed

Indeed, just like plain old CSRF.

Reading my message again I feel I should try to clarify: I did not intend to say there was no vulnerability (after all,
Guile is executing code without even attempting authentication), I intended to say that it was nothing new or
particularly clever. (Though it's appalling to know that even old and simple hacks are still exposing such gaping
security holes.)

Now, when I said "NoScript ABE killed this", "this" should have been unpacked to "cross-origin requests to localhost".

> I don't see why XMLHttpRequest would be needed here either - a simple <img src="http://localhost:37146/?attack-code">
> or <a href="http://localhost:37146/?attack-code">click me to learn about an important security vulnerability</a>
> sounds like it ought to work just as well in this case, with no scripting involved.

Yes. ABE will trap the first one (subresources) by default, being cross-origin. It can also trap the second one
(links, forms), but won't by default because the "Accept from LOCAL" line means non-cross-origin is allowed. I have
that one commented out in my "internet" profile.

Guile security vulnerability w/ listening on localhost + port

arielb1@mail.tau.ac.il — Mon, 17 Oct 2016 20:28:10 +0000

Not only on multi-user systems - all sorts of programs assume it is safe to make data-driven requests to data-driven IP addresses, so treating IP address connectivity as authority is A Bad Idea.

OTOH, non-buggy programs do not access data-driven file paths, so access to a file (or a UNIX socket) can be more safely treated as authority.

Guile security vulnerability w/ listening on localhost + port

mathstuf — Mon, 17 Oct 2016 18:49:32 +0000

It'd be nice if Linux would steal some bit of the IPv6 address space and make it so that a socket could be routed to via those addresses with the underlying domain socket permissions being enforced. Would probably need a second bind(2) call to bind it there, but that'd be fine with me.

Guile security vulnerability w/ listening on localhost + port

flussence — Mon, 17 Oct 2016 16:37:58 +0000

> But people writing non-HTTP servers may still be quite surprised that attackers can send HTTP requests to them, and they may foolishly believe in Postel's law and accept those unexpected requests.
For that reason, various browser engines have a hardcoded list of ports they'll never connect to, which includes a large chunk of ports <1024 and things like X11 (6000) or IRC (6667). The general rule seems to be “if it was popular 25 years ago, it's probably insecure”.

The X11 one in particular causes an occasional WAT reaction: it's common for people writing unprivileged-user HTTP servers to pick a round number like port 3000 or 5000.

Guile security vulnerability w/ listening on localhost + port

epa — Mon, 17 Oct 2016 14:59:06 +0000

I suppose Linux could work around it by letting you set up multiple localhost addresses each restricted to a particular user. Or find some more general way to tie Unix domain sockets into the IP address system, so userland doesn't have to care that they exist.

Guile security vulnerability w/ listening on localhost + port

excors — Mon, 17 Oct 2016 14:25:09 +0000

> Sounds like plain old CSRF attack. NoScript ABE killed this many years ago. (Surely you are running NoScript.) Plus, reasonable DNS servers should reject DNS rebinding to local addresses

https://blog.lizzie.io/exploiting-CVE-2016-8606.html indicates no DNS rebinding is needed, you can use XMLHttpRequest to send an HTTP GET request with an attacker-controlled URL (containing some Guile code) directly to localhost. The web's security model assumes that GET requests will cause no harmful side-effects, so it's safe to send arbitrary GETs to arbitrary hosts. (It does assume they might return confidential information, so (by default) CORS will prevent an attacker seeing the response, but it will still happily send the request first.)

I don't see why XMLHttpRequest would be needed here either - a simple <img src="http://localhost:37146/?attack-code"> or <a href="http://localhost:37146/?attack-code">click me to learn about an important security vulnerability</a> sounds like it ought to work just as well in this case, with no scripting involved. That's why the web's security model makes those assumptions about GETs - it's been trivial to send arbitrary GET requests since the very beginning of the web (before anyone cared about security), so everyone writing servers should already be aware of that. But people writing non-HTTP servers may still be quite surprised that attackers can send HTTP requests to them, and they may foolishly believe in Postel's law and accept those unexpected requests.

Guile security vulnerability w/ listening on localhost + port

flussence — Sun, 16 Oct 2016 01:32:21 +0000

It's trivial to deny specific processes network access: just prefix the command with "unshare -n" (allowing selective traffic through is where it gets painful...)

Guile security vulnerability w/ listening on localhost + port

flussence — Sun, 16 Oct 2016 01:20:43 +0000

One browser does have exactly this system, right down to the 4 distinct zones, but unfortunately its Unix version was abandoned around the turn of the century and nobody else thought to adopt the idea...

Guile security vulnerability w/ listening on localhost + port

cortana — Sat, 15 Oct 2016 09:43:00 +0000

Other users can be rejected if the server checks incoming connections against /proc/net/tcp, paying attention to the uid field. This is analogous to SO_PEERCRED, though Linux-specific.

Guile security vulnerability w/ listening on localhost + port

mathstuf — Fri, 14 Oct 2016 20:31:49 +0000

Yep. Unfortunately, for things like HTTP proxies, nothing (that I can find) supports using a domain socket as the proxy URI, so you're stuck with a localhost port AFAIK. I requested support from libsoup a while ago, but it was hairy because everything basically assumed there were things like "ports" and a "remote IP address".

Guile security vulnerability w/ listening on localhost + port

drag — Fri, 14 Oct 2016 16:46:58 +0000

bugs happen. You should file a report.

$ echo 'cow' > index.html
$ xdg-open index.html

works well for me.

I have found that a lot of applications try to be 'too smart' about things when trying to launch other 'helper' applications. They try to create their own solutions instead of just using the 'standardized' interfaces like the ones defined by the 'X Desktop Group'. Especially anything to do with email tends to be nightmarishly incorrect and/or cludgy since much of what gets installed pre-dates xdg stuff.

And, besides, even if your stuff is broken wouldn't it be better to have it 'broken and more secure' then 'broken and less secure'?

Guile security vulnerability w/ listening on localhost + port

niner — Fri, 14 Oct 2016 15:42:42 +0000

Right now, half of the time I click a link in some application, the opened chromium window greets me with a failure to open my profile because it didn't notice that chromium was already running and started another one.

My faith in a working solution with added security is less than noteworthy.

Guile security vulnerability w/ listening on localhost + port

drag — Fri, 14 Oct 2016 15:22:36 +0000

> Than how shall I check the generated HTML documentation for my project? Or read the the documentation from /usr/share/doc?

You need to map the files or directories containing the files you want to view to the browser's file system namespace.

Mount binds is one simple way to do it.

A more advanced theoretical 'user friendly' approach would be to use something like a Fuse file system that makes up the browser's file system namespace. When the browser is launched the fuse file system is launched to go along with it.

You could then run a command like 'html-browser-open' on a particular file or directory and have that file or directory mapped to the browser's namespace. The browser could be modified slightly to monitor the 'mapping directory' and automatically open up whatever shows up there.

'html-browser-open' could be command line, or issued from the GUI file manager, or a dbus instruction. Simple access control lists could control what applications are allowed to issue these types of requests. Users could control these lists and be notified in the case of some application sending a request to another application unexpectedly.

Guile security vulnerability w/ listening on localhost + port

drag — Fri, 14 Oct 2016 14:42:16 +0000

> That said, the advice about preferring unix-domain sockets seems sound, that is until browsers give javascript access to that as well...

We can manage permissions to unix sockets pretty well using file system-based access control rules. Of course file system permissions are based on UID and within a user account it's usually 'anything goes'.. that is the web browser has the same rights and privileges to the file system that the user running it has. SELinux is useful here, but painful.

With internet sockets the only real rule, most of the time, is 'need to be root to create socket numbered lower then 1024'. And that's pretty much it. Otherwise anything can do anything. I suppose you could use iptables, but that is also really painful unless you are running some very static setup.

Android is a bit more robust in this regard because each application ends up running as a different UID and has some basic provisioning for internal controls via privileges based around traditional Unix group membership and standardized application APIs. Not too useful for normal Linux installs unless you want to rewrite every application, unfortunately.

The solution seems to be, at this point, is to use container-style namespace-based sandboxing. That way you can run applications with a sort of 'need to know' approach without having to modify the applications themselves (much). If applications don't 'need to know' about sockets (internet, unix or otherwise) they won't ever be able to see them. If they can't ever see them then it's going to be a lot more difficult to do something malicious with them.

Guile security vulnerability w/ listening on localhost + port

bandrami — Fri, 14 Oct 2016 13:03:42 +0000

IDK... I've got about 7 "users" running on my laptop right now: mpd, sshd, apache, postgres. Since the point of running those daemons as dedicated users is at least primarily security, it's good to remember what they are and aren't isolated from (even a chroot doesn't do anything to keep a daemon away from 127.0.0.1:80).

Guile security vulnerability w/ listening on localhost + port

matthias — Fri, 14 Oct 2016 12:19:37 +0000

I know that there are still problems with the idea. I would accept that I have to do an additional click in the file open dialog, if I could get my browser secure. The browser could open the dialog with some file preselected. Thus the navigation would not be needed. The user would only have to confirm (with one click) that the file should be opened, such that a malicious website cannot open your .ssh/id_rsa through some bug in the flash viewer without your approval.

With a bit more effort, the location bar could be operated by a different process than the renderer. This process could have the necessary permissions to open local files and pass them (by FD) to the renderer. I just want the fraction of the browser that has permissions to access my files to be small enough that there is a reasonable probability to get this fraction free from serious bugs. That means this fraction has to be tiny. Especially no plugin and no complex code like rendering complex stuff like images, pdfs, or even true-type-fonts should have the permissions to access my files without prior approval. Such code is much too complicated to really get it bug free. Thus it has to run in a restricted container.

For browsing html documentation of course this cannot be restricted to simple FDs. Instead, a possibility to pass entire directories into the container would be needed. It is not only browsing from chapter1 to chapter2, but also images in the documentation. For many other applications passing single files is fine, but html is a multi-file format.

Guile security vulnerability w/ listening on localhost + port

Karellen — Fri, 14 Oct 2016 11:57:20 +0000

Sorry, I missed the "the containing folder should be added" part.

*sigh*. Read more slowly next time...

Guile security vulnerability w/ listening on localhost + port

Karellen — Fri, 14 Oct 2016 11:55:05 +0000

So, if I click <File>/<Open>, navigate to a directory, and select a file then it works, and the location bar shows file:///home/karellen/project/foo.html.

But if I type file:///home/karellen/project/foo.html into the location bar, it doesn't work - except maybe without extra clicking from some confirmation dialog?. And bookmarks to local files don't work (without extra clicking...)? And links between file:///.../chapter1.html and file:///.../chapter2.html don't work?

Guile security vulnerability w/ listening on localhost + port

matthias — Fri, 14 Oct 2016 10:40:07 +0000

For my personal notebook, any other user on that machine is precisely the empty set. I would prefer if a port that I open on localhost would be safe, but this would require some effective barriers for processes communicating over the web (especially browsers).

Of course, on multi-user systems localhost was never safe and programs like guile should expect to be running on a multi-user system and make the default configuration safe.

Guile security vulnerability w/ listening on localhost + port

matthias — Fri, 14 Oct 2016 10:30:48 +0000

Using another instance of the browser that is outside the container (or inside a container with different restrictions).

Having these barriers in place would be a big improvement of security. Of course, as bferrell said, there are already some barriers inside the browser, but still there are too many vulnerabilities, where an exploit can manage to escape. The kernel can provide more security than the browsers are currently using. The main reason the browser don't use these is of course usability.

There would be quite a bit of work to be done to get this as transparent as possible. E.g., if you open some html documentation, the containing folder should be added to the container instance, such that browsing different files would work, etc. The web interface of your project is a bit different. A developer can be expected to do 1 or 2 minutes of configuration to get a container instance suited for testing, but the common case should just work out of the box.

The main reason, I would like this to be done on operating system level is that it could easily be applied to other processes, e.g., libreoffice, pdf readers. All of these had their pile of critical bugs that would be much more harmless, if the process would be restricted to the necessary resources.

Right now, most user programs have full access to the users home directory, because the user might want to open another file. This is exactly the directory that should have maximum protection, because it might contain sensitive or private data. Restricting the programs, that they cannot access the home directory, except through the file open dialog of the desktop environment that would pass a FD back, would give much more protection. The programs could only access files explicitly selected by the user.

Guile security vulnerability w/ listening on localhost + port

NAR — Fri, 14 Oct 2016 08:59:36 +0000

Why not putting the browser into a container, where it has a network namespace restricted to the internet, a filesystem/mount namespace restricted to its configuration files and a directory for storing downloads, etc.?

Than how shall I check the generated HTML documentation for my project? Or read the the documentation from /usr/share/doc? Not to mention testing the web interface of my project?

Guile security vulnerability w/ listening on localhost + port

alexl — Fri, 14 Oct 2016 08:21:25 +0000

I don't see how some port on loopback iface was ever considered "safe". Any user on that machine can connect to it at the very least.

Guile security vulnerability w/ listening on localhost + port

roc — Fri, 14 Oct 2016 06:56:20 +0000

Chrome and Firefox on Linux are already doing a lot of this internally. Actually their Web-content processes are even more restricted, and talk to a master "broker" process via IPC to fetch configuration data etc.

Guile security vulnerability w/ listening on localhost + port

epa — Fri, 14 Oct 2016 06:48:55 +0000

Well, duh. On any multiuser system there is no guarantee that the process connecting to a port on localhost is the same user as the one listening.

Guile security vulnerability w/ listening on localhost + port

matthias — Fri, 14 Oct 2016 05:52:03 +0000

I prefer to have this boundary not in the browser, but in the operating system. Why not putting the browser into a container, where it has a network namespace restricted to the internet, a filesystem/mount namespace restricted to its configuration files and a directory for storing downloads, etc.? This has the advantage that also vulnerabilities in plugins as flash, java, etc. are not that easy to exploit.

I know that there are some tasks to solve. How to upload a file to the internet? The user prefers, not having to copy the file to the browsers container before. But there should be a way such that the browser can access the file open dialog from the desktop environment and then get a fd back.

The kernel should be roughly at a point, where this works. The userspace is not. Creation of containers for user applications would need to be (almost) transparent to the user.

Guile security vulnerability w/ listening on localhost + port

bferrell — Fri, 14 Oct 2016 04:54:32 +0000

because localhost is just a name, usually attached to the ip address 127.0.0.1 in /etc/hosts. localhost is "translated" by the glibc resolver routines. The resolver routines are configured via the file /etc/nsswitch.conf allowing the use of files and/or other methods for converting names to addresses, providing a uniform means of converting names to addresses.

It's NOT really a vulnerability, but to the ignorant it can look like one.

Guile security vulnerability w/ listening on localhost + port

pabs — Fri, 14 Oct 2016 03:46:54 +0000

I always wondered why browsers don't put boundaries between localhost, localnets, VPNs and the Internet.

Guile security vulnerability w/ listening on localhost + port

alkadim — Thu, 13 Oct 2016 22:42:31 +0000

Sounds like plain old CSRF attack. NoScript ABE killed this many years ago.
(Surely you are running NoScript.) Plus, reasonable DNS servers should
reject DNS rebinding to local addresses (dnsmasq, used by NetworkManager,
for example, should do this with --stop-dns-rebind, enabled by default).

That said, the advice about preferring unix-domain sockets seems sound, that
is until browsers give javascript access to that as well...