We've just released a new version of GNU Guile, version 2.0.13, which is a security release for Guile (see the original announcement).
This handles a significant security vulnerability affecting the live REPL, CVE-2016-8606. 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. (A more minor security issue is also addressed, CVE-2016-8605.)
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 or so on. This allows Guile users to hack programs even while programs are running.
When using the live hacking feature, 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 and a DNS rebinding attack. How to combine these attacks is published in the article How to steal any developer's local database.
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:
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!
(This post originally appeared on the guile-users mailing list.)