Guile security vulnerability w/ listening on localhost + port (with fix)

[Christopher Allan Webber <cwebber@dustycloud.org>]

[-- Attachment #1: Type: text/plain, Size: 3196 bytes --]

The Guile team has just pushed out a new commit on the Guile stable-2.0
branch addressing a security issue for Guile.  There will be a release
shortly as well.  The commit is
08c021916dbd3a235a9f9cc33df4c418c0724e03, or for web viewing purposes:

  http://git.savannah.gnu.org/cgit/guile.git/commit/?h=stable-2.0&id=08c021916dbd3a235a9f9cc33df4c418c0724e03

Due to the nature of this bug, Guile applications themselves in general
aren't vulnerable, but Guile developers are.  Arbitrary scheme code may
be used to attack your system in this scenario.

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.

To give context, Guile supports a nice live-hacking feature where a user
can expose a REPL to connect to, through Geiser
(http://www.nongnu.org/geiser/) or so on.  This allows Guile users to
hack programs even while programs are running.

The default in Guile has been to expose a port over localhost to which
code may be passed.  The assumption for this is that only a local user
may write to localhost, so it should be safe.  Unfortunately, users
simultaneously developing Guile and operating modern browsers are
vulnerable to a combination of an html form protocol attack [1] and a
DNS rebinding attack [2].  How to combine these attacks is published in
the article "How to steal any developer's local database" [3].
  

In Guile's case, the general idea is that you visit some site which
presumably loads some javascript code (or tricks the developer into
pressing a button which performs a POST), and the site operator switches
the DNS from their own IP to 127.0.0.1.  Then a POST is done from the
website to 127.0.0.1 with the body containing scheme code.  This code is
then executed by the Guile interpreter on the listening port.

The version we are releasing mitigates this problem by detecting
incoming HTTP connections and closing them before executing any code.

However, there is a better long term solution, which is already
available even to users of older versions of Guile: Guile supports unix
domain sockets in POSIX environments.  For example, users may run the
command:

  guile --listen=/tmp/guile-socket

to open and listen to a socket at `/tmp/guile-socket`.  Geiser users may
then connect using `M-x geiser-connect-local`.  This is considerably
safer.

We hope that other program authors take heed of this lesson as well:
many programs make use of localhost + port as a way of limiting
connections.  Unfortunately, in today's complex networked environment,
this isn't a safe assumption.  It's very difficult to predict what
programs may provide a way of chaining requests to an application
listening on localhost, and certainly difficult on a system where
web browsers are involved.  Take heed!

[1] https://www.jochentopf.com/hfpa/
[2] https://en.wikipedia.org/wiki/DNS_rebinding
[3] http://bouk.co/blog/hacking-developers/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]