1. 56

  2. 9

    Interesting! Some checks I’ve done:

    It obviously doesn’t work if I run noscript (well, duh, but a point on “you should run noscript”)

    Starting up a quick web server (python -m http.server) is a nice way to see it happen: the site will just do a regular “GET /” request, that is logged. …however the page doesn’t list the webserver as it should. Maybe I’m missing something?

    I’ve just found out about firejail, so I tried it with that too. It seems to work nevertheless: my local webserver is called. I find this weird: isn’t firejail supposed to give you a sandbox, also involving network? I should probably learn more :)

    1. 6

      I’m leery of Firejail, as it’s had multiple (root) exploits and has been known (at least in the past) to make you more vulnerable rather than less.

      It’s also extremely easy to sandbox Firefox (or another browser) using systemd nspawn containers and/or SELinux sandboxing, so I’d go that route before Firejail.

      Maybe they’ve cleaned up the project, but I still feel like it’s the wrong approach.

      1. 3

        Any opinion on bubblewrap?


        1. 1

          I don’t know enough about it to have any useful opinion, but the README does offer a comparison to other projects.

        2. 1

          Why do you think it’s the wrong approach?

          It is a while I’m thinking about sandboxing, and it seems that there’s a “sandbox” command for selinux. Perhaps I should give it a try :) Thanks for the idea.

          1. 2

            The “one size fits all” solution, especially when it has to run with elevated privileges, means that little mistakes can be devastating — and this has happened before. There was also some past discussion on poor code quality which may or may not be relevant today.

            Using SELinux sandboxing doesn’t require starting with elevated privileges and then dropping them later. Something like sandbox -C -M -X -H ~/.firefox_sandbox/home -T ~/.firefox_sandbox/tmp -w 1280x960 -t sandbox_web_t firefox (going from memory here) should be sufficient.

            1. 2

              Thanks trn. I’ve been experimenting a bit with SELinux these days, and I think it’s really good, once one gets acquainted with it. Do you have relevant pointers that you feel I should look at?

              Also, while using sandbox I got a lot of notifications from the auditing system. I’m guessing I should read up on how to compile a policy to disable auditing for those warnings. Or figure out how to avoid them in the proper way, should it not work.

              1. 1

                The SELinux web site maintains collection of links to documentation and resources, but it can be a bit overwhelming.

                Instead, I usually point people at the SELinux Coloring Book for basic concepts. Then, while it’s not the most up-to-date documentation for the latest Fedora builds, I recommend the RHEL latest manual, which is, as of this writing, the Red Hat Enterprise Linux 7 SELinux User’s and Administrator’s Guide. It’s thorough enough for a good understanding and less than 200 pages.

                I also highly recommend Dan Walsh’s Blog which focuses mostly on SELinux topics.

        3. 5

          however the page doesn’t list the webserver as it should. Maybe I’m missing something?

          The server needs to support CORS, right? Or am I missing something?

          Unfortunately quite a few apps just have a “allow anything” policy, but in general it’s not like every webpage on the internet can just request your http://localhost:8080.

          That said, listening on *:8080 is probably not a good idea, depending on what it is, as anyone on the same network can access it by going to http://localhost:8080. I think that’s the point the website was mainly trying to make.

          1. 2

            Yes. as per the fetch spec, servers that do not respond with the right cors header, return a network error. However, whether a server is listening at all is likely more easily observable through timing side-channels than whether a resource is available on a server.

            1. 1

              Pretty handy if you test on anything other than a single desktop device, though.

              1. 1

                Actually unless i’m wrong cors don’t protect the lan server to receive an offensive post request.

            2. 5

              This article focuses on the privacy implications, but there have also been real remote code execution vulnerabilities that could be exploited via DNS rebinding: https://twitter.com/bcrypt/status/955621661126008832.

              Note that as far as I can tell, removing CORS headers does nothing to address attacks like Tavis’s (though I feel like I need to revisit all the details).

              1. 4

                Judging by the source, it’s using a WebRTC API to resolve my LAN IPv4 prefix. I didn’t know that was possible (so thanks for the enlightening article!)

                1. 4

                  Hi! Author here. Yes, I forgot to mention that in the post. Perhaps an interesting follow up.

                2. 2

                  Hmm. This website makes your browser to try to connect to UDP port 19302. I wonder if this PoC would work on TCP port 80. Otherwise, software like Little Snitch is a good way to prevent this behaviour.

                  1. 1

                    Interesting! I wanted to see it work but I couldn’t reproduce this from the code sample in the post :/

                    if anyone has ideas, i’m really interested in what i might have done wrong here: https://i.imgur.com/oGqCglr.png

                    1. 1

                      From the source it looks like the site doesn’t try port 3002:

                        const portsToTry = [
                          80, 81, 88,
                          3000, 3001, 3030, 3031, 3333,
                          4000, 4001, 4040, 4041, 4444,
                          5000, 5001, 5050, 5051, 5555,
                          6000, 6001, 6060, 6061, 6666,
                          7000, 7001, 7070, 7071, 7777,
                          8000, 8001, 8080, 8081, 8888,
                          9000, 9001, 9090, 9091, 9999,
                      1. 1

                        Ah, that was it, thank you!