1. 54
  1.  

  2. 9

    The answer to

    There are plenty of webpages that offer online services where you can type in C code and run it. It is obvious that such systems are insecure if the code running is not sandboxed in some way. But is it equally obvious that the compiler also needs to be sandboxed?

    should be yes, if only because compilers are insanely complex creatures developed under the assumption that input is trusted.

    1. 3

      Interesting find! So the service in question was not only running as root, but the webserver/app wasn’t even chrooted. Reminds me a bit of the Apache phf exploit from 1996. People, always wear your seatbelt!

      Just as an aside, and I know this article isn’t about any particular language, but Go makes it trivially easy to get a webserver running - but it’s not chrooted and runs as root. Would be nice if it were trivially easy to get a webserver running with basic defenses.

      1. 2

        You can listen on high ports as an unprivileged user and redirect traffic at the firewall (I do this for my Go servers in production).

        1. 2

          but Go makes it trivially easy to get a webserver running - but it’s not chrooted and runs as root.

          If it was dev you’d be at a port above 1024, so a regular user would run it. And if it was prod, wouldn’t you drop privileges after start via your service manager?

          Or were you just saying how easy it is to just sudo ./web-server

          1. 1

            …or use authbind and not worry about privileges at all.

          2. 1

            One of the downsides of chroot is that it’s not implemented on Windows, so it’ll make your webserver not cross-platform. I’m not sure what alternatives there are for Windows?

            1. 1

              Docker containers usually run their local system as root, and most compiler services I know of run in Docker containers or something similar. Eventually we’ll get to a capability-based reality where you have to explicitly grant permissions rather than explicitly taking them away, but we’re not quite there yet.

            2. 3

              This reminds me, including files from sysfs and procfs in compilers can cause problems because gcc and clang use stat() to find the #include file size, and stat() returns incorrect information for sysfs and procfs file systems.

              I always wondered if these bugs could be exploited somehow, perhaps in one of these remote execution environments, especially since they mmap() the files using the wrong stat() reported filesize.

              https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66909 https://bugs.llvm.org/show_bug.cgi?id=24168

              sad to say these bugs still seem present in current compilers… Well, gcc isn’t segfaulting anymore, but clang still is reading a bunch of 0 bytes from the rest of the page the file is mapped to. It would probably also be worth trying to see if #include will have issues on other special files on Linux: pipes, sockets, dev files, etc.

              1. 1

                Fun fact: varnish passes its config through gcc and then loads the result memory: https://book.varnish-software.com/4.0/chapters/VCL_Basics.html

                So if an attacker has write access to the varnish port, it also has read access to the entire fs. Hopefully you werent running that as root.