3 ms·

Also put a black hat: what can be done by theft well-known port is basically like a MiTM attack. Anyway MiTM attack should be prevented by other methods like pu

Also put a black hat: what can be done by theft well-known port is basically like a MiTM attack. Anyway MiTM attack should be prevented by other methods like public key auth.

throwaway09223 4y ago
Creating identities is useful, but also impractical at scale for internal access. Your system depends on non-authenticated privileges. I'll explain: Privileged ports are a permission applied to bind() to a sockaddr of type AF_INET. Privileges are also checked when bind()ing to type AF_UNIX -- aka a unix domain socket -- aka a path to a file in your filesystem. Privileges are also checked when open()ing a local file. It is entirely reasonable to rely on filesystem privileges to control access to regular files like /etc/shadow, or /etc/ssh/ssh_host_ed25519_key. It is entirely reasonable to rely on filesystem privileges to control access to unix domain sockets. It is entirely reasonable to rely on interface privileges to control access to inet sockets. The commonality in all of the above scenarios is that it is reasonable to trust the local system regarding its own access controls. There is no such practical concept as a MiTM between a process and open() to a local file, nor is there such thing as MiTM between a process and a bind() to a local resource. In fact, this local trust is a required component to implement a key based system (note: the need of sshd to trust file permissions to store a host key)
zajio1am 4y ago
Even if the other methods prevented MiTM attack, it is still DoS attack (as the expected service is not available).
stouset 4y ago
You can enforce public-key auth server-side, but you can't enforce that your clients won't prompt for a password if the (attacker-run) sshd a client connects to requires it. Clients should be configured correctly to never ask. But many won't be and that's out of your control.

Also put a black hat: what can be done by theft well-known port is basically like a MiTM attack. Anyway MiTM attack should be prevented by other methods like public key auth.

throwaway09223 4y ago

Creating identities is useful, but also impractical at scale for internal access. Your system depends on non-authenticated privileges. I'll explain: Privileged ports are a permission applied to bind() to a sockaddr of type AF_INET. Privileges are also checked when bind()ing to type AF_UNIX -- aka a unix domain socket -- aka a path to a file in your filesystem. Privileges are also checked when open()ing a local file. It is entirely reasonable to rely on filesystem privileges to control access to regular files like /etc/shadow, or /etc/ssh/ssh_host_ed25519_key. It is entirely reasonable to rely on filesystem privileges to control access to unix domain sockets. It is entirely reasonable to rely on interface privileges to control access to inet sockets. The commonality in all of the above scenarios is that it is reasonable to trust the local system regarding its own access controls. There is no such practical concept as a MiTM between a process and open() to a local file, nor is there such thing as MiTM between a process and a bind() to a local resource. In fact, this local trust is a required component to implement a key based system (note: the need of sshd to trust file permissions to store a host key)

zajio1am 4y ago

Even if the other methods prevented MiTM attack, it is still DoS attack (as the expected service is not available).

stouset 4y ago

You can enforce public-key auth server-side, but you can't enforce that your clients won't prompt for a password if the (attacker-run) sshd a client connects to requires it. Clients should be configured correctly to never ask. But many won't be and that's out of your control.