4 ms·

So if I understand this correctly, anyone can bring down a site with a Caddy server by just running : curl -X POST "https://example.com:2019/stop https://exampl

• jorams 3y ago
  No, it is only bound to localhost.
• gkbrk 3y ago
  No, by default it listens on localhost. So only processes running on the same machine can connect to that port.
  • executesorder66 3y ago
    Okay that makes sense. So why would you bother disabling this thing? I'd imagine if someone already has local access to the server, it's already too late.
    • mcint 3y ago
      Most people would expect that `sudo` and `curl localhost:2019` are very different permissions, that is, curl with post payload `-d '{"admin":{"remote":{"listen":"0.0.0.0:2019"}}}'`, and you'd only have to convince an existing process to make the request.
    • rekoil 3y ago
      SSRF in an application is a serious issue to have on its own, that's true, but in combination with a Caddy admin endpoint it can be used to give an attacker full access to your local network. You could have a blind SSRF vulnerability in an application and while that's not great, it is difficult for an attacker to exploit successfully. If the attacker knows or guesses you're hosting Caddy on the same machine, they know you most likely have an admin interface on localhost:2019 that they can use to make further local network requests and also makes it possible for them to access the results of their local network requests they were making through the blind SSRF vulnerability hypothesised above. Basically, if you're not using it (and you shouldn't be using such functionality on a production machine), then you don't need it and should disable it, see: https://owasp.org/Top10/A05_2021-Security_Misconfiguration/ https://owasp.org/Top10/A05_2021-Security_Misconfiguration/
      • francislavoie 3y ago
        > Basically, if you're not using it (and you shouldn't be using such functionality on a production machine), then you don't need it and should disable it Actually, most everyone wants zero-downtime config reloads. The API is necessary to perform config reloads. As others have said, you may use a unix socket instead for the admin endpoint. And see https://news.ycombinator.com/item?id=37482096 https://news.ycombinator.com/item?id=37482096, we plan to make that the default in certain distributions.
        • yencabulator 3y ago
          > The API is necessary to perform config reloads. Of course it isn't. It could reload the config from the same path it loaded the config from in the first place. Like practically all other software has done for decades.
          • francislavoie 3y ago
            The source of a config doesn't necessarily need to be from a config file. Config loading is abstracted. So it requires input, and signals provide no way to pass arguments, so it's not workable. See https://github.com/caddyserver/caddy/issues/3967 https://github.com/caddyserver/caddy/issues/3967
            • yencabulator 3y ago
              This sounds like a design decision you've made, not an inherent limitation. You can read config from files, like practically all other software has done for decades.
        • rekoil 3y ago
          I get the thing about config reloads, I don't think it's worth it due to the security risks of the current default, but I get it. Happy to hear you're moving to sockets by default on *nix! However, I'd like to point out that the default should be in the binary, not in the distros default environment variables, otherwise it won't reach people who build their own binary, and depending on how you start your Caddy server you may clear environment variables for that process, and end up with the insecure HTTP-based admin endpoint enabled by accident.
    • raesene9 3y ago
      In some cases, localhost is not just accessible from localhost :) https://unit42.paloaltonetworks.com/cve-2020-8558/ https://unit42.paloaltonetworks.com/cve-2020-8558/ Also SSRF risks as mentioned elsewhere ...
    • hnbad 3y ago
      You should disable it if you don't need it or at least move it behind authentication if you do need it. Security follows the Swiss cheese model: each individual measure has known limitations but by layering them, you reduce the overall number of attack vectors. Getting the server to make arbitrary HTTP requests is bad, yes, but limiting what the attacker can do with that makes it less dangerous if you somehow screw that one thing up.
    • netheril96 3y ago
      Not really. If someone logins as user A on the machine, and caddy runs as user B, then unless A has sudo access, A cannot modify caddy. But with this admin HTTP endpoint, user A now can arbitrarily modify caddy.
      • rekoil 3y ago
        That's another really good point, even if it's less common these days to see this type of shared machine.
      • anakaine 3y ago
        This does kind of beg the question, who is sharing their load balancer / reverse proxy?
      • ufmace 3y ago
        That's true, but I think if your production web server is running on a system that you expect to have other users log into and do things on while having the Unix permissions prevent them from interfering with the production server, then your whole architecture and process is deeply broken far beyond the ability of any Caddy design decisions to address.
• deleted 3y ago
  [deleted]
• deleted 3y ago
  [deleted]