7 ms·
Guile security vulnerability with listening on localhost and port
- flukus 10y agoThe same issue was discussed on here recently: http://bouk.co/blog/hacking-developers/ http://bouk.co/blog/hacking-developers/ I think we're only scratching the surface on the number of vulnerabilities exposed.
- l_zzie 10y agoI don't think this is the same vulnerability. You don't even need to rebind DNS to do it, I believe: just make an XmlHTTPRequest. Your GET is considered code. The browser will get back a request that doesn't have a cors header and so not let you read it, but your code still executes. So there's no reason to be on the same origin, so DNS rebinding is unnecessary
- fulafel 10y agoClojure should pick up on this too.
- aardvark179 10y agoThere is https://github.com/monsanto/nreplds https://github.com/monsanto/nreplds but it requires some native code, and obviously isn't a solution for those on Windows. I'm not sure how vulnerable nRepl is to http attacks as I don't think either of its default transports would accept or filter out http commands.
- fulafel 10y agoI'm not so sure, certainly one of the two socket protocols is vulnerable (the "tty" one) judging by what the regular repl does with '' GET /%20(println"hello") HTTP/1.0 '' and it's somewhat likely that you could get through the bencode transport too.
- l_zzie 10y agoI tried to get nrepl to accept http requests once and I couldn't make it validate anything. (But of course I'd love to see someone manage to do it...)
- imagist 10y agoIs this an issue with Guile, or is this an issue with browsers? It seems like allowing sites to query localhost is a vulnerability that could affect a wide variety of development tools. Maybe I'm not thinking of some use case, but it seems to me that we would only ever want requests to localhost to come from local sources, no?
- X-Istence 10y agoThis is a DNS re-bind attack.
- brazzledazzle 10y agoI wonder if browsers will need to start including a dev mode toggle to allow access to anything hosted on the local loopback.
- aikah 10y agobrowsers absolutely SHOULD do that. A page on the internet shouldn't have access to localhost by default ever.
- antocv 10y agoBut this is not a case of a webpage on the internet having access to your localhost, its your local process which access local host!
- languagewars 10y agoThis is a webpage with an origin outside your host, it is only supposed to have implicit access to the same origin in a sandbox imposed by the local browser. Unfortunately the nature of that policy is broken by not going bellow resolved names, most especially for non-http where the service isn't sent the hostname the client used to resolve it. So, it is most certainly appropriate for a browser to block local networks (including localhost) from being in foreign domains AFA sanboxing. I also don't want a website attacking my (id)iot router via this broken sandbox.
- tedunangst 10y ago> the presumption that "localhost" is only accessible by local users Why is there even a presumption that all local users are equally trusted?
- flukus 10y agoSomeone logged in to the machine likely has enough access to make this attack irrelevant.
- Arnt 10y agoEven HN has enough access to your machine. Your browser is showing you this page, the page may contain javascript (probably does, feh), and the javascript can retrieve http://localhost:43278/this/that http://localhost:43278/this/that.
- cheiVia0 10y agoNot if you have noscript and the ABE protection turned on.
- tmsbrg 10y agoThat doesn't even require JavaScript, does it? Just `<img src="http://localhost..."/>` http://localhost..."/>`.
- Arnt 10y agoI suppose you're right. Although for the good stuff you want POST. With POST and an error-tolerant SMTP server you can send mail, I imagine other kinds of servers might be equally accommodating.
- JoshTriplett 10y agoNot necessarily; unless they have root, they likely don't have permission to run as your user account, only their own.
- 10y ago
- Tepix 10y agoThe browsers should consider detecting when an adress in DNS changes from non-local to localhost and blocking requests when this occurs.
- antocv 10y agoNot the browsers, the dns library. Protect any application.
- qwertyuiop924 10y agoThis is actually a vulnerability in any language that provides a networked REPL. I'm glad that Guile kept the option to run a REPL via a port, because that's really useful for debugging nonlocal servers (investigating production issues, etc.).
- paroneayea 10y agoIt does look like there's a way to "forward" a unix domain socket over ssh enough to do that kind of debugging: https://debian-administration.org/users/dkg/weblog/68 https://debian-administration.org/users/dkg/weblog/68
- qwertyuiop924 10y agoThat's certainly a potential solution.
- fulafel 10y agoNetworked REPL doesn't preclude security. See eg Twisted's SSH based twisted.conch.manhole
- qwertyuiop924 10y agoYeah, but until you linked that, I'd never seen a networked REPL that actually provided it.
- tetrep 10y agoWhy not have the REPL (or whatever else you're exposing to localhost) require a token for authentication of each request?
- qwertyuiop924 10y agoBecause it's usually a raw socket, not an HTTP interface, so that's kind of tricky. But it could work.
- 0x0 10y agoSounds very similar to the emergency patch issued for Android Studio and IntelliJ IDEA back in May, https://blog.jetbrains.com/blog/2016/05/11/security-update-for-intellij-based-ides-v2016-1-and-older-versions/ https://blog.jetbrains.com/blog/2016/05/11/security-update-f...