4 ms·

I think the difference is whether it's something that's always enabled. You could presumably make it available or not at compile time, so the software shipped t

I think the difference is whether it's something that's always enabled. You could presumably make it available or not at compile time, so the software shipped to a customer wouldn't have it, but maybe if they were having issues, you could ship them a version with the debug server with their permission.

yjftsjthsd-h 6y ago
I can agree with that with the caveat that "enabled" has to be at either something that only the user can do. If it requires that the customer intentionally run a debug build, that's fine; if it can be toggled on without their knowledge, then it's a problem.
- orisho 6y ago
  It was disabled by default, and could only be enabled using environment variables. Even when enabled, the whole thing ran in Docker and the socket was bound to loopback, so you could only connect to it from within the container. When the intention is a debugging server, making it exposed to the world is a mistake and a security vulnerability. At that point it is effectively a backdoor, but the difference between a high level vulnerability such as this and a backdoor is developer intent.
  - tantalor 6y ago
    That doesn't sound very safe.
    - lukevp 6y ago
      What sounds unsafe about having a locally bound port inside a container that only binds with an env variable getting set?
      - still_grokking 6y ago
        For example that someone finds out about that backdoor and activate it to spy on users. Forwarding a port in Docker is not magic…
        orisho 6y ago
        Sure, it's simple. But you would have to be able to modify the container settings anyway. For all practical uses, and certainly in my case, you could just make it run a different image at that point. Or copy another executable into the container and run it. You're already privileged. Requiring you to be privileged to access the debug server means it's secure.
        still_grokking 6y ago
        Until things around change and what was previously "a secure backdoor" becomes a "less secure backdoor". ;-) One can read every second week about cases where some backdoor that was meant to be used "only for debugging" landed in the end product and became a security problem. Actually I usually suspect malice when something like that is found once again, as "who the hell could be so stupid to deliver a product with a glaring backdoor". But maybe there is something to Hanlon's razor… :-D
    - orisho 6y ago
      If you're already running another process in the container, you could do whatever you want anyway.

yjftsjthsd-h 6y ago

I can agree with that with the caveat that "enabled" has to be at either something that only the user can do. If it requires that the customer intentionally run a debug build, that's fine; if it can be toggled on without their knowledge, then it's a problem.

orisho 6y ago
It was disabled by default, and could only be enabled using environment variables. Even when enabled, the whole thing ran in Docker and the socket was bound to loopback, so you could only connect to it from within the container. When the intention is a debugging server, making it exposed to the world is a mistake and a security vulnerability. At that point it is effectively a backdoor, but the difference between a high level vulnerability such as this and a backdoor is developer intent.
- tantalor 6y ago
  That doesn't sound very safe.
  - lukevp 6y ago
    What sounds unsafe about having a locally bound port inside a container that only binds with an env variable getting set?
    - still_grokking 6y ago
      For example that someone finds out about that backdoor and activate it to spy on users. Forwarding a port in Docker is not magic…
      - orisho 6y ago
        Sure, it's simple. But you would have to be able to modify the container settings anyway. For all practical uses, and certainly in my case, you could just make it run a different image at that point. Or copy another executable into the container and run it. You're already privileged. Requiring you to be privileged to access the debug server means it's secure.
        still_grokking 6y ago
        Until things around change and what was previously "a secure backdoor" becomes a "less secure backdoor". ;-) One can read every second week about cases where some backdoor that was meant to be used "only for debugging" landed in the end product and became a security problem. Actually I usually suspect malice when something like that is found once again, as "who the hell could be so stupid to deliver a product with a glaring backdoor". But maybe there is something to Hanlon's razor… :-D
  - orisho 6y ago
    If you're already running another process in the container, you could do whatever you want anyway.