Hacker News Reader

Comment by jeffbee | Hacker News Reader

One of the best things about user-space TCP implementations is never needing to be an archaeologist, never trying to figure out the path-dependent sequence of accidents that leads to surprising and undocumented kernel behaviors.

View on HN

But wouldn't the same issue apply to user-space TCP implementations too? User-space TCP implementations too could have "path-dependent sequence of accidents" which a power user might eventually need to figure out?

Yes but instead of being a 35-year-old accretion of mistakes, a user-space network stack is likely to be part of a more typical software lifecycle, that gets updated more easily and ultimately replaced. Also such things are dramatically easier to debug.

Happily Linux is at most a 32-year old accretion of mistakes (and I'm not completely confident 0.01 even had TCP).

Happily Linux is a good name for a fresh new distro.

What are arguments against user-space TCP?

It doesn't work out-of-the-box with any existing software, so it only applies to things you are building from scratch, or that are structured in such a way that adding an alternate network mode, or that would work with a dynamic library that shims the entire sockets API. Your user-mode stack won't be observable by any existing monitoring tools. Also, your process needs to execute with CAP_NET_RAW.

One argument is that it requires building on top of a raw socket, which can open you to all sorts of ancient vulnerabilities that have been patched in the battle-tested code running in the kernel, e.g. this recent ICMP remote code execution vulnerability [0] ("An attacker could send a low-level protocol error containing a fragmented IP packet inside another ICMP packet in its header to the target machine. To trigger the vulnerable code path, an application on the target must be bound to a raw socket") [1].

[0] Discussion: https://old.reddit.com/r/netsec/comments/11s80zo/cve20232341...

[1] Advisory: https://msrc.microsoft.com/update-guide/vulnerability/CVE-20...

If you are able, could you explain this in more detail? I find the description unparseable.

Reading the words I do understand, the raw socket aspect seems to be irrelevant right? The vulnerable code would be the the parser that incorrectly runs code based on invalid input? It might require raw socket to trigger the vulnerability, but perhaps it would not exist if it was not written in kernel C but rather in user space garbage collected code with a good type system (not sure what the vulnerability actually is).

    TAPIF=tap0; BR=br0; LOCAL_IP=192.whatever; MASK=24; REAL_IP=eth0

    sudo ip tuntap add dev $TAPIF mode tap user $(whoami)    
    sudo ip addr add $LOCAL_IP/$MASK dev $TAPIF
    sudo ip link set $TAPIF up
    sudo ip link add $BR type bridge
    sudo ip link set $TAPIF master $BR
    sudo ip link set $REAL_IF up
    sudo ip link set $REAL_IF master $BR

Means you don't have to add iptables rules to get the kernel tcp/ip stack to ignore packets meant for your program specific user level stack. Raw sockets require special permissions.

    sudo setcap cap_net_admin,cap_net_raw=eip my_prog_bin

ping needs this, for example.

    getcap $(which ping)
    /bin/ping = cap_net_raw+ep

But this underscores the real issue we face because enough people won't care about your security if its convenient for their programming that it isn't a barrier to acceptance.

You have to get the kernel to do things, probably using root privs, to get out of the way of your programs ip traffic now. The kernel will jump in and reject a syn or synack response meant for your program and its user level stack. You don't have do anything like that if your program calls socket() to get an fd and goes on in the usual manner from there.

Normally if app opens a port it is not allowed to by firewall or application permissions it will just get error, with RAW sockets kernel would need to parse packet before deciding that.

For example normally you will get permission denied when you try to listen on sub-1024 port on normal user.

I'd also imagine if kernel is doing any kind of connection tracking (so really anything with firewall), it would be more optimal to have that connection tracked in kernel vs decoding it and adding to conntrack table.

I guess some kind of half-RAW could be done in place, like say a socket where you define protocol and port but handle actual packets in userspace ?

Reply on news.ycombinator.com