Comment by throwaway09223 | Hacker News Reader

Comment by throwaway09223 | Hacker News Reader

Parent Full thread

Put on your black hat for a moment. You want to pretend to be the sshd on your shared university server and collect passwords or session data from your fellow students foolish enough to ignore host key warnings.

1) You find a way to crash sshd. This might be easier than it seems. Maybe you can fill up a disk partition and cause a fatal logging error, or drive the machine so low on memory that it is killed. If sshd seems too farfetched, pretend you're compromising a less robust system service like the printing subsystem.

2) Try to start your own listener before sshd can be restarted. It's a race, and with enough tries you will eventually win

3) If you're really diabolical, you might notice that there are certain cronjobs or management systems like puppet, chef, ansible, etc that restart system services at known times or after known events (after updating a config file). You write a script to watch for these events (use inotify to event on file updates), and race it to the finish line.

There really isn't a good mechanism from userspace for systemd to police ports without race conditions. Privileged ports is a fairly reasonable way to do it.

> sshd on your shared university server

Another attack scenario applies if the shared server hosts a web server:

If you have a shell and can bind a port, listening for HTTP requests. Example: nc -vvl 8080

Trick a victim into visiting your malicious port: http://example.com:8080/

The attacker gets the victim's cookies for http://example.com:80/ (and https://example.com:443/, if the "secure" flag is not set). And all other ports.

This attack succeeds because "Cookies do not provide isolation by port" (RFC6265 Section 8.5).

What is the fix? If only the cookie spec allowed binding to specific ports...

But an alternate fix could be requiring web browsers to only connect to privileged ports. 80 and 443, or any port <1024, thwarting the unprivileged user from exfiltrating cookies.

Unfortunately this ship has sailed and web browsers now have to support unprivileged ports forever. A more practical defense, in practice, is to consider this scenario out of scope, and/or implement application-level authentication. I am with you, and would have advocated privileged ports to defend against these attacks (with http and ssh and other services), but am not optimistic it will gain any traction. The world has moved on, and even multi-user shell servers are becoming increasingly rare (as much as I use them - still a proud Super Dimension Fortress member)

Well, that's a bug in the HTTP cookie spec. Regrettable, but as you note something that should have been foreseen. There's absolutely no excuse, as RFC6265 itself notes "cookies contain a number of security and privacy infelicities."

This bug is unrelated to port privileges

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.

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)

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

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.

Y'ain't wrong.

Did someone not realize this says "You aren't wrong" ?

Reply on news.ycombinator.com