Guile security vulnerability w/ listening on localhost + port
There is also a lesson here that applies beyond Guile: the presumption that "localhost" is only accessible by local users can't be guaranteed by modern operating system environments. If you are looking to provide local-execution-only, we recommend using unix domain sockets or named pipes. Don't rely on localhost plus some port."
Posted Oct 13, 2016 22:42 UTC (Thu)
by alkadim (guest, #104623)
[Link] (4 responses)
That said, the advice about preferring unix-domain sockets seems sound, that
Posted Oct 14, 2016 14:42 UTC (Fri)
by drag (guest, #31333)
[Link]
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.
Posted Oct 17, 2016 14:25 UTC (Mon)
by excors (subscriber, #95769)
[Link] (2 responses)
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.
Posted Oct 17, 2016 16:37 UTC (Mon)
by flussence (guest, #85566)
[Link]
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.
Posted Oct 18, 2016 2:45 UTC (Tue)
by alkadim (guest, #104623)
[Link]
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,
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">
Yes. ABE will trap the first one (subresources) by default, being cross-origin. It can also trap the second one
Posted Oct 14, 2016 3:46 UTC (Fri)
by pabs (subscriber, #43278)
[Link] (12 responses)
Posted Oct 14, 2016 4:54 UTC (Fri)
by bferrell (subscriber, #624)
[Link]
It's NOT really a vulnerability, but to the ignorant it can look like one.
Posted Oct 14, 2016 5:52 UTC (Fri)
by matthias (subscriber, #94967)
[Link] (9 responses)
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.
Posted Oct 14, 2016 6:56 UTC (Fri)
by roc (subscriber, #30627)
[Link]
Posted Oct 14, 2016 8:59 UTC (Fri)
by NAR (subscriber, #1313)
[Link] (7 responses)
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?
Posted Oct 14, 2016 10:30 UTC (Fri)
by matthias (subscriber, #94967)
[Link] (3 responses)
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.
Posted Oct 14, 2016 11:55 UTC (Fri)
by Karellen (subscriber, #67644)
[Link] (2 responses)
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?
Posted Oct 14, 2016 11:57 UTC (Fri)
by Karellen (subscriber, #67644)
[Link]
*sigh*. Read more slowly next time...
Posted Oct 14, 2016 12:19 UTC (Fri)
by matthias (subscriber, #94967)
[Link]
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.
Posted Oct 14, 2016 15:22 UTC (Fri)
by drag (guest, #31333)
[Link] (2 responses)
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.
Posted Oct 14, 2016 15:42 UTC (Fri)
by niner (subscriber, #26151)
[Link] (1 responses)
My faith in a working solution with added security is less than noteworthy.
Posted Oct 14, 2016 16:46 UTC (Fri)
by drag (guest, #31333)
[Link]
$ echo 'cow' > 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'?
Posted Oct 16, 2016 1:20 UTC (Sun)
by flussence (guest, #85566)
[Link]
Posted Oct 14, 2016 6:48 UTC (Fri)
by epa (subscriber, #39769)
[Link] (4 responses)
Posted Oct 14, 2016 20:31 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
Posted Oct 17, 2016 14:59 UTC (Mon)
by epa (subscriber, #39769)
[Link] (1 responses)
Posted Oct 17, 2016 18:49 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link]
Posted Oct 17, 2016 20:28 UTC (Mon)
by arielb1@mail.tau.ac.il (guest, #94131)
[Link]
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.
Posted Oct 14, 2016 8:21 UTC (Fri)
by alexl (subscriber, #19068)
[Link] (4 responses)
Posted Oct 14, 2016 10:40 UTC (Fri)
by matthias (subscriber, #94967)
[Link] (2 responses)
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.
Posted Oct 14, 2016 13:03 UTC (Fri)
by bandrami (guest, #94229)
[Link] (1 responses)
Posted Oct 16, 2016 1:32 UTC (Sun)
by flussence (guest, #85566)
[Link]
Posted Oct 15, 2016 9:43 UTC (Sat)
by cortana (subscriber, #24596)
[Link]
Guile security vulnerability w/ listening on localhost + port
(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).
is until browsers give javascript access to that as well...
Guile security vulnerability w/ listening on localhost + port
Guile security vulnerability w/ listening on localhost + port
Guile security vulnerability w/ listening on localhost + port
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”.
Guile security vulnerability w/ listening on localhost + port
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.)
> 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.
(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
Guile security vulnerability w/ listening on localhost + port
Guile security vulnerability w/ listening on localhost + port
Guile security vulnerability w/ listening on localhost + port
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.?
Guile security vulnerability w/ listening on localhost + port
Guile security vulnerability w/ listening on localhost + port
Guile security vulnerability w/ listening on localhost + port
Guile security vulnerability w/ listening on localhost + port
Guile security vulnerability w/ listening on localhost + port
Guile security vulnerability w/ listening on localhost + port
Guile security vulnerability w/ listening on localhost + port
Guile security vulnerability w/ listening on localhost + port
$ xdg-open index.html
Guile security vulnerability w/ listening on localhost + port
Guile security vulnerability w/ listening on localhost + port
Guile security vulnerability w/ listening on localhost + port
Guile security vulnerability w/ listening on localhost + port
Guile security vulnerability w/ listening on localhost + port
Guile security vulnerability w/ listening on localhost + port
Guile security vulnerability w/ listening on localhost + port
Guile security vulnerability w/ listening on localhost + port
Guile security vulnerability w/ listening on localhost + port
Guile security vulnerability w/ listening on localhost + port
Guile security vulnerability w/ listening on localhost + port