5 ms·

Is 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 vari

by imagist 10y ago

Is 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 ago
This is a DNS re-bind attack.
- brazzledazzle 10y ago
  I wonder if browsers will need to start including a dev mode toggle to allow access to anything hosted on the local loopback.
  - aikah 10y ago
    browsers absolutely SHOULD do that. A page on the internet shouldn't have access to localhost by default ever.
    - antocv 10y ago
      But 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 ago
        This 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.
        brazzledazzle 10y ago
        But don't they update DNS so that the origin for the (presumably sub) domain is now pointing at your localhost? Perhaps the solution is to track the DNS state. Any external to localhost changes should be blocked. And any communication between parent/sub domains should never cross the localhost boundary no matter what DNS might say. Of course this would interfere with development so it would need to be something you could toggle. But I'm 100% sure there's something I haven't thought of that depends on this behavior.
- l_zzie 10y ago
  It's not only a DNS rebind attack. I'm pretty sure in this case even a GET could get rce , so you don't even need to check the cors headers. You can just XHR.
pilif 10y ago
Dropbox and Github both use it to talk to their installed desktop clients from the website. It's very useful as it by just installing an app, a website can get more access to the local machine's hardware without having to resort to browser-specific plugins. In our case, we're using it to read data from a barcode scanner to use it on a web application. All a user needs to do is to install the application an once that's done it works in all browsers.
- flukus 10y ago
  Can any websites talk to these apps? I've built a similar one (a decade ago now), but we at least had the benefit of only running on a closed network.
  - pilif 10y ago
    Potentially, yes. In our case we're doing a bit of additional work to prevent this from happening though. Other sites would get access to the built-in web server, but they wouldn't get anything apart from a 403 error.
- imagist 10y ago
  > Dropbox and Github both use it to talk to their installed desktop clients from the website. It's very useful as it by just installing an app, a website can get more access to the local machine's hardware without having to resort to browser-specific plugins. Okay, but from a user's perspective this is exactly what I would NOT want--it's unintuitive to me that going onto GitHub would give them access to my machine's hardware just because I have the app installed. The program should serve the user, not GitHub or DropBox.
rixed 10y ago
The site is not querying localhost, the browser is. I find it strange that we consider the error to lie in guile or redis or memcached or elastic search when clearly the browser is the security hole. Why is it so?
- antocv 10y ago
  Well the browser must be able to visit http://127.0.0.1 http://127.0.0.1 whats so different about that than https://192.168.1.1 https://192.168.1.1 or any other address? Its only in combination with DNS that a browser can be tricked into sending requests where it didnt intend - but thats a problem of DNS. So libnss or whatever library the browser uses sees lists.gnu.org and resolves that to 208.118.235.17 so browser initiates connection to that IP, but on subsequent requests, the name lists.gnu.org is changed to 127.0.0.1, how would a web-browser notice this, shouldnt the dns-library warn about this or just use a cache? In any case, you can prevent it like this iptables -A OUTPUT -d 127.0.0.0/8 -p tcp -m owner --uid-owner $YOUR_USER_ID_OF_BROWSER -m tcp -j REJECT --reject-with-tcp-reset that is, if you run the browser under its own uid.
  - Matt3o12_ 10y ago
    Quite simple. I don't think it is a good idea to allow querying sites from the locale network if the visited site is hosted on the public internet. Let's say I visit google.com and it resolves to google's public Webserver. Your browser should be able to see whether the IP is in the public range (if I'm not mistaken you just checking that the IP is not an A, B, or C class IP, but don't quote me on that). If it is not a local IP (e.g. localhost, LAN, WAN), the browser should disallow all request to local IP addresses (Ajax queries, HTML frames, form requests) initiated by the initial page (google or whatever). It should work the other way around of course and I have never seen a use case where a public webpage relies on being able to query or send a request to my local network if this page is from the internet. A normal HTTP redirect could be allowed because I think some routers rely on that to give the user a way to configure it (they tell the user to start configuring their router by going to config.manufacture.tld which displays some information and then issues a normal redirect to the default router IP). Post request directly sent to the local network should be strictly forbidden, though. Why would I ever want to do that?
JoshTriplett 10y ago
Both. Browsers shouldn't allow requests to localhost or 127.0.0.0/8 from anything other than localhost, but guile also shouldn't listen on a port on localhost by default.
- rekado 10y ago
  Guile does not listen on any port by default. To make it listen the `--listen` option has to be provided.

by imagist 10y ago

X-Istence 10y ago

This is a DNS re-bind attack.

brazzledazzle 10y ago
I wonder if browsers will need to start including a dev mode toggle to allow access to anything hosted on the local loopback.
- aikah 10y ago
  browsers absolutely SHOULD do that. A page on the internet shouldn't have access to localhost by default ever.
  - antocv 10y ago
    But 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 ago
      This 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.
      - brazzledazzle 10y ago
        But don't they update DNS so that the origin for the (presumably sub) domain is now pointing at your localhost? Perhaps the solution is to track the DNS state. Any external to localhost changes should be blocked. And any communication between parent/sub domains should never cross the localhost boundary no matter what DNS might say. Of course this would interfere with development so it would need to be something you could toggle. But I'm 100% sure there's something I haven't thought of that depends on this behavior.
l_zzie 10y ago
It's not only a DNS rebind attack. I'm pretty sure in this case even a GET could get rce , so you don't even need to check the cors headers. You can just XHR.

pilif 10y ago

Dropbox and Github both use it to talk to their installed desktop clients from the website. It's very useful as it by just installing an app, a website can get more access to the local machine's hardware without having to resort to browser-specific plugins. In our case, we're using it to read data from a barcode scanner to use it on a web application. All a user needs to do is to install the application an once that's done it works in all browsers.

flukus 10y ago
Can any websites talk to these apps? I've built a similar one (a decade ago now), but we at least had the benefit of only running on a closed network.
- pilif 10y ago
  Potentially, yes. In our case we're doing a bit of additional work to prevent this from happening though. Other sites would get access to the built-in web server, but they wouldn't get anything apart from a 403 error.
imagist 10y ago
> Dropbox and Github both use it to talk to their installed desktop clients from the website. It's very useful as it by just installing an app, a website can get more access to the local machine's hardware without having to resort to browser-specific plugins. Okay, but from a user's perspective this is exactly what I would NOT want--it's unintuitive to me that going onto GitHub would give them access to my machine's hardware just because I have the app installed. The program should serve the user, not GitHub or DropBox.

rixed 10y ago

The site is not querying localhost, the browser is. I find it strange that we consider the error to lie in guile or redis or memcached or elastic search when clearly the browser is the security hole. Why is it so?

antocv 10y ago
Well the browser must be able to visit http://127.0.0.1 http://127.0.0.1 whats so different about that than https://192.168.1.1 https://192.168.1.1 or any other address? Its only in combination with DNS that a browser can be tricked into sending requests where it didnt intend - but thats a problem of DNS. So libnss or whatever library the browser uses sees lists.gnu.org and resolves that to 208.118.235.17 so browser initiates connection to that IP, but on subsequent requests, the name lists.gnu.org is changed to 127.0.0.1, how would a web-browser notice this, shouldnt the dns-library warn about this or just use a cache? In any case, you can prevent it like this iptables -A OUTPUT -d 127.0.0.0/8 -p tcp -m owner --uid-owner $YOUR_USER_ID_OF_BROWSER -m tcp -j REJECT --reject-with-tcp-reset that is, if you run the browser under its own uid.
- Matt3o12_ 10y ago
  Quite simple. I don't think it is a good idea to allow querying sites from the locale network if the visited site is hosted on the public internet. Let's say I visit google.com and it resolves to google's public Webserver. Your browser should be able to see whether the IP is in the public range (if I'm not mistaken you just checking that the IP is not an A, B, or C class IP, but don't quote me on that). If it is not a local IP (e.g. localhost, LAN, WAN), the browser should disallow all request to local IP addresses (Ajax queries, HTML frames, form requests) initiated by the initial page (google or whatever). It should work the other way around of course and I have never seen a use case where a public webpage relies on being able to query or send a request to my local network if this page is from the internet. A normal HTTP redirect could be allowed because I think some routers rely on that to give the user a way to configure it (they tell the user to start configuring their router by going to config.manufacture.tld which displays some information and then issues a normal redirect to the default router IP). Post request directly sent to the local network should be strictly forbidden, though. Why would I ever want to do that?

JoshTriplett 10y ago

Both. Browsers shouldn't allow requests to localhost or 127.0.0.0/8 from anything other than localhost, but guile also shouldn't listen on a port on localhost by default.

rekado 10y ago
Guile does not listen on any port by default. To make it listen the `--listen` option has to be provided.