From ${URL}: Hi, if this hasn't already caught your interest here's a forward from guile-dev, should be of interest of the people maintaining guile on Gentoo. Below follows the message: From: Christopher Allan Webber <cwebber@dustycloud.org> To: guile-devel@gnu.org, guile-user@gnu.org Subject: Guile security vulnerability w/ listening on localhost + port (with fix) Date: Tue, 11 Oct 2016 09:01:18 -0500 Message-ID: <87k2dfc7dd.fsf@dustycloud.org> 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=3Dstable-2.0&id=3D08= c021916dbd3a235a9f9cc33df4c418c0724e03 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]. =20=20 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=3D/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/ Reproducible: Always
Needs to be investigated whether this also affects guile versions in stable branch (1.8)
Updated ${URL}: Commit message is: REPL Server: Guard against HTTP inter-protocol exploitation attacks.stable-2.0 Reported by Christopher Allan Webber <cwebber@dustycloud.org> Co-authored-by: Ludovic Courtès <ludo@gnu.org> This commit adds protection to Guile's REPL servers against HTTP inter-protocol exploitation attacks, a scenario whereby an attacker can, via an HTML page, cause a web browser to send data to TCP servers listening on a loopback interface or private network. See <https://en.wikipedia.org/wiki/Inter-protocol_exploitation> and <https://www.jochentopf.com/hfpa/hfpa.pdf>, The HTML Form Protocol Attack (2001) by Tochen Topf <jochen@remote.org>. Here we add a procedure to 'before-read-hook' that looks for a possible HTTP request-line in the first line of input from the client socket. If present, the socket is drained and closed, and a loud warning is written to stderr (POSIX file descriptor 2). * module/system/repl/server.scm: Add 'maybe-check-for-http-request' to 'before-read-hook' when this module is loaded. (with-temporary-port-encoding, with-saved-port-line+column) (drain-input-and-close, permissive-http-request-line?) (check-for-http-request, guard-against-http-request) (maybe-check-for-http-request): New procedures. (serve-client): Use 'guard-against-http-request'. * module/system/repl/coop-server.scm (start-repl-client): Use 'guard-against-http-request'. * doc/ref/guile-invoke.texi (Command-line Options): In the description of the --listen option, make the security warning more prominent. Mention the new protection added here. Recommend using UNIX domain sockets for REPL servers. "a path to" => "the file name of".
Provisional investigation indicates this issue not affecting stable package, rating changed.
committer Amy Winston <amynka@gentoo.org> 2016-11-05 12:55:59 (GMT) commit f4acb8b7ed70914fc98bbb7532b44b7087b85048 dev-scheme/guile: version bump 2.0.13 Bugs: 597216,596864,596876 committer Amy Winston <amynka@gentoo.org> 2016-11-06 19:13:23 (GMT) commit 857729aac64d4c4a007fefdb66d2d461adac7110 dev-scheme/guile: remove old 2.0.12 Should be fixed now.
@maintainer(s), thank you for the bump and removal!
