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

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

[Christopher Allan Webber]

[-- 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 --]

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

[Nala Ginrut]

On Tue, 2016-10-11 at 09:01 -0500, Christopher Allan Webber wrote:
> 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=08c021916
> dbd3a235a9f9cc33df4c418c0724e03
> 
> 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.
> 


Indeed, I've considered to do so in Artanis too.
But maybe we should provide both just like what php-fpm does? And let users
choose which one to use, localhost:port or unix socket.

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

[Thompson, David]

On Wed, Oct 12, 2016 at 11:49 AM, Nala Ginrut <nalaginrut@gmail.com> wrote:

> But maybe we should provide both just like what php-fpm does? And let users
> choose which one to use, localhost:port or unix socket.

This is what Guile already does.

- Dave

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

[Lizzie Dixon]

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

Hi,

On 10/11, Christopher Allan Webber wrote:
> 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.

You don't need to rebind DNS to exploit this bug, or other bugs like
it. I wrote some details here:

<https://blog.lizzie.io/exploiting-CVE-2016-8606.html>

Best,

Lizzie.

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

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

[Alex Kost]

Lizzie Dixon (2016-10-14 14:55 -0700) wrote:

> Hi,
>
> On 10/11, Christopher Allan Webber wrote:
>> 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.
>
> You don't need to rebind DNS to exploit this bug, or other bugs like
> it. I wrote some details here:
>
> <https://blog.lizzie.io/exploiting-CVE-2016-8606.html>

Wow, this is great!

It's remarkable how you found ways to escape all this stuff in the code.
I really enjoyed this reading, thanks a lot for sharing!

-- 
Alex

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

[Christopher Allan Webber]

Lizzie Dixon writes:

> Hi,
>
> On 10/11, Christopher Allan Webber wrote:
>> 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.
>
> You don't need to rebind DNS to exploit this bug, or other bugs like
> it. I wrote some details here:
>
> <https://blog.lizzie.io/exploiting-CVE-2016-8606.html>
>
> Best,
>
> Lizzie.

Hi Lizzie!  Thanks for the post.  Interesting to see you figured out how
to do it with a GET request, not just a POST.  So, I guess this will
work from a public site as well?  I'm always a bit fuzzy about what
browsers do and don't allow, but I'm stunned that a browser will let a
request from some http://foo.example/ to http://localhost:37146/, even
for just a GET.  It seems like there are all sorts of daemons you can
exploit that way.

Anyway, thanks for the interesting blogpost, and kudos for using Guile
to write your example!
 - Chris

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

[Arne Babenhauserheide]

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


Christopher Allan Webber writes:
> browsers do and don't allow, but I'm stunned that a browser will let a
> request from some http://foo.example/ to http://localhost:37146/, even
> for just a GET.  It seems like there are all sorts of daemons you can
> exploit that way.

This can be pretty useful for embedding an iframe with a local service
(I do that for babcom[1]: Decentralized comments over Freenet, sadly still
pretty slow, because I’m using an in-Freenet system for that which
wasn’t optimized for the usecase).

On the downside, companies use the same methods to connect local
services with playback-restrictions (DRM) which aren’t easily doable via
the web alone. Likely this is the reason why it’s still possible, though
I’d wish it were the other way round (possible for the good usages, not
possible for the problematic-but-profitable ones)…

[1]: http://www.draketo.de/proj/freecom/

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

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

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

[Lizzie Dixon]

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

Hi Christopher,

On 10/16, Christopher Allan Webber wrote:
> So, I guess this will work from a public site as well?  

Yes! The HTML I mentioned in my post is available here:

<http://s3-us-west-2.amazonaws.com/blog.lizzie.io/exploiting-CVE-2016-8606-exploit.html>

(Though note that it won't work if you visit it over HTTPS, since
HTTPS documents aren't allowed to XHR to HTTP.)

If you visit it while a guile 2.0.13 repl is listening on 37146,
you'll see this:

    [lizzie@empress b.l.i]$ guile --listen
    GNU Guile 2.0.13
    Copyright (C) 1995-2016 Free Software Foundation, Inc.
    
    Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
    This program is free software, and you are welcome to redistribute it
    under certain conditions; type `,show c' for details.
    
    Enter `,help' for help.
    scheme@(guile-user)> 
    @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
    @@ POSSIBLE BREAK-IN ATTEMPT ON THE REPL SERVER                @@
    @@ BY AN HTTP INTER-PROTOCOL EXPLOITATION ATTACK.  See:        @@
    @@ <https://en.wikipedia.org/wiki/Inter-protocol_exploitation> @@
    @@ Possible HTTP request received: "GET /?(let((ascii(((lambda(x)x)reverse)(((lambda(x)x)char-set-fold)((lambda(x)x)cons)(((lambda(x)x)make-list)((lambda(x)x)0))((lambda(x)x)char-set:ascii)))))(((lambda(x)x)with-output-to-file)(((lambda(x)x)string)(((lambda(x)x)list-ref)((lambda(x)x)ascii)((lambda(x)x)110))(((lambda(x)x)list-ref)((lambda(x)x)ascii)((lambda(x)x)111))(((lambda(x)x)list-ref)((lambda(x)x)ascii)((lambda(x)x)116))(((lambda(x)x)list-ref)((lambda(x)x)ascii)((lambda(x)x)101))(((lambda(x)x)list-ref)((lambda(x)x)ascii)((lambda(x)x)46))(((lambda(x)x)list-ref)((lambda(x)x)ascii)((lambda(x)x)116))(((lambda(x)x)list-ref)((lambda(x)x)ascii)((lambda(x)x)120))(((lambda(x)x)list-ref)((lambda(x)x)ascii)((lambda(x)x)116)))(lambda()(((lambda(x)x)display)(((lambda(x)x)string)(((lambda(x)x)list-ref)((lambda(x)x)ascii)((lambda(x)x)62))(((lambda(x)x)list-ref)((lambda(x)x)ascii)((lambda(x)x)58))(((lambda(x)x)list-ref)((lambda(x)x)ascii)((lambda(x)x)41))(((lambda(x)x)list-ref)((lambda(x)x)ascii)((lambda(x)x)10))))))) HTTP/1.1\r\nHost: localhost:37146\r\nConnection: keep-alive\r\nOrigin: http://s3-us-west-2.amazonaws.com\r\nUser-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36\r\nAccept: */*\r\nReferer: http://s3-us-west-2.amazonaws.com/blog.lizzie.io/exploiting-CVE-2016-8606-exploit.html\r\nAccept-Encoding: gzip, deflate, sdch\r\nAccept-Language: en-US,en;q=0.8\r\n\r\n"
    @@ The associated socket has been closed.                      @@
    @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@


I don't recommend visiting it while a 2.0.12 repl is open, but it will
write a file in that case.

> I'm always a bit fuzzy about what browsers do and don't allow, but
> I'm stunned that a browser will let a request from some
> http://foo.example/ to http://localhost:37146/, even for just a GET.
> It seems like there are all sorts of daemons you can exploit that
> way.

It's a little absurd, yeah. :/ Maybe this string of exploits will
convince others to reconsider, but probably this kind of vulnerability
will be around for a while.

Thanks,

Lizzie.

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

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

[Andy Wingo]

Hi!

On Fri 14 Oct 2016 23:55, Lizzie Dixon <_@lizzie.io> writes:

> <https://blog.lizzie.io/exploiting-CVE-2016-8606.html>

I know it's a late kudo but still -- great investigation and writeup,
thank you for digging in to this one :)

Andy