1. 30
  1. 6

    Every program with two features has a third feature. You may just not be aware of what that feature is yet.

    1. 4

      The key mistake, it seems to me, is failing to authenticate write access to the config parameters. That is de facto an admin interface to the process/server, and needs to be locked down.

      (And secondarily, yeah, a runtime-settable parameter that makes the server shell out to an arbitrary executable seems like a bad idea regardless of who has access to it.)

      1. 3

        Ugh. Right in the feels. Most, if not all of those features, exist as some similar variant in the codebase I work on. Gaaah.

        1. 2

          So ugh, when will mozilla issue an CVE ? ;)

          1. 4

            Sorry. I didn’t mean to scare people.

            We do not execute random commands. We do not implement some RPC. We do have logging but it’s not controlled remotely. We can flip some preferences remotely (e.g., if you have enabled to sync settings through Firefox Sync, which is end-to-end encrypted). But those also can not execute or control commands.

            There’s no such vulnerability in any Mozilla product I know of.

            1. 2

              no worries, just me being sarcastic

              1. 2

                At least you didn’t use your “Mozilla Security” hat :P

          2. 2

            The company might have a small HTTP or RPC server that automatically gets baked into most network server software. It comes up on a given port and it hands out status information about the program. It might do things like export the values of counters so that something else can fetch them and store them, so yet another tool can be used to monitor and/or graph them.

            It’s not obvious, but this is the lone good choice in this log-oriented story. The internal Google tool, Borgmon, is discussed in the SRE book. The standard tool outside of Google is Prometheus. As the book says:

            In particular, Prometheus shares many similarities with Borgmon, especially when you compare the two rule languages. … To facilitate mass collection, the metrics format had to be standardized. An older method of exporting the internal state (known as varz) was formalized to allow the collection of all metrics from a single target in one HTTP fetch.

            This is all distinct from any gRPC endpoint which might allow for reconfiguration or flag-flipping. It’s possible to have read-only metrics exported without opening up security holes.

            1. 1

              I love how Prometheus and OpenMetrics were both like “we just took the borgmon text wire format and called it a standard”

            2. 1

              This becomes effective immediately and then there’s your verbose debugging info, all without restarting a thing.

              You might think this is awesome, but it’s usually not, all because of what comes after this.

              I would argue that the problem here isn’t setting program flags remotely, it’s setting arbitrary program flags remotely. I struggle to think of a justification for wiring up such a feature for anything except log verbosity - for everything else, you should be restarting the service anyway because it’s hard to predict whether the program will end up in an invalid state it would never have gotten to if you hadn’t mucked with the flags mid-flight.

              Log verbosity is a special exception for this rule because a) log output exists at the fringes of the control flow graph (it’s basically a sink for state, not a source), so the likelihood of putting the program in invalid state is extremely low, and b) restarting the program, unlike with almost everything else, is not an option because by doing so you are likely to destroy the information you wanted to turn up the logs to get in the first place.

              1. 2

                Also SIGHUP/SIGUSR1/2 exist and this is widely used to reload configs. And it kinda needs shell access, which can be scripted for doing it remotely, but is not opening up any holes…